This was the email discussing the cons.... -------- Original Message -------- Subject: Re: Maven Configuration - preferred method Date: Thu, 26 Apr 2012 18:50:57 +0200 From: Max Rydahl Andersen <max.andersen(a)redhat.com&gt; To: Sande Gilda <sgilda(a)redhat.com&gt; CC: Burr Sutter <bsutter(a)redhat.com&gt;, Pete Muir <pmuir(a)redhat.com&gt;, Paul Gier <pgier(a)redhat.com&gt;, jboss-developer-usability-internal(a)redhat.com > I have inherited some Maven configuration documentation and am trying to verify a statement that was made in a topic on how to configure the project POM file to use the JBoss EAP Maven Repository. > > It basically says: > "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. 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" > Here are my questions: > • Is the really the preferred and recommended configuration? This would only work if the repository is stored on a shared server. If the repository is installed on the local file system, this wouldn't work. Yes, exactly. > • For distributed development, it seems like it limits what a developer can do to optimize the build process. Yup. plus 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. > What should we be recommending here? Maven settings or project POM? Or does it just depend? Should we be recommending anything?

Hi, > For our products we have the obligation to keep it for 5 years, so we > already can't change the repo URL. Plus the fact that our quickstarts are > not available through the Maven Central. Is this the same as not changing our maven repository URL to remove the "techpreview" in the path? Or the same way that we're stuck with not being able to remove the old JDF site that is referenced in the EAP quickstarts? Thanks, J

On 27 Aug 2014, at 15:37, Rafael Benevides wrote: > After reading it I have some more reasons to think that we should do it. > > The blog isn't totally against. It says: "The short answer is: > settings. The long answer is: it depends." Since I was the one being referenced let me summarize too: It is just bad period for any widely publically shared pom to add additional repositories since it will change any downstream projects using it. That is why we say it should not be in any of the product runtime POM, BOM's etc. For examples and quickstarts there is the crucial difference that these pom's are *not* intended to be shared by other projects thus it is less of an issue and we in that thread and others weighted that the out-of-box usability was greater than the proper best practice since these pom's are *not* to be used/shared by other projects. > The main reason that they identify is that " The entries you have > defined will be burned forever into your released POMs. This means > that, should the URLs change down the road, anyone consuming your > POMs will face these broken URLs and have to track down the new ones > manually." Right now we are looking at the repository url changing multiple times (/earlyaccess/all, /techpreview/all, /all) for examples so things are changing (unfortunately) > For our products we have the obligation to keep it for 5 years, so we > already can't change the repo URL. Plus the fact that our quickstarts > are not available through the Maven Central. don't know where you get 5 years from - they need to be much longer. > The blog itself also says: " If you are exposing your source and want > to make it easy for others to build, then consider adding a > repository entry to your POM, but don’t pick a URL lightly, think > long-term, and use a URL that will always be under your control. If > your URL has to change down the road, make sure that you will always > be able to track 404s and write the appropriate mod_rewrite rules to > ensure that future builds will be able to find the appropriate > artifacts." > > Maybe I can be trying to convince myself, but what we're trying to > achieve is "exposing your our source and want to make it easy for > others to build" Look under the "Open Source Projects" - those are the concerns we are under. The article is talking more about it being more okey for your inhouse stuff. Anyway - I believe for the released runtime pom's we cnanot add the repository urls but for the quickstart examples it is okey because of the usability aspect. /max > Em 8/27/14, 8:52, Sande Gilda escreveu: >> This was the email discussing the cons.... >> >> >> -------- Original Message -------- >> Subject: Re: Maven Configuration - preferred method >> Date: Thu, 26 Apr 2012 18:50:57 +0200 >> From: Max Rydahl Andersen <max.andersen(a)redhat.com&gt; >> To: Sande Gilda <sgilda(a)redhat.com&gt; >> CC: Burr Sutter <bsutter(a)redhat.com&gt;, Pete Muir >> <pmuir(a)redhat.com&gt;, Paul Gier <pgier(a)redhat.com&gt;, >> jboss-developer-usability-internal(a)redhat.com >> >> >> >> > I have inherited some Maven configuration documentation and am >> trying to verify a statement that was made in a topic on how to >> configure the project POM file to use the JBoss EAP Maven Repository. >> > >> > It basically says: >> > "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. >> >> 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" >> >> > Here are my questions: >> > • Is the really the preferred and recommended configuration? >> This would only work if the repository is stored on a shared server. >> If the repository is installed on the local file system, this >> wouldn't work. >> >> Yes, exactly. >> >> > • For distributed development, it seems like it limits what a >> developer can do to optimize the build process. >> >> Yup. >> >> plus 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. >> >> > What should we be recommending here? Maven settings or project >> POM? Or does it just depend? Should we be recommending anything? >> >> >> >> > > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper /max http://about.me/maxandersen

