On Nov 25, 2013, at 6:21 AM, Karel Piwko <kpiwko(a)redhat.com&gt; wrote: > The original pain was about zip repositories, which would have different > location on every machine. Now, if we want to point user to > maven.repository.redhat.com in our quickstarts/demos, why don't we simply ship > settings.xml as well? > https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?sof... We do. afaict most users want/expect to use the hosted repo. The ones who are interested in a big .zip are typically interested because they *cant* use the hosted repo. The maven .zips To Catherines original email - for GA the FSW installer will offer to update a users settings.xml to point at the hosted repository. Does JBDS not honor settings.xml? I don’t recall having to set anything explicitly in the editor once maven proper was correctly configured. > Karel > > On Sun, 24 Nov 2013 12:59:18 +0100 > Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > >> If we do this we should: >> >> a) use the exact same id/url for referenced repositories (this ensures >> mirror settings in settings.xml would just need to be setup once) b) we >> should add comments in the pom.xml saying it is recommended for real projects >> (i.e. not examples) to remove the repository url from the pom.xml (my >> comments below goes in more detail) c) check if i'm right about #a and that >> local pom.xml repositories doesn't simply override settings.xml repository >> definitions making it even harder to use ;/ Note, users trying the archetypes >> need to add the reference to settings.xml anyway. >> >> btw. if the repository is *not* defined in settings.xml tools can't check if >> things are setup correctly...thats why a and c are important to get >> tested/verified. >> >> /max >> >> On Fri, Nov 22, 2013 at 01:51:29PM -0500, Sande Gilda wrote: >>> When I took over the Maven documentation for EAP 6.0 Development >>> Guide, I remember this came up. The original writer had written: >>> >>> "Red Hat recommends configuring the Maven repository in your project's >>> pom.xml file so the configuration applies regardless of where the project >>> is built." This is as opposed to using the Maven settings." >>> >>> Max responded: >>> >>> This recommendation is broken standing on its own. >>> >>> Read:http://www.sonatype.com/people/2009/02/why-putting-repositories-in-y... >>> >>> We don't even do this for our own products and with good reasons. >>> >>> I know some projects do still do this but it has to be done very >>> carefully. >>> >>> All the arguments is in the blog from Sonatype. >>> >>> Thus in my opinion we should say something like: >>> >>> "Red Hat recommends configuration the Maven repository in your >>> settings.xml and only place the repositories in your pom.xml if you >>> understand the consequence of doing so, see <linktosontaypeblog>" "For a >>> team the simplest way is to host the maven repository on a shared webserver >>> or use a repository manager such as Nexus or Artifactory and use these >>> settings in their ~/.m2/settings.xml" >>> >>> These were additional comments by Max: >>> >>> * It limits what a developer can do to optimize the build process . >>> * If the customer is putting this into a pom that is referred to by >>> other projects he can actually "inject" this repository into other >>> users/customers builds which expect their builds to use nothing but >>> their hosted repository. >>> >>> >>> I can forward the email if you like. >>> >>> On 11/22/2013 12:07 PM, Pete Muir wrote: >>>> With JBDS it’s not too bad, as it fixes your settings.xml for you. I agree >>>> with Max here, there is no way to magically do the fix. >>>> >>>> The only way I’m aware off, to make this transparent, is to embed the >>>> repository definition into the POM. However this is generally regarded as >>>> an anti-pattern in Maven... >>>> >>>> >>>> On 22 Nov 2013, at 16:57, Catherine Robson <crobson(a)redhat.com&gt; wrote: >>>> >>>>> Thanks for sending this Pete, this was on my list of things to follow up >>>>> on after seeing the FSW experience. >>>>> >>>>> Is there any way to bundle these dependencies in with the tooling the >>>>> users download, and would this solve the problem for all products? >>>>> >>>>> The experience now: >>>>> - download JBDS >>>>> - get specific tooling for product >>>>> - go fix maven w/ a new settings.xml file >>>>> - use quickstarts and projects >>>>> >>>>> Would like to see it back to: >>>>> - download JBDS >>>>> - get specific tooling for product (has maven stuff build into it to 'just >>>>> work'?) >>>>> - use quickstarts and examples >>>>> >>>>> Feel free to point out if I'm missing something. Maven is still a crazy >>>>> black box to me - so I definitely might not understand all the >>>>> implications! >>>>> >>>>> - Catherine >>>>> >>>>> Pete Muir wrote: >>>>>> Hi all, >>>>>> >>>>>> As we move our resources to target product, where the dependencies of the >>>>>> projects are not in Maven Central (nor can be, for legal reasons), we hit >>>>>> a usability problem if we require users to set up their settings.xml >>>>>> correctly first. This is not a good “getting started” experience. >>>>>> >>>>>> Therefore, I would like to reopen the question of whether we should >>>>>> consider putting maven.repository.redhat.com into our quickstart, example >>>>>> and demo POMs as a standard practice. >>>>>> >>>>>> I would also like to see if any clever people have other ideas about how >>>>>> to address this as well :-) >>>>>> >>>>>> Pete >>>>>> >>>> >>> >> > >