6:17 a.m.
please stop just replying to me ;)
cc'ing jbosstools dev
On 03/15/2012 12:11 PM, Max Rydahl Andersen wrote:
> That is fine for generating the updatesite - but this does not control the resolution
of features/plugins when actually building with tycho.
Yes it does. Tycho resolves against given update-site, and local repo.
On a clean repo, tycho won't visit other sources than the one you give him (the
update-site), so we are sure it will use features/plugins from this site. If we control
the site, we control what Tycho can resolve.
Not true.
Read tycho-dev about plan mode.
And sure - if I remove all my mirrors from settings.xml, do not build other plugins than
from one specific branch/trunk on my machine with the same ~/.m2/repo in it then you are
correct.
But that is *not* what happens.
We build from multiple branches, we want to use mirrors (and those mirrors can get out of
date and thus build should fail if thats the case) and I don't have enough disk space
to have a ~/.m2/repo for each build.
/max
6:30 a.m.
New subject: Who uses .target file?
On 03/15/2012 12:17 PM, Max Rdahl Andersen wrote:
please stop just replying to me ;)
Oops, sorry.
And sure - if I remove all my mirrors from settings.xml, do not build
other plugins than from one specific branch/trunk on my machine with the same ~/.m2/repo
in it then you are correct.
Having stuff is a settings.xml makes build non portable.
It reduces the
control build provider have on dependency management since you (as a
consumer) decided to use other repositories. Having a settings.xml with
repo in it is just like adding stuff to the parent pom, we cannot
guarantee that much with customized pom.xml, it's the responsability of
the user.
I agree that having a clean repo for each branch is an annoying step.
But that's the only way I know to guarantee build isolation and
consistency (cf Jenkins), and it's working well.
We build from multiple branches
Ok.
we want to use mirrors
Really? How useful is it? Having
customized mirrors in settings.xml is
not very compatible with having strong management of dependency sources.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9:13 a.m.
New subject: Who uses .target file?
> And sure - if I remove all my mirrors from settings.xml, do not build other plugins
than from one specific branch/trunk on my machine with the same ~/.m2/repo in it then you
are correct.
Having stuff is a settings.xml makes build non portable. It reduces the control build
provider have on dependency management since you (as a consumer) decided to use other
repositories. Having a settings.xml with repo in it is just like adding stuff to the
parent pom, we cannot guarantee that much with customized pom.xml, it's the
responsability of the user.
yes, adding repositories to settings.xml is non portable.
Same is it to add it to pom.xml and having different repositories in profiles and see the
examples Nick was passing around - they are using arguments
to change the repository and they all make things nonportable.
That is not a bad thing as long as you have a target platform that you use to restrict the
resolution of the versions - similar to what plain maven <dependencyManagement> is
doing.
I agree that having a clean repo for each branch is an annoying step.
But that's the only way I know to guarantee build isolation and consistency (cf
Jenkins), and it's working well.
Jenkins is not the only place builds are done.
> We build from multiple branches
Ok.
> we want to use mirrors
Really? How useful is it?
*speed*!
Having customized mirrors in settings.xml is not very compatible with
having strong management of dependency sources.
How different is this from using -Dlocal.site=<pathtomirror> ?
*zero* afaics.
/max
4735
days inactive
4735
days old
jbosstools-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Max Rydahl Andersen -
Mickael Istria