We need also to consider that the actual generated project by the latests Archetypes already uses <repository /> on its pom.xml. So I assume that we're already somehow encouraging them to do it. More inline.. Em 8/27/14, 13:26, Sande Gilda escreveu: >> For our products we have the obligation to keep it for 5 years, so >> we already can't change the repo URL. Plus the fact that our >> quickstarts are not available through the Maven Central. > don't know where you get 5 years from - they need to be much longer. You're right. If we consider the ELS of some products it can easily get more than 10 years! > Anyway - I believe for the released runtime pom's we cnanot add the > repository urls but for the quickstart examples it is okey because of > the usability aspect. > +1 > /max

It was changed on this commit at 11 Feb 2014 for EAP 6.2 : https://github.com/jboss-developer/jboss-eap-archetypes/commit/e9b78e807d... After that I sent several emails asking about the Archetype productization release process and had no replies. So we haven't any archetypes releases (but -build-x) after that as you can see at: https://github.com/jboss-developer/jboss-eap-archetypes/commits/6.2.x-dev... Em 9/2/14, 11:25, Sande Gilda escreveu: > Rafael, when where the Archetypes changed? The JBoss EAP 6 Java EE Web > Project doesn't do this in JBoss Tools 3.2.x or JBoss Developer Studio > 7.1.GA. > > > On 08/27/2014 01:29 PM, Rafael Benevides wrote: >> We need also to consider that the actual generated project by the >> latests Archetypes already uses <repository /> on its pom.xml. >> >> So I assume that we're already somehow encouraging them to do it. >> >> More inline.. >> >> Em 8/27/14, 13:26, Sande Gilda escreveu: >>>> For our products we have the obligation to keep it for 5 years, so >>>> we already can't change the repo URL. Plus the fact that our >>>> quickstarts are not available through the Maven Central. >>> don't know where you get 5 years from - they need to be much longer. >> You're right. If we consider the ELS of some products it can easily >> get more than 10 years! >>> Anyway - I believe for the released runtime pom's we cnanot add the >>> repository urls but for the quickstart examples it is okey because >>> of the usability aspect. >>> >> +1 >>> /max >> >> >> >> _______________________________________________ jbossdeveloper mailing list jbossdeveloper(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbossdeveloper

Thanks Rafael. That clarifies things. I've always been unclear about the Archetype releases. Do they coincide with the JBoss EAP release cycle or the JBoss Developer release cycle? When do we normally tag and branch? It seems like they are tightly coupled to the quickstarts, so should we be tagging, branching, and releasing them with the quickstarts? On 09/02/2014 10:38 AM, Rafael Benevides wrote: > It was changed on this commit at 11 Feb 2014 for EAP 6.2 : > https://github.com/jboss-developer/jboss-eap-archetypes/commit/e9b78e807d... > > After that I sent several emails asking about the Archetype > productization release process and had no replies. So we haven't any > archetypes releases (but -build-x) after that as you can see at: > https://github.com/jboss-developer/jboss-eap-archetypes/commits/6.2.x-dev... > > > Em 9/2/14, 11:25, Sande Gilda escreveu: >> Rafael, when where the Archetypes changed? The JBoss EAP 6 Java EE >> Web Project doesn't do this in JBoss Tools 3.2.x or JBoss Developer >> Studio 7.1.GA. >> >> >> On 08/27/2014 01:29 PM, Rafael Benevides wrote: >>> We need also to consider that the actual generated project by the >>> latests Archetypes already uses <repository /> on its pom.xml. >>> >>> So I assume that we're already somehow encouraging them to do it. >>> >>> More inline.. >>> >>> Em 8/27/14, 13:26, Sande Gilda escreveu: >>>>> For our products we have the obligation to keep it for 5 years, >>>>> so we already can't change the repo URL. Plus the fact that our >>>>> quickstarts are not available through the Maven Central. >>>> don't know where you get 5 years from - they need to be much longer. >>> You're right. If we consider the ELS of some products it can easily >>> get more than 10 years! >>>> Anyway - I believe for the released runtime pom's we cnanot add >>>> the repository urls but for the quickstart examples it is okey >>>> because of the usability aspect. >>>> >>> +1 >>>> /max >>> >>> >>> >>> >>> >> >

Who does this?

Is this something I should be doing?

