[jbosstools-dev] Make the "How To Build" page a favorite in your browser

Max Rydahl Andersen max.andersen at redhat.com
Fri Apr 13 03:46:16 EDT 2012


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-poms-is-a-bad-idea/

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 at 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




More information about the jbosstools-dev mailing list