[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