The archetypes are still using branch 6.2.x. Looks like we missed 6.3.x. :-(

On 09/02/2014 10:53 AM, Rafael Benevides wrote: > yes. EAP Archetypes should be release together with EAP Quickstart. > > It already happens for WFK Archetypes.. > > Em 9/2/14, 11:50, Sande Gilda escreveu: >> Thanks Rafael. That clarifies things. >> >> I've always been unclear about the Archetype releases. Do they >> coincide with the JBoss EAP release cycle or the JBoss Developer >> release cycle? When do we normally tag and branch? It seems like >> they are tightly coupled to the quickstarts, so should we be >> tagging, branching, and releasing them with the quickstarts? >> >> >> On 09/02/2014 10:38 AM, Rafael Benevides wrote: >>> It was changed on this commit at 11 Feb 2014 for EAP 6.2 : >>> https://github.com/jboss-developer/jboss-eap-archetypes/commit/e9b78e807d... >>> >>> After that I sent several emails asking about the Archetype >>> productization release process and had no replies. So we haven't >>> any archetypes releases (but -build-x) after that as you can see >>> at: >>> https://github.com/jboss-developer/jboss-eap-archetypes/commits/6.2.x-dev... >>> >>> >>> Em 9/2/14, 11:25, Sande Gilda escreveu: >>>> Rafael, when where the Archetypes changed? The JBoss EAP 6 Java EE >>>> Web Project doesn't do this in JBoss Tools 3.2.x or JBoss >>>> Developer Studio 7.1.GA. >>>> >>>> >>>> On 08/27/2014 01:29 PM, Rafael Benevides wrote: >>>>> We need also to consider that the actual generated project by the >>>>> latests Archetypes already uses <repository /> on its pom.xml. >>>>> >>>>> So I assume that we're already somehow encouraging them to do it. >>>>> >>>>> More inline.. >>>>> >>>>> Em 8/27/14, 13:26, Sande Gilda escreveu: >>>>>>> For our products we have the obligation to keep it for 5 years, >>>>>>> so we already can't change the repo URL. Plus the fact that our >>>>>>> quickstarts are not available through the Maven Central. >>>>>> don't know where you get 5 years from - they need to be much >>>>>> longer. >>>>> You're right. If we consider the ELS of some products it can >>>>> easily get more than 10 years! >>>>>> Anyway - I believe for the released runtime pom's we cnanot add >>>>>> the repository urls but for the quickstart examples it is okey >>>>>> because of the usability aspect. >>>>>> >>>>> +1 >>>>>> /max >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >

Em 9/2/14, 17:27, Sande Gilda escreveu: > Who does this? It looks that it is under my responsibility. I though that it was part of the productization procedure as WFK and forgot about this for EAP.

I think we sligthly changed the process to release WFK archetypes around GA release, so I think EAP can handle the release same way. Archetypes need to be derived from final quickstarts commit/tag and should be only in one version - more than 1 release of archetype for the version is confusing for end user IMHO. On 2.9.2014 16:53, Rafael Benevides wrote: > yes. EAP Archetypes should be release together with EAP Quickstart. > > It already happens for WFK Archetypes.. >

Including Paul Gier Em 9/3/14, 8:31, Rafael Benevides escreveu: > +1 > > Paul Gier, > > Will you be happy to handle the EAP Archetypes? We need to release > 6.3.0 Archetypes so I'll be glad to guide you. > > Em 9/3/14, 6:59, Marek Novotny escreveu: >> I think we sligthly changed the process to release WFK archetypes around >> GA release, so I think EAP can handle the release same way. Archetypes >> need to be derived from final quickstarts commit/tag and should be only >> in one version - more than 1 release of archetype for the version is >> confusing for end user IMHO. >> >> On 2.9.2014 16:53, Rafael Benevides wrote: >>> yes. EAP Archetypes should be release together with EAP Quickstart. >>> >>> It already happens for WFK Archetypes.. >>> >> >

Yes, I think prod can release the archetypes along with the other stuff. On 09/03/2014 09:13 AM, Rafael Benevides wrote: > Including Paul Gier > Em 9/3/14, 8:31, Rafael Benevides escreveu: >> +1 >> >> Paul Gier, >> >> Will you be happy to handle the EAP Archetypes? We need to release >> 6.3.0 Archetypes so I'll be glad to guide you. >> >> Em 9/3/14, 6:59, Marek Novotny escreveu: >>> I think we sligthly changed the process to release WFK archetypes around >>> GA release, so I think EAP can handle the release same way. Archetypes >>> need to be derived from final quickstarts commit/tag and should be only >>> in one version - more than 1 release of archetype for the version is >>> confusing for end user IMHO. >>> >>> On 2.9.2014 16:53, Rafael Benevides wrote: >>>> yes. EAP Archetypes should be release together with EAP Quickstart. >>>> >>>> It already happens for WFK Archetypes.. >>>>

On 4 Sep 2014, at 15:27, Rafael Benevides wrote: > Yesterday Paul and I did the release of EAP 6.3.0 Archetypes. > > They're now available at Maven Central and I just commited the > stacks.yaml: > https://github.com/jboss-developer/jboss-stacks/commit/29a753da4 > > From this release the <repository /> is injected at pom.xml of the > archetype generated project as discussed in other threads. cool. where is the easiest way for me to see the injected result ? would like to be sure its using the same id and url as we are in the tools and other places. /max > > Em 9/3/14, 11:15, Paul Gier escreveu: >> Yes, I think prod can release the archetypes along with the other >> stuff. >> >> On 09/03/2014 09:13 AM, Rafael Benevides wrote: >>> Including Paul Gier >>> Em 9/3/14, 8:31, Rafael Benevides escreveu: >>>> +1 >>>> >>>> Paul Gier, >>>> >>>> Will you be happy to handle the EAP Archetypes? We need to release >>>> 6.3.0 Archetypes so I'll be glad to guide you. >>>> >>>> Em 9/3/14, 6:59, Marek Novotny escreveu: >>>>> I think we sligthly changed the process to release WFK archetypes >>>>> around >>>>> GA release, so I think EAP can handle the release same way. >>>>> Archetypes >>>>> need to be derived from final quickstarts commit/tag and should >>>>> be only >>>>> in one version - more than 1 release of archetype for the version is >>>>> confusing for end user IMHO. >>>>> >>>>> On 2.9.2014 16:53, Rafael Benevides wrote: >>>>>> yes. EAP Archetypes should be release together with EAP Quickstart. >>>>>> >>>>>> It already happens for WFK Archetypes.. >>>>>> > > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper /max http://about.me/maxandersen

so a few things: in stacks.yml the id is 'redhat-techpreview-all-repository' and in this patch it is 'jboss-products-ga-repo' but it is still using the techpreview url (/techpreview/all).

I can also see that earlyaccess is now enabled by default on https://github.com/jboss-developer/jboss-eap-quickstarts/commit/358479339... is that expected ?

Anyways: 1) can we agree on aligning the id's ? (just so we are in sync)

