Re: [jbosstools-dev] Make the "How To Build" page a favorite in your browser
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