I have worked on a tentative improvement of the "How To Build" page for JBoss Tools. You can see the result here: https://community.jboss.org/wiki/HowToBuildJBossToolsWithMaven3 You should make it a favorite since people ask very often "How can I build...". Also, you are welcome to improve it, all your suggestions on how to improve this page or how to improve build in general are welcome. All we want is to get all of you happy with the build ;)

> If JBoss Nexus is a requirement now then it seem to be missing instructions on adding the snapshot repo to ones ~/.m2/settings.xml ? The Nexus repo is added to the top-level pom.xml for each component, so it works without additional effort.

> >> If JBoss Nexus is a requirement now then it seem to be missing >> instructions on adding the snapshot repo to ones >> ~/.m2/settings.xml ? > The Nexus repo is added to the top-level pom.xml for each > component, so it works without additional effort. please don't do that. thats a very bad mvn practice. IMO provide a settings.xml users can use via -s settings.xml or copy to their ~/.m2/settings.xml instead.

>>> The Nexus repo is added to the top-level pom.xml for each >>> component, so it works without additional effort. >> >> please don't do that. thats a very bad mvn practice. >> >> IMO provide a settings.xml users can use via -s settings.xml or >> copy >> to their ~/.m2/settings.xml instead. > > For what it's worth, I think it's pretty convenient when things > just compile out of the box without any extra configuration steps: > git clone; mvn install. I completely agree on that. > As for it being bad practice, I thought that was one of the > benefits of using Maven: not having to scrounge around for JARs, > etc. to get the project to build. > problem is that repositories listed in pom.xml's are inherited by all projects using them which means they can affect their builds nondeterministcally. It's a flaw of maven. Since the only usecase for this is to get our current parent snapshots and every other jboss project already require changes to settings.xml i'm not too worried - especially if we can just provide a settings.xml to do it.

>> >> Since the only usecase for this is to get our current parent >> snapshots and every other jboss project already require changes to >> settings.xml i'm not too worried - especially if we can just >> provide >> a settings.xml to do it. > > Sounds like the right solution is to move the repository settings > down into the individual project parent poms (SwitchYard uses this > approach). That said, if they're all including the same repo, it > makes me wonder if we'd just be jumping through hoops for no real > benefit. Any project that needs to go into a product and not infect your users pom's will need to remove this reference. It is simply wrong to do. And yes it sucks but the consequences are rather annoying for those users wanting to do reproducible builds. /max

I prefer profiles in parent pom to configuration steps & settings in a settings.xml because... ... I don't use a settings.xml file.

... I'd rather look up how to build something by scanning its parent pom for profiles to use than magically determine what to put in my settings.xml file. How do I know to resolve against JBoss Nexus?

... using such a file adds an extra level of job complication when running in Jenkins. Using profiles it's easy to run the same config in BOTH Jenkins and offline; using settings.xml files pretty much guarantees a different bootstrapping step for each scenario (ie., either instructions to users on how to edit settings.xml or scripting such a process for use in Jenkins).

N On 04/11/2012 12:33 PM, Rob Cernich wrote: > Perhaps it might be better to use profiles then, instead of settings.xml. Default profile defines the public repo's and can be deactivated for product builds. WDYT? > > ----- Original Message ----- >>>> >>>> Since the only usecase for this is to get our current parent >>>> snapshots and every other jboss project already require changes to >>>> settings.xml i'm not too worried - especially if we can just >>>> provide >>>> a settings.xml to do it. >>> >>> Sounds like the right solution is to move the repository settings >>> down into the individual project parent poms (SwitchYard uses this >>> approach). That said, if they're all including the same repo, it >>> makes me wonder if we'd just be jumping through hoops for no real >>> benefit. >> >> Any project that needs to go into a product and not infect your users >> pom's will need to remove this reference. >> >> It is simply wrong to do. And yes it sucks but the consequences are >> rather annoying for those users wanting to do reproducible builds. >> >> /max >> >> > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

> guys - please read up on how maven works and how its recommended to use. > > > http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-p... These arguments are good and makes lot of sense for people proxying repositories. But assuming someone works on multiple projects, then his settings.xml is polluted with a lot of stuff coming from other projects, and then the build that will happen on his machine may differ a lot from the "normal/maintained" one. So that means that all project have to ship its settings.xml containing the repository to reference, and profiles related to enablement of these repositories. We'll have to split pom.xml into pom.xml + settings.xml. It makes things more complicated for maintainers and consumers, but makes sense in case of an "enterprise" deployment of Maven. Also please note that if you don't want the build to contain any reference to a repository, this is also an argument against target platforms since they directly refer to repository. I'll investigate on how dependencyManagement works with Tycho. In a nutshell: What you'd like is a pattern that decouples dependency source (to be overriden when necessary) and dependency management. It adds complexity and it is the contrary of what TP do.