2) is it expected the id says 'ga' but the url is not that ?

For #1 we should look at updating that in stacks.yml so we add it with the same id. Before changing stacks.yml I want to be sure #2 was consistent choice we wanted to make for that? ps. we actually also add this repo as a plugin repository - not sure if that matters for you?

/max

Hi Rafael and everyone, Do I need to change the 6.4.x-develop branch of the quickstarts at this point? And if so, what do I need to do?

* Do I need to add the repository to all the POM files?

* Should I update all the README files to mention that it is not a good practice to add the repository to the POM files?

* Should I remove the settings.xml file?

Thanks, Sande On 09/05/2014 07:58 AM, Rafael Benevides wrote: > > Em 9/5/14, 8:47, Max Rydahl Andersen escreveu: >> so a few things: >> >> in stacks.yml the id is 'redhat-techpreview-all-repository' and in >> this patch it is 'jboss-products-ga-repo' but it is still using the >> techpreview url (/techpreview/all). >> > Since the Archtypes were released, should I update the Stacks to ` > jboss-product-repository` for those archtypes only ? Then I update > the patch for 'redhat-techpreview-all-repository' for the next EAP > 6.4 release ? >> I can also see that earlyaccess is now enabled by default on >> https://github.com/jboss-developer/jboss-eap-quickstarts/commit/358479339... >> is that expected ? > I don't know. >> >> Anyways: >> >> 1) can we agree on aligning the id's ? (just so we are in sync) > Yeap. For sure! I'll update the patch file now for to > 'redhat-techpreview-all-repository' as I just said.. >> >> 2) is it expected the id says 'ga' but the url is not that ? > > Once that we change to ' redhat-techpreview-all-repository' it won't > matter anymore. >> >> For #1 we should look at updating that in stacks.yml so we add it >> with the same id. >> >> Before changing stacks.yml I want to be sure #2 was consistent >> choice we wanted to make for that? >> >> ps. we actually also add this repo as a plugin repository - not sure >> if that matters for you? > I don't think it matters since the tests worked fine. > > So that's my plan: > > 1 - Update the patch file to use 'redhat-techpreview-all-repository' > as repo id instead of 'jboss-products-ga-repo'. It will be available > for next EAP 6.4 Archtype release. > > 2 - Wait for your answer if we should update stacks.yaml repo to ' > jboss-products-ga-repo' for EAP 6.3 Archetypes only > > Is that right ? >> >> /max > > > > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper