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

[Max Rydahl Andersen]

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

It is not going away but jboss public repo does *not* have enterprise dependencies nor do you wish enterprise users to mix up the productized bits with community bits.

Snapshot development is expected to have to mess with settings.xml.

Note, this is not only a product issue (but it gets very clear here ;), it is also an issue if you are building a project in a company that only allow Maven central repo binaries or for simple buildspeed - for every repo you add there will be one more lookup.

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