I understand the argument, but reading more closely, do you ever think JBoss public repo is going to disappear? I'm guessing it won't and because of that I'm not too worried about this. Also, our snapshots are made available as well (see the caveats in "open source projects." In short, I'm not worried.

----- Original Message ----- > guys - please read up on how maven works and how its recommended to > use. > > http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-p... > > And yeah, I just reread it and there is a nuance where it is "ok": > > If your pom is not going to be referenced by anyone as a dependency > then it is *probably* fine. > > But if it is being used as a framework (afaik switchyard is a such) > then it should *not* be put there since it then affects your users > builds. > > Thus as things are *right* now, jbosstools could probably be ok to > include it - but anyone using our parent pom would have to be > *careful*. > >> I prefer profiles in parent pom to configuration steps & settings >> in a settings.xml because... >> >> ... I don't use a settings.xml file. >> > > you should. > >> ... I'd rather look up how to build something by scanning its >> parent pom for profiles to use than magically determine what to >> put in my settings.xml file. How do I know to resolve against >> JBoss Nexus? > > how do I know which profile to use to build jboss tools ? its not > deducable from the parent pom ;) > > anyway, I know this sucks but its a problem of how maven works so you > can't just put these repositories into your build without > considering the consequences. > > Our use of p2 repositories in pom.xml is a problem too but for that > there is no good workaround :( > >> ... using such a file adds an extra level of job complication when >> running in Jenkins. Using profiles it's easy to run the same >> config in BOTH Jenkins and offline; using settings.xml files >> pretty much guarantees a different bootstrapping step for each >> scenario (ie., either instructions to users on how to edit >> settings.xml or scripting such a process for use in Jenkins). > > Please read the article above. > > Jenkins in jboss.org already has jboss nexus defined so its not a big > issue and you can just add your own settings.xml into the build and > then actually be in control instead of relying on what gets put into > the global settings.xml... > > /max > >> >> N >> >> On 04/11/2012 12:33 PM, Rob Cernich wrote: >>> Perhaps it might be better to use profiles then, instead of >>> settings.xml. Default profile defines the public repo's and can >>> be deactivated for product builds. WDYT? >>> >>> ----- Original Message ----- >>>>>> >>>>>> Since the only usecase for this is to get our current parent >>>>>> snapshots and every other jboss project already require changes >>>>>> to >>>>>> settings.xml i'm not too worried - especially if we can just >>>>>> provide >>>>>> a settings.xml to do it. >>>>> >>>>> Sounds like the right solution is to move the repository >>>>> settings >>>>> down into the individual project parent poms (SwitchYard uses >>>>> this >>>>> approach). That said, if they're all including the same repo, >>>>> it >>>>> makes me wonder if we'd just be jumping through hoops for no >>>>> real >>>>> benefit. >>>> >>>> Any project that needs to go into a product and not infect your >>>> users >>>> pom's will need to remove this reference. >>>> >>>> It is simply wrong to do. And yes it sucks but the consequences >>>> are >>>> rather annoying for those users wanting to do reproducible >>>> builds. >>>> >>>> /max >>>> >>>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com > >

I'm a bit lost: Do you want us to move only the snapshot repo into settings.xml OR both repo to settings,xml ?

Perhaps it might be better to use profiles then, instead of settings.xml. Default profile defines the public repo's and can be deactivated for product builds. WDYT?

----- Original Message ----- >>> >>> Since the only usecase for this is to get our current parent >>> snapshots and every other jboss project already require changes to >>> settings.xml i'm not too worried - especially if we can just >>> provide >>> a settings.xml to do it. >> >> Sounds like the right solution is to move the repository settings >> down into the individual project parent poms (SwitchYard uses this >> approach). That said, if they're all including the same repo, it >> makes me wonder if we'd just be jumping through hoops for no real >> benefit. > > Any project that needs to go into a product and not infect your users > pom's will need to remove this reference. > > It is simply wrong to do. And yes it sucks but the consequences are > rather annoying for those users wanting to do reproducible builds. > > /max > > _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev