From pgier at redhat.com Thu Apr 9 11:46:57 2015 From: pgier at redhat.com (Paul Gier) Date: Thu, 09 Apr 2015 10:46:57 -0500 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 Message-ID: <55269EF1.6090702@redhat.com> Hi Everyone, I'd like to propose that we consolidate our current JBoss EAP BOMs into a single BOM. We currently have several smallish BOMs with names like "jboss-javaee-6.0-with-hibernate" and "jboss-javaee-6.0-with-security". Instead I think we could make a single BOM which contains all public API jar versions and is used throughout the quickstarts whenever an API is needed. The specs project would continue to provide a JavaEE specs BOM for simple use cases. And the eap BOM project would provide the JavaEE APIs and public EAP specific APIs. Note that using this BOM in a quickstart would not cause the quickstart to download "all" the API jars, the BOM only manages the versions of the jars which have already been added to the dependency tree. The advantage of this is easier maintenance and a simpler configuration for users who currently use more than one of our current BOMs in their application. WDYT? From benevides at redhat.com Thu Apr 9 11:51:38 2015 From: benevides at redhat.com (Rafael Benevides) Date: Thu, 09 Apr 2015 11:51:38 -0400 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <55269EF1.6090702@redhat.com> References: <55269EF1.6090702@redhat.com> Message-ID: <5526A00A.5080705@redhat.com> Since our JBoss Developer Materials BOMs are aligned with a single product I don't have any objections on it. Does anyone have any? It also can be included as part of EAP build. If we move forward, how will we name it? My proposal: org.jboss.bom.eap:jboss-javaee-7.0-bom On 4/9/15 11:46, Paul Gier wrote: > Hi Everyone, > > I'd like to propose that we consolidate our current JBoss EAP BOMs into > a single BOM. We currently have several smallish BOMs with names like > "jboss-javaee-6.0-with-hibernate" and "jboss-javaee-6.0-with-security". > Instead I think we could make a single BOM which contains all public > API jar versions and is used throughout the quickstarts whenever an API > is needed. > > The specs project would continue to provide a JavaEE specs BOM for > simple use cases. And the eap BOM project would provide the JavaEE APIs > and public EAP specific APIs. Note that using this BOM in a quickstart > would not cause the quickstart to download "all" the API jars, the BOM > only manages the versions of the jars which have already been added to > the dependency tree. > > The advantage of this is easier maintenance and a simpler configuration > for users who currently use more than one of our current BOMs in their > application. > > WDYT? > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper From ozizka at redhat.com Thu Apr 9 18:05:21 2015 From: ozizka at redhat.com (Ondrej Zizka) Date: Fri, 10 Apr 2015 00:05:21 +0200 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <55269EF1.6090702@redhat.com> References: <55269EF1.6090702@redhat.com> Message-ID: <5526F7A1.20908@redhat.com> +1. From user's PoV it's a good step. I was being asked few times on demos which one should choose and whether "all" makes the app bigger etc. Too confusing. Ondra On 9.4.2015 17:46, Paul Gier wrote: > Hi Everyone, > > I'd like to propose that we consolidate our current JBoss EAP BOMs into > a single BOM. We currently have several smallish BOMs with names like > "jboss-javaee-6.0-with-hibernate" and "jboss-javaee-6.0-with-security". > Instead I think we could make a single BOM which contains all public > API jar versions and is used throughout the quickstarts whenever an API > is needed. > > The specs project would continue to provide a JavaEE specs BOM for > simple use cases. And the eap BOM project would provide the JavaEE APIs > and public EAP specific APIs. Note that using this BOM in a quickstart > would not cause the quickstart to download "all" the API jars, the BOM > only manages the versions of the jars which have already been added to > the dependency tree. > > The advantage of this is easier maintenance and a simpler configuration > for users who currently use more than one of our current BOMs in their > application. > > WDYT? > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper From manderse at redhat.com Fri Apr 10 05:03:10 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Fri, 10 Apr 2015 11:03:10 +0200 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <55269EF1.6090702@redhat.com> References: <55269EF1.6090702@redhat.com> Message-ID: I was never a big fan of the separate BOM's but I recall that one of the reasons for this was to allow JDF/WFK quoickstarts to move a bit faster/independent without waiting for the full overall BOM pom to be ready ? Will that no longer be an issue ? /max > Hi Everyone, > > I'd like to propose that we consolidate our current JBoss EAP BOMs > into > a single BOM. We currently have several smallish BOMs with names like > "jboss-javaee-6.0-with-hibernate" and > "jboss-javaee-6.0-with-security". > Instead I think we could make a single BOM which contains all public > API jar versions and is used throughout the quickstarts whenever an > API > is needed. > > The specs project would continue to provide a JavaEE specs BOM for > simple use cases. And the eap BOM project would provide the JavaEE > APIs > and public EAP specific APIs. Note that using this BOM in a > quickstart > would not cause the quickstart to download "all" the API jars, the BOM > only manages the versions of the jars which have already been added to > the dependency tree. > > The advantage of this is easier maintenance and a simpler > configuration > for users who currently use more than one of our current BOMs in their > application. > > WDYT? > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper /max http://about.me/maxandersen From pmuir at redhat.com Fri Apr 10 05:58:39 2015 From: pmuir at redhat.com (Pete Muir) Date: Fri, 10 Apr 2015 10:58:39 +0100 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <55269EF1.6090702@redhat.com> References: <55269EF1.6090702@redhat.com> Message-ID: +1 > On 9 Apr 2015, at 16:46, Paul Gier wrote: > > Hi Everyone, > > I'd like to propose that we consolidate our current JBoss EAP BOMs into > a single BOM. We currently have several smallish BOMs with names like > "jboss-javaee-6.0-with-hibernate" and "jboss-javaee-6.0-with-security". > Instead I think we could make a single BOM which contains all public > API jar versions and is used throughout the quickstarts whenever an API > is needed. > > The specs project would continue to provide a JavaEE specs BOM for > simple use cases. And the eap BOM project would provide the JavaEE APIs > and public EAP specific APIs. Note that using this BOM in a quickstart > would not cause the quickstart to download "all" the API jars, the BOM > only manages the versions of the jars which have already been added to > the dependency tree. > > The advantage of this is easier maintenance and a simpler configuration > for users who currently use more than one of our current BOMs in their > application. > > WDYT? > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper From pmuir at redhat.com Fri Apr 10 05:58:53 2015 From: pmuir at redhat.com (Pete Muir) Date: Fri, 10 Apr 2015 10:58:53 +0100 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: References: <55269EF1.6090702@redhat.com> Message-ID: <3A7D51A2-39A2-4D41-8099-73F890308BA7@redhat.com> I don?t think this is an issue any more. > On 10 Apr 2015, at 10:03, Max Rydahl Andersen wrote: > > I was never a big fan of the separate BOM's but I recall that one of the > reasons for this > was to allow JDF/WFK quoickstarts to move a bit faster/independent > without waiting for the full > overall BOM pom to be ready ? > > Will that no longer be an issue ? > > /max > >> Hi Everyone, >> >> I'd like to propose that we consolidate our current JBoss EAP BOMs >> into >> a single BOM. We currently have several smallish BOMs with names like >> "jboss-javaee-6.0-with-hibernate" and >> "jboss-javaee-6.0-with-security". >> Instead I think we could make a single BOM which contains all public >> API jar versions and is used throughout the quickstarts whenever an >> API >> is needed. >> >> The specs project would continue to provide a JavaEE specs BOM for >> simple use cases. And the eap BOM project would provide the JavaEE >> APIs >> and public EAP specific APIs. Note that using this BOM in a >> quickstart >> would not cause the quickstart to download "all" the API jars, the BOM >> only manages the versions of the jars which have already been added to >> the dependency tree. >> >> The advantage of this is easier maintenance and a simpler >> configuration >> for users who currently use more than one of our current BOMs in their >> application. >> >> WDYT? >> _______________________________________________ >> jbossdeveloper mailing list >> jbossdeveloper at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbossdeveloper > > > /max > http://about.me/maxandersen > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper From sgilda at redhat.com Fri Apr 10 07:38:02 2015 From: sgilda at redhat.com (Sande Gilda) Date: Fri, 10 Apr 2015 07:38:02 -0400 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <55269EF1.6090702@redhat.com> References: <55269EF1.6090702@redhat.com> Message-ID: <5527B61A.6020600@redhat.com> It would certainly simplify things, not only for the quickstarts, but also for documentation.. :-) On 04/09/2015 11:46 AM, Paul Gier wrote: > Hi Everyone, > > I'd like to propose that we consolidate our current JBoss EAP BOMs into > a single BOM. We currently have several smallish BOMs with names like > "jboss-javaee-6.0-with-hibernate" and "jboss-javaee-6.0-with-security". > Instead I think we could make a single BOM which contains all public > API jar versions and is used throughout the quickstarts whenever an API > is needed. > > The specs project would continue to provide a JavaEE specs BOM for > simple use cases. And the eap BOM project would provide the JavaEE APIs > and public EAP specific APIs. Note that using this BOM in a quickstart > would not cause the quickstart to download "all" the API jars, the BOM > only manages the versions of the jars which have already been added to > the dependency tree. > > The advantage of this is easier maintenance and a simpler configuration > for users who currently use more than one of our current BOMs in their > application. > > WDYT? > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper From benevides at redhat.com Fri Apr 10 09:28:22 2015 From: benevides at redhat.com (Rafael Benevides) Date: Fri, 10 Apr 2015 09:28:22 -0400 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <5527B61A.6020600@redhat.com> References: <55269EF1.6090702@redhat.com> <5527B61A.6020600@redhat.com> Message-ID: <5527CFF6.7090703@redhat.com> I was thinking a little bit more about the naming. Actually we use org.jboss.bom.:jboss-javaee-6.0-with-. Examples - org.jboss.bom.eap:jboss-javaee-6.0-with-security - org.jboss.bom.eap:jboss-javaee-6.0-with-tools - org.jboss.bom.brms:jboss-javaee-6.0-with-drools - org.jboss.bom.jdg:jboss-javaee-6.0-with-infinispan. My proposal is to return the groupId to org.jboss.bom and use org.jboss.bom:jboss-javaee-7.0- Examples: - org.jboss.bom:jboss-javaee-7.0-eap - org.jboss.bom:jboss-javaee-7.0-brms - org.jboss.bom:jboss-javaee-7.0-jdg On 4/10/15 07:38, Sande Gilda wrote: > It would certainly simplify things, not only for the quickstarts, but > also for documentation.. :-) > > On 04/09/2015 11:46 AM, Paul Gier wrote: >> Hi Everyone, >> >> I'd like to propose that we consolidate our current JBoss EAP BOMs into >> a single BOM. We currently have several smallish BOMs with names like >> "jboss-javaee-6.0-with-hibernate" and "jboss-javaee-6.0-with-security". >> Instead I think we could make a single BOM which contains all public >> API jar versions and is used throughout the quickstarts whenever an API >> is needed. >> >> The specs project would continue to provide a JavaEE specs BOM for >> simple use cases. And the eap BOM project would provide the JavaEE APIs >> and public EAP specific APIs. Note that using this BOM in a quickstart >> would not cause the quickstart to download "all" the API jars, the BOM >> only manages the versions of the jars which have already been added to >> the dependency tree. >> >> The advantage of this is easier maintenance and a simpler configuration >> for users who currently use more than one of our current BOMs in their >> application. >> >> WDYT? >> _______________________________________________ >> jbossdeveloper mailing list >> jbossdeveloper at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbossdeveloper > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper From sgilda at redhat.com Fri Apr 10 09:33:55 2015 From: sgilda at redhat.com (Sande Gilda) Date: Fri, 10 Apr 2015 09:33:55 -0400 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <5527CFF6.7090703@redhat.com> References: <55269EF1.6090702@redhat.com> <5527B61A.6020600@redhat.com> <5527CFF6.7090703@redhat.com> Message-ID: <5527D143.4060404@redhat.com> Rafael, I really like that naming scheme. It's easier to see the product. :-) On 04/10/2015 09:28 AM, Rafael Benevides wrote: > I was thinking a little bit more about the naming. > > Actually we use > > org.jboss.bom.:jboss-javaee-6.0-with-. > > Examples > - org.jboss.bom.eap:jboss-javaee-6.0-with-security > - org.jboss.bom.eap:jboss-javaee-6.0-with-tools > - org.jboss.bom.brms:jboss-javaee-6.0-with-drools > - org.jboss.bom.jdg:jboss-javaee-6.0-with-infinispan. > > My proposal is to return the groupId to org.jboss.bom and use > org.jboss.bom:jboss-javaee-7.0- > > Examples: > - org.jboss.bom:jboss-javaee-7.0-eap > - org.jboss.bom:jboss-javaee-7.0-brms > - org.jboss.bom:jboss-javaee-7.0-jdg > > > On 4/10/15 07:38, Sande Gilda wrote: >> It would certainly simplify things, not only for the quickstarts, but >> also for documentation.. :-) >> >> On 04/09/2015 11:46 AM, Paul Gier wrote: >>> Hi Everyone, >>> >>> I'd like to propose that we consolidate our current JBoss EAP BOMs into >>> a single BOM. We currently have several smallish BOMs with names like >>> "jboss-javaee-6.0-with-hibernate" and "jboss-javaee-6.0-with-security". >>> Instead I think we could make a single BOM which contains all public >>> API jar versions and is used throughout the quickstarts whenever an API >>> is needed. >>> >>> The specs project would continue to provide a JavaEE specs BOM for >>> simple use cases. And the eap BOM project would provide the JavaEE >>> APIs >>> and public EAP specific APIs. Note that using this BOM in a quickstart >>> would not cause the quickstart to download "all" the API jars, the BOM >>> only manages the versions of the jars which have already been added to >>> the dependency tree. >>> >>> The advantage of this is easier maintenance and a simpler configuration >>> for users who currently use more than one of our current BOMs in their >>> application. >>> >>> WDYT? >>> _______________________________________________ >>> jbossdeveloper mailing list >>> jbossdeveloper at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >> _______________________________________________ >> jbossdeveloper mailing list >> jbossdeveloper at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbossdeveloper > From manderse at redhat.com Mon Apr 13 07:39:51 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 13 Apr 2015 13:39:51 +0200 Subject: [jbossdeveloper] Fwd: [Website] - Current state of forums - Neglect, spam and blocking genuine participation, can someone from .org team help? [nzpb2z-1py-jtgf] References: <2-924639-3-2104-1428822171493.jivesbs.jivemailuser@https://developer.jboss.org> Message-ID: <8CF308A2-A3DF-402C-8BCE-47C83167EC29@redhat.com> Jaikirian with a post with some good points about the spam levels at jboss.org ;/ Mark N./jboss.org - are we really this powerless in fighting this ? either by installing filters or handing out moderation abilities to more users ? Currently it seems most of what we do (maximum post rate on newcomer) is hurting real newcomers ability to engage rather than helping filtering spams.. I know its a loosing battle, but just interested to know if we are doing or planning something beyond "manually deleting spam" ? /max http://about.me/maxandersen Forwarded message: > From: jaikiran pai > To: Max Rydahl Andersen > Subject: [Website] - Current state of forums - Neglect, spam and > blocking genuine participation, can someone from .org team help? > [nzpb2z-1py-jtgf] > Date: Sun, 12 Apr 2015 03:03:00 -0400 > > jaikiran pai > [https://developer.jboss.org/people/jaikiran?et=watches.email.thread] > created the discussion > "Current state of forums - Neglect, spam and blocking genuine > participation, can someone from .org team help?" > > To view the discussion, visit: > https://developer.jboss.org/message/924639?et=watches.email.thread#924639 > > -------------------------------------------------------------- > This is not a new issue, but something that (sadly) has been around > for a long while now. The forums hosted at developer.jboss.org have > been constantly spammed and in general the forums themselves have been > neglected. Genuine activity/participation in the forums has > drastically decreased over the years. To give you an example of the > kind of content (spam) that the forums currently attract, take a look > at the attached screenshots which are from the "Recent discussions" > and the "latest content" widget/pages. All spam (except a thread or > two)! > > The more worrying sign is that there seems to be absolutely no one > (other than community volunteers) with the right set of control (i.e. > Jive admin related controls) from the .org team, who seem to monitor > these forums and nip this spam in the bud. The community volunteers > occasionally mark these threads as spam but one can't expect them to > be able to handle this amount of spam on their own. > > In the past, when I was employed at Red Hat, I had raised this issue > numerous times and the jboss.org was helpful enough to add a very > basic spam filter to the forums. Unfortunately, that has helped only > marginally and in fact on many occasions caused problems to genuine > users (see these threads for what I mean > https://developer.jboss.org/thread/248640 One post per hour > https://developer.jboss.org/thread/240315 Disable Frequency Limit > https://developer.jboss.org/thread/237908 Rate Limiting). > > If you look at the current bunch of spam, it's very clear that it's a > scripted attack (take a look at the timing on the posts). I am a > moderator in one other very popular Java forum on the internet and > that one is fully driven by volunteers including managing the servers > and the software. Yet, we have far better control on spam. In fact, > you hardly find spam in those forums because we nip them in the bud > with various tools and more importantly with the intention and > dedication of keeping the forums active and lively with genuine > participation. I find it hard to believe that these professional > forums at jboss.org, overs these past years, have constantly allowed > this kind of spam to continue, yet at the same time haven't addressed > concerns where genuine participation has been blocked. > > Could someone from the .org team please take care of these issues and > get rid of spam and at the same time allow genuine participation to > continue? Hopefully someone from the team is allocated to keep a watch > on activities like these on a ongoing basis instead of someone from > the community constantly bringing this up every few weeks. > -------------------------------------------------------------- > > Reply to this message by replying to this email, or go to the > discussion on JBoss Developer > [https://developer.jboss.org/message/924639?et=watches.email.thread#924639] > > Start a new discussion in Website at JBoss Developer > [https://developer.jboss.org/choose-container.jspa?contentType=1&containerType=14&container=2008&et=watches.email.thread] > > > > --end-- From manderse at redhat.com Mon Apr 13 08:34:08 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 13 Apr 2015 14:34:08 +0200 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <5527CFF6.7090703@redhat.com> References: <55269EF1.6090702@redhat.com> <5527B61A.6020600@redhat.com> <5527CFF6.7090703@redhat.com> Message-ID: <36321398-5C6C-40AB-8EB1-971FBDCABFF6@redhat.com> On 10 Apr 2015, at 15:28, Rafael Benevides wrote: > I was thinking a little bit more about the naming. > > Actually we use > > org.jboss.bom.:jboss-javaee-6.0-with-. > > Examples > - org.jboss.bom.eap:jboss-javaee-6.0-with-security > - org.jboss.bom.eap:jboss-javaee-6.0-with-tools > - org.jboss.bom.brms:jboss-javaee-6.0-with-drools > - org.jboss.bom.jdg:jboss-javaee-6.0-with-infinispan. > > My proposal is to return the groupId to org.jboss.bom and use > org.jboss.bom:jboss-javaee-7.0- > > Examples: > - org.jboss.bom:jboss-javaee-7.0-eap > - org.jboss.bom:jboss-javaee-7.0-brms > - org.jboss.bom:jboss-javaee-7.0-jdg unless there are small tiny differences between these three this seems wrong to leave the actual difference to be in the qualifier of the version. Having the group artefact be different seem to be the right approach (at least following standard maven conventions ?) /max http://about.me/maxandersen From benevides at redhat.com Mon Apr 13 10:57:34 2015 From: benevides at redhat.com (Rafael Benevides) Date: Mon, 13 Apr 2015 10:57:34 -0400 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <36321398-5C6C-40AB-8EB1-971FBDCABFF6@redhat.com> References: <55269EF1.6090702@redhat.com> <5527B61A.6020600@redhat.com> <5527CFF6.7090703@redhat.com> <36321398-5C6C-40AB-8EB1-971FBDCABFF6@redhat.com> Message-ID: <552BD95E.5040104@redhat.com> Hi Max, I believe that there are small tiny differences between them: - Just the supported managed dependencies. It's like viewing from an "enterprise" perspective: They are all "JBoss BOMs" (groupId) and here are the different products BOMs supported by Red Hat (artifactId) I think it would be too odd if we have: - org.jboss.bom.:jboss-javaee-7.0 (same artifactId for all) or - org.jboss.bom.:jboss-javaee-7.0- On 4/13/15 08:34, Max Rydahl Andersen wrote: > On 10 Apr 2015, at 15:28, Rafael Benevides wrote: > >> I was thinking a little bit more about the naming. >> >> Actually we use >> >> org.jboss.bom.:jboss-javaee-6.0-with-. >> >> Examples >> - org.jboss.bom.eap:jboss-javaee-6.0-with-security >> - org.jboss.bom.eap:jboss-javaee-6.0-with-tools >> - org.jboss.bom.brms:jboss-javaee-6.0-with-drools >> - org.jboss.bom.jdg:jboss-javaee-6.0-with-infinispan. >> >> My proposal is to return the groupId to org.jboss.bom and use >> org.jboss.bom:jboss-javaee-7.0- >> >> Examples: >> - org.jboss.bom:jboss-javaee-7.0-eap >> - org.jboss.bom:jboss-javaee-7.0-brms >> - org.jboss.bom:jboss-javaee-7.0-jdg > > unless there are small tiny differences between these three > this seems wrong to leave the actual difference to be in the qualifier > of the version. > > Having the group artefact be different seem to be the right approach > (at least following > standard maven conventions ?) > > > /max > http://about.me/maxandersen From pgier at redhat.com Mon Apr 13 12:47:23 2015 From: pgier at redhat.com (Paul Gier) Date: Mon, 13 Apr 2015 11:47:23 -0500 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <36321398-5C6C-40AB-8EB1-971FBDCABFF6@redhat.com> References: <55269EF1.6090702@redhat.com> <5527B61A.6020600@redhat.com> <5527CFF6.7090703@redhat.com> <36321398-5C6C-40AB-8EB1-971FBDCABFF6@redhat.com> Message-ID: <552BF31B.2070206@redhat.com> On 04/13/2015 07:34 AM, Max Rydahl Andersen wrote: > On 10 Apr 2015, at 15:28, Rafael Benevides wrote: > >> I was thinking a little bit more about the naming. >> >> Actually we use >> >> org.jboss.bom.:jboss-javaee-6.0-with-. >> >> Examples >> - org.jboss.bom.eap:jboss-javaee-6.0-with-security >> - org.jboss.bom.eap:jboss-javaee-6.0-with-tools >> - org.jboss.bom.brms:jboss-javaee-6.0-with-drools >> - org.jboss.bom.jdg:jboss-javaee-6.0-with-infinispan. >> >> My proposal is to return the groupId to org.jboss.bom and use >> org.jboss.bom:jboss-javaee-7.0- >> >> Examples: >> - org.jboss.bom:jboss-javaee-7.0-eap >> - org.jboss.bom:jboss-javaee-7.0-brms >> - org.jboss.bom:jboss-javaee-7.0-jdg > > unless there are small tiny differences between these three > this seems wrong to leave the actual difference to be in the qualifier > of the version. > > Having the group artefact be different seem to be the right approach (at > least following > standard maven conventions ?) > > > /max > http://about.me/maxandersen I understood Rafael's naming suggestion to be a different artifacId for each. "jboss-javaee-7.0-eap" would be the artifact Id with a version maybe matching the EAP release, so "7.0.0.Beta1" or something. From mnovotny at redhat.com Tue Apr 14 04:49:01 2015 From: mnovotny at redhat.com (Marek Novotny) Date: Tue, 14 Apr 2015 10:49:01 +0200 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <552BF31B.2070206@redhat.com> References: <55269EF1.6090702@redhat.com> <5527B61A.6020600@redhat.com> <5527CFF6.7090703@redhat.com> <36321398-5C6C-40AB-8EB1-971FBDCABFF6@redhat.com> <552BF31B.2070206@redhat.com> Message-ID: <552CD47D.5080304@redhat.com> On 13.4.2015 18:47, Paul Gier wrote: >> >> Examples: >> >> - org.jboss.bom:jboss-javaee-7.0-eap >> >> - org.jboss.bom:jboss-javaee-7.0-brms >> >> - org.jboss.bom:jboss-javaee-7.0-jdg > > > > unless there are small tiny differences between these three > > this seems wrong to leave the actual difference to be in the qualifier > > of the version. @Max, Rafael suggested to add a product string into artifact name not in version string as qualifier AFAIU. -- Marek Novotny -- WFK and Seam Product Lead Red Hat Czech s.r.o. Purkynova 99 612 45 Brno From manderse at redhat.com Tue Apr 14 06:04:43 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 14 Apr 2015 12:04:43 +0200 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <552BD95E.5040104@redhat.com> References: <55269EF1.6090702@redhat.com> <5527B61A.6020600@redhat.com> <5527CFF6.7090703@redhat.com> <36321398-5C6C-40AB-8EB1-971FBDCABFF6@redhat.com> <552BD95E.5040104@redhat.com> Message-ID: <3F33CE0F-FC2A-4039-8A49-797E72018DD3@redhat.com> On 13 Apr 2015, at 16:57, Rafael Benevides wrote: > Hi Max, > > I believe that there are small tiny differences between them: - Just > the supported managed dependencies. > > It's like viewing from an "enterprise" perspective: They are all > "JBoss BOMs" (groupId) and here are the different products BOMs > supported by Red Hat (artifactId) > > I think it would be too odd if we have: > > - org.jboss.bom.:jboss-javaee-7.0 (same artifactId for > all) This one is to me sensible. You choose your product, and the specific versioned artifact for this group. This is the list that is *owned* by the hence using the group id makes sense IMO. > or > - org.jboss.bom.:jboss-javaee-7.0- This one feels redundant. /max > > On 4/13/15 08:34, Max Rydahl Andersen wrote: >> On 10 Apr 2015, at 15:28, Rafael Benevides wrote: >> >>> I was thinking a little bit more about the naming. >>> >>> Actually we use >>> >>> org.jboss.bom.:jboss-javaee-6.0-with-. >>> >>> Examples >>> - org.jboss.bom.eap:jboss-javaee-6.0-with-security >>> - org.jboss.bom.eap:jboss-javaee-6.0-with-tools >>> - org.jboss.bom.brms:jboss-javaee-6.0-with-drools >>> - org.jboss.bom.jdg:jboss-javaee-6.0-with-infinispan. >>> >>> My proposal is to return the groupId to org.jboss.bom and use >>> org.jboss.bom:jboss-javaee-7.0- >>> >>> Examples: >>> - org.jboss.bom:jboss-javaee-7.0-eap >>> - org.jboss.bom:jboss-javaee-7.0-brms >>> - org.jboss.bom:jboss-javaee-7.0-jdg >> >> unless there are small tiny differences between these three >> this seems wrong to leave the actual difference to be in the >> qualifier of the version. >> >> Having the group artefact be different seem to be the right approach >> (at least following >> standard maven conventions ?) >> >> >> /max >> http://about.me/maxandersen /max http://about.me/maxandersen From manderse at redhat.com Tue Apr 14 06:24:26 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 14 Apr 2015 12:24:26 +0200 Subject: [jbossdeveloper] [Proposal] One BOM for Wildfly/EAP 7 In-Reply-To: <552CD47D.5080304@redhat.com> References: <55269EF1.6090702@redhat.com> <5527B61A.6020600@redhat.com> <5527CFF6.7090703@redhat.com> <36321398-5C6C-40AB-8EB1-971FBDCABFF6@redhat.com> <552BF31B.2070206@redhat.com> <552CD47D.5080304@redhat.com> Message-ID: On 14 Apr 2015, at 10:49, Marek Novotny wrote: > On 13.4.2015 18:47, Paul Gier wrote: >>>>> Examples: >>>>> - org.jboss.bom:jboss-javaee-7.0-eap >>>>> - org.jboss.bom:jboss-javaee-7.0-brms >>>>> - org.jboss.bom:jboss-javaee-7.0-jdg >>> >>> unless there are small tiny differences between these three >>> this seems wrong to leave the actual difference to be in the >>> qualifier >>> of the version. > @Max, Rafael suggested to add a product string into artifact name not > in > version string as qualifier AFAIU. *ah* - I missed that. Damn version numbers in artefact id's ;) I have less of an issue with that - I still think these are more owned by the product than by "bom"-group but that is not something I feel that strongly about. /max http://about.me/maxandersen From benevides at redhat.com Mon Apr 20 11:28:18 2015 From: benevides at redhat.com (Rafael Benevides) Date: Mon, 20 Apr 2015 11:28:18 -0400 Subject: [jbossdeveloper] JBoss Developer Materials Repository Management and Releases Message-ID: <55351B12.1040808@redhat.com> Hi all, After a long time of discussion, I'm sharing with you the updated version of JBoss Developer Material repo management: https://mojo.redhat.com/docs/DOC-928619 The main changes refer to: - The default branch will point to the latest G.A. - There will be the definition inside pom.xml - General clarification on BOM and Archetypes release process. The general purpose of these changes is to allow users and contributors to do: git clone ...; cd ...; mvn clean install without the need to checkout a different branch and/or update maven settings.xml The injection will take place for EAP 7 only. -- *Rafael Benevides | Senior Software Engineer* JBoss Developer M: +1-919-592-6255 Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at www.redhat.com LinkedIn Youtube -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150420/aa6d2f69/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: {a8aabf3a-4467-4e37-9bc5-48b1d7b494a2}_LATAM_RedHat.jpg Type: image/jpeg Size: 4815 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150420/aa6d2f69/attachment.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: linkedin.png Type: image/png Size: 597 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150420/aa6d2f69/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: youtube.png Type: image/png Size: 616 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150420/aa6d2f69/attachment-0001.png From benevides at redhat.com Mon Apr 20 14:39:27 2015 From: benevides at redhat.com (Rafael Benevides) Date: Mon, 20 Apr 2015 14:39:27 -0400 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> Message-ID: <553547DF.8010209@redhat.com> Hi all, The definition in pom.xml was included as part of EAP 7 plan: https://mojo.redhat.com/docs/DOC-1020116 On 11/14/14 07:38, Pete Muir wrote: >> On 14 Nov 2014, at 10:51, Max Rydahl Andersen wrote: >> >>>>> Can you please review https://mojo.redhat.com/docs/DOC-997344 and confirm if those ids are ok. If not, do you mind to place the right information at the document? >>>> sorry for late response. >>>> >>>> Looking at this list the only two repositories I consider valid in production quickstarts >>> production quickstarts aren?t actually a thing :-p >> What word do we use for it then ? it's not community quickstarts since they depend on productized bits. > Product quickstarts. > >>>> are: >>>> >>>> redhat-techpreview-all-repository >>>> http://maven.repository.redhat.com/techpreview/all/ >>>> >>>> redhat-earlyaccess-all-repository (for things not GA) >>>> https://maven.repository.redhat.com/earlyaccess/all/ >>> These ^^^, plus fusesource, are valid for non-earlyaccess quickstarts >> So the earlyaccess repo is valid for non-earlyaccess quickstarts ? seems counterintuitive ? > Yes. A quickstart may be in beta, or a product may be in beta. These things are orthogonal. > >>>> These are I'm surprised we are now letting in: >>>> >>>> Jboss public repo is not something our productized nor project quickstarts should depend on is it ? Was there not a requirement for quickstarts >>>> to *not* rely on this repo that is a big mashup of dependencies and instead only rely on central published artifacts ? >>>> jboss-public-repository >>>> https://repository.jboss.org/nexus/content/groups/public/ >>> This ^^^ is valid only for earlyaccess quickstarts >> ...so earlyaccess quickstarts is even earlier than what is in earlyaccess maven repo ? >> >> Just trying to do the mapping since this is what we call community quickstarts on jboss tools end and we keep it clearly separate from production related stuff >> to avoid/reduce confusion. > Correct. It?s much closer to what you call early access in JBDS - features that aren?t ready to go in to the product yet. > >>>> Fuse reposource repo I thought was only being used for old fuse releases ? If that is no longer the case then that is not great since >>>> it seem to have a lot of redundancy of artifacts. >>>> fuse-public-repository >>>> https://repo.fusesource.com/nexus/content/groups/public >>> It?s still used for Fuse releases AFAIK. >> mkay '/ - i'll try reach Aileen and here what is the plan for it and what is stopping them from getting into maven.repository.redhat.com. >> >>>> This repo I do not understand what is for and should not be exposed anywhere IMO. Only relevant to put in testers own settings.xml is it not ? >>>> jboss-developer-staging-repository >>>> http://jboss-developer.github.io/temp-maven-repo/ >>> Agreed, this one should never appear in a POM. >> +1 >> >> /max >> >>>> About the ID's correctness/alignment with our tools that is something Fred should be able to verify better than I. >>>> >>>> /max >>>> >>>>> Pete/Max, >>>>> >>>>> Do you know if Fuse maven repository still valid ? >>>>> >>>>> >>>>> Thanks >>>>> >>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>> Hi all, >>>>>> >>>>>> I was thinking about the implementation of the repository definition in pom.xml and I want to share my thoughts: >>>>>> >>>>>> - Create a QSTools CHECKER to mark the lack of as a guideline violation if MavenCentralChecker is disabled. >>>>>> - The violation message will instruct to use the new QSTools GOAL that will be created >>>>>> >>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>> - There will be a list of approved repositories and its IDs (redhat techpreview, earlyacess, jboss developer temporary, etc) >>>>>> - QSTools will remove all previous repositories from pom.xml and prompt which repositories should be added. >>>>>> - This will help Quickstarts and demos to be easily buildable from development and production branches and will also allow this list to be bulk updated to remove any previous development repository definition. >>>>>> >>>>>> Please, >>>>>> >>>>>> If you have any feedback on this, feel free to reply. >>>>>> >>>>>> -- >>>>>> >>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>> JBoss Developer >>>>>> M: +55-61-9269-6576 >>>>>> >>>>>> Red Hat >>>>>> >>>>>> Better technology. Faster innovation. Powered by community collaboration. >>>>>> See how it works at www.redhat.com > >>>>>> >>>>>> LinkedIn > Youtube > >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jbossdeveloper mailing list >>>>>> jbossdeveloper at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>> _______________________________________________ >>>>> jbossdeveloper mailing list >>>>> jbossdeveloper at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>> >>>> /max >>>> http://about.me/maxandersen >> >> /max >> http://about.me/maxandersen From benevides at redhat.com Mon Apr 20 16:42:13 2015 From: benevides at redhat.com (Rafael Benevides) Date: Mon, 20 Apr 2015 16:42:13 -0400 Subject: [jbossdeveloper] JBoss Developer Materials Repository Management and Releases In-Reply-To: <55351B12.1040808@redhat.com> References: <55351B12.1040808@redhat.com> Message-ID: <553564A5.6090008@redhat.com> After a discussion with Paul Gier and Sande, We made some minor adjustments. - The default branch will point to the latest -develop branch. The document was updated to reflect this change. On 4/20/15 11:28, Rafael Benevides wrote: > Hi all, > > After a long time of discussion, I'm sharing with you the updated > version of JBoss Developer Material repo management: > https://mojo.redhat.com/docs/DOC-928619 > > The main changes refer to: > > - The default branch will point to the latest G.A. > - There will be the definition inside pom.xml > - General clarification on BOM and Archetypes release process. > > > The general purpose of these changes is to allow users and > contributors to do: git clone ...; cd ...; mvn clean install without > the need to checkout a different branch and/or update maven settings.xml > > The injection will take place for EAP 7 only. > > -- > > *Rafael Benevides | Senior Software Engineer* > JBoss Developer > M: +1-919-592-6255 > > Red Hat > > Better technology. Faster innovation. Powered by community collaboration. > See how it works at www.redhat.com > > LinkedIn Youtube > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150420/e8d71a35/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4815 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150420/e8d71a35/attachment-0001.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 597 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150420/e8d71a35/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 616 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150420/e8d71a35/attachment-0003.png From manderse at redhat.com Tue Apr 21 03:54:31 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 21 Apr 2015 09:54:31 +0200 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: <553547DF.8010209@redhat.com> References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> Message-ID: <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: > Hi all, > > The definition in pom.xml was included as part of EAP 7 > plan: https://mojo.redhat.com/docs/DOC-1020116 I noticed this linked to a link that says a repo named "temp-maven-repo" is in the list of approved repositories ? Is that really intended ? And why is the very global repository.jboss.org/nexus/content/groups/public allowed in here ? We are supposed to *not* depend on that repository in any form of fashion during productisation aren't we ? p.s. I think I've asked the above before so i'm sorry if I forgotten - if there is a good reason I think we should add that in the comments of the qstools-plugin :) /max > > > On 11/14/14 07:38, Pete Muir wrote: >>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen >>> wrote: >>> >>>>>> Can you please review https://mojo.redhat.com/docs/DOC-997344 >>>>>> and confirm if those >>>>>> ids are ok. If not, do you mind to place the right information at >>>>>> the document? >>>>> sorry for late response. >>>>> >>>>> Looking at this list the only two repositories I consider valid in >>>>> production quickstarts >>>> production quickstarts aren?t actually a thing :-p >>> What word do we use for it then ? it's not community quickstarts >>> since they depend on productized bits. >> Product quickstarts. >> >>>>> are: >>>>> >>>>> redhat-techpreview-all-repository >>>>> http://maven.repository.redhat.com/techpreview/all/ >>>>> >>>>> >>>>> redhat-earlyaccess-all-repository (for things not GA) >>>>> https://maven.repository.redhat.com/earlyaccess/all/ >>>>> >>>> These ^^^, plus fusesource, are valid for non-earlyaccess >>>> quickstarts >>> So the earlyaccess repo is valid for non-earlyaccess quickstarts ? >>> seems counterintuitive ? >> Yes. A quickstart may be in beta, or a product may be in beta. These >> things are orthogonal. >> >>>>> These are I'm surprised we are now letting in: >>>>> >>>>> Jboss public repo is not something our productized nor project >>>>> quickstarts should depend on is it ? Was there not a requirement >>>>> for quickstarts >>>>> to *not* rely on this repo that is a big mashup of dependencies >>>>> and instead only rely on central published artifacts ? >>>>> jboss-public-repository >>>>> https://repository.jboss.org/nexus/content/groups/public/ >>>>> >>>> This ^^^ is valid only for earlyaccess quickstarts >>> ...so earlyaccess quickstarts is even earlier than what is in >>> earlyaccess maven repo ? >>> >>> Just trying to do the mapping since this is what we call community >>> quickstarts on jboss tools end and we keep it clearly separate from >>> production related stuff >>> to avoid/reduce confusion. >> Correct. It?s much closer to what you call early access in JBDS - >> features that aren?t ready to go in to the product yet. >> >>>>> Fuse reposource repo I thought was only being used for old fuse >>>>> releases ? If that is no longer the case then that is not great >>>>> since >>>>> it seem to have a lot of redundancy of artifacts. >>>>> fuse-public-repository >>>>> https://repo.fusesource.com/nexus/content/groups/public >>>>> >>>> It?s still used for Fuse releases AFAIK. >>> mkay '/ - i'll try reach Aileen and here what is the plan for it and >>> what is stopping them from getting into maven.repository.redhat.com. >>> >>>>> This repo I do not understand what is for and should not be >>>>> exposed anywhere IMO. Only relevant to put in testers own >>>>> settings.xml is it not ? >>>>> jboss-developer-staging-repository >>>>> http://jboss-developer.github.io/temp-maven-repo/ >>>>> >>>> Agreed, this one should never appear in a POM. >>> +1 >>> >>> /max >>> >>>>> About the ID's correctness/alignment with our tools that is >>>>> something Fred should be able to verify better than I. >>>>> >>>>> /max >>>>> >>>>>> Pete/Max, >>>>>> >>>>>> Do you know if Fuse maven repository still valid ? >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I was thinking about the implementation of the repository >>>>>>> definition in pom.xml and I want to share my thoughts: >>>>>>> >>>>>>> - Create a QSTools CHECKER to mark the lack of as >>>>>>> a guideline violation if MavenCentralChecker is disabled. >>>>>>> - The violation message will instruct to use the new QSTools >>>>>>> GOAL that will be created >>>>>>> >>>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>>> - There will be a list of approved repositories and its IDs >>>>>>> (redhat techpreview, earlyacess, jboss developer temporary, etc) >>>>>>> - QSTools will remove all previous repositories from pom.xml and >>>>>>> prompt which repositories should be added. >>>>>>> - This will help Quickstarts and demos to be easily buildable >>>>>>> from development and production branches and will also allow >>>>>>> this list to be bulk updated to remove any previous development >>>>>>> repository definition. >>>>>>> >>>>>>> Please, >>>>>>> >>>>>>> If you have any feedback on this, feel free to reply. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>>> JBoss Developer >>>>>>> M: +55-61-9269-6576 >>>>>>> >>>>>>> Red Hat >>>>>>> >>>>>>> Better technology. Faster innovation. Powered by community >>>>>>> collaboration. >>>>>>> See how it works at www.redhat.com >>>>>>> > >>>>>>> >>>>>>> LinkedIn >>>>>> > Youtube >>>>>>> >>>>>> > >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jbossdeveloper mailing list >>>>>>> jbossdeveloper at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>> >>>>>> _______________________________________________ >>>>>> jbossdeveloper mailing list >>>>>> jbossdeveloper at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>> >>>>> >>>>> /max >>>>> http://about.me/maxandersen >>> >>> /max >>> http://about.me/maxandersen /max http://about.me/maxandersen From benevides at redhat.com Tue Apr 21 09:32:31 2015 From: benevides at redhat.com (Rafael Benevides) Date: Tue, 21 Apr 2015 09:32:31 -0400 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> Message-ID: <5536516F.5010407@redhat.com> Np, Max. They will be used just "if required" for dependencies that were not released yet because we want/need that the -develop branch should be buildable for Quickstarts contributors. During the productisation procedures, the only repository allowed will be "maven.repository.redhat.com". On 4/21/15 03:54, Max Rydahl Andersen wrote: > On 20 Apr 2015, at 20:39, Rafael Benevides wrote: > >> Hi all, >> >> The definition in pom.xml was included as part of EAP >> 7 plan: https://mojo.redhat.com/docs/DOC-1020116 > > I noticed this linked to a link that says a repo named > "temp-maven-repo" is in the list of approved repositories ? Is that > really intended ? > > And why is the very global > repository.jboss.org/nexus/content/groups/public allowed in here ? We > are supposed to *not* depend on that repository in any form of fashion > during productisation aren't we ? > > p.s. I think I've asked the above before so i'm sorry if I forgotten - > if there is a good reason I think we should add that in the comments > of the qstools-plugin :) > > /max > >> >> >> On 11/14/14 07:38, Pete Muir wrote: >>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen >>>> wrote: >>>> >>>>>>> Can you please review https://mojo.redhat.com/docs/DOC-997344 >>>>>>> and confirm if those >>>>>>> ids are ok. If not, do you mind to place the right information >>>>>>> at the document? >>>>>> sorry for late response. >>>>>> >>>>>> Looking at this list the only two repositories I consider valid >>>>>> in production quickstarts >>>>> production quickstarts aren?t actually a thing :-p >>>> What word do we use for it then ? it's not community quickstarts >>>> since they depend on productized bits. >>> Product quickstarts. >>> >>>>>> are: >>>>>> >>>>>> redhat-techpreview-all-repository >>>>>> http://maven.repository.redhat.com/techpreview/all/ >>>>>> >>>>>> >>>>>> redhat-earlyaccess-all-repository (for things not GA) >>>>>> https://maven.repository.redhat.com/earlyaccess/all/ >>>>>> >>>>> These ^^^, plus fusesource, are valid for non-earlyaccess quickstarts >>>> So the earlyaccess repo is valid for non-earlyaccess quickstarts ? >>>> seems counterintuitive ? >>> Yes. A quickstart may be in beta, or a product may be in beta. These >>> things are orthogonal. >>> >>>>>> These are I'm surprised we are now letting in: >>>>>> >>>>>> Jboss public repo is not something our productized nor project >>>>>> quickstarts should depend on is it ? Was there not a requirement >>>>>> for quickstarts >>>>>> to *not* rely on this repo that is a big mashup of dependencies >>>>>> and instead only rely on central published artifacts ? >>>>>> jboss-public-repository >>>>>> https://repository.jboss.org/nexus/content/groups/public/ >>>>>> >>>>> This ^^^ is valid only for earlyaccess quickstarts >>>> ...so earlyaccess quickstarts is even earlier than what is in >>>> earlyaccess maven repo ? >>>> >>>> Just trying to do the mapping since this is what we call community >>>> quickstarts on jboss tools end and we keep it clearly separate from >>>> production related stuff >>>> to avoid/reduce confusion. >>> Correct. It?s much closer to what you call early access in JBDS - >>> features that aren?t ready to go in to the product yet. >>> >>>>>> Fuse reposource repo I thought was only being used for old fuse >>>>>> releases ? If that is no longer the case then that is not great >>>>>> since >>>>>> it seem to have a lot of redundancy of artifacts. >>>>>> fuse-public-repository >>>>>> https://repo.fusesource.com/nexus/content/groups/public >>>>>> >>>>> It?s still used for Fuse releases AFAIK. >>>> mkay '/ - i'll try reach Aileen and here what is the plan for it >>>> and what is stopping them from getting into >>>> maven.repository.redhat.com. >>>> >>>>>> This repo I do not understand what is for and should not be >>>>>> exposed anywhere IMO. Only relevant to put in testers own >>>>>> settings.xml is it not ? >>>>>> jboss-developer-staging-repository >>>>>> http://jboss-developer.github.io/temp-maven-repo/ >>>>>> >>>>> Agreed, this one should never appear in a POM. >>>> +1 >>>> >>>> /max >>>> >>>>>> About the ID's correctness/alignment with our tools that is >>>>>> something Fred should be able to verify better than I. >>>>>> >>>>>> /max >>>>>> >>>>>>> Pete/Max, >>>>>>> >>>>>>> Do you know if Fuse maven repository still valid ? >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I was thinking about the implementation of the repository >>>>>>>> definition in pom.xml and I want to share my thoughts: >>>>>>>> >>>>>>>> - Create a QSTools CHECKER to mark the lack of >>>>>>>> as a guideline violation if MavenCentralChecker is disabled. >>>>>>>> - The violation message will instruct to use the new QSTools >>>>>>>> GOAL that will be created >>>>>>>> >>>>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>>>> - There will be a list of approved repositories and its IDs >>>>>>>> (redhat techpreview, earlyacess, jboss developer temporary, etc) >>>>>>>> - QSTools will remove all previous repositories from pom.xml >>>>>>>> and prompt which repositories should be added. >>>>>>>> - This will help Quickstarts and demos to be easily buildable >>>>>>>> from development and production branches and will also allow >>>>>>>> this list to be bulk updated to remove any previous development >>>>>>>> repository definition. >>>>>>>> >>>>>>>> Please, >>>>>>>> >>>>>>>> If you have any feedback on this, feel free to reply. >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>>>> JBoss Developer >>>>>>>> M: +55-61-9269-6576 >>>>>>>> >>>>>>>> Red Hat >>>>>>>> >>>>>>>> Better technology. Faster innovation. Powered by community >>>>>>>> collaboration. >>>>>>>> See how it works at www.redhat.com >>>>>>>> > >>>>>>>> >>>>>>>> LinkedIn >>>>>>> > Youtube >>>>>>>> >>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jbossdeveloper mailing list >>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> jbossdeveloper mailing list >>>>>>> jbossdeveloper at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>> >>>>>> >>>>>> /max >>>>>> http://about.me/maxandersen >>>> >>>> /max >>>> http://about.me/maxandersen > > > /max > http://about.me/maxandersen From manderse at redhat.com Tue Apr 21 16:53:55 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Tue, 21 Apr 2015 22:53:55 +0200 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: <5536516F.5010407@redhat.com> References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> <5536516F.5010407@redhat.com> Message-ID: <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> On 21 Apr 2015, at 15:32, Rafael Benevides wrote: > Np, Max. > > They will be used just "if required" for dependencies that were not > released yet because we want/need that the -develop branch should be > buildable for Quickstarts contributors. > > During the productisation procedures, the only repository allowed will > be "maven.repository.redhat.com". ah yes, now I remember. Can you point me to where that is enforced ? https://github.com/jboss-developer/maven-qstools-plugin/blob/master/config/qstools_config.yaml#L24 seem to just be the global list ? /max > On 4/21/15 03:54, Max Rydahl Andersen wrote: >> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: >> >>> Hi all, >>> >>> The definition in pom.xml was included as part of EAP >>> 7 plan: https://mojo.redhat.com/docs/DOC-1020116 >> >> I noticed this linked to a link that says a repo named >> "temp-maven-repo" is in the list of approved repositories ? Is that >> really intended ? >> >> And why is the very global >> repository.jboss.org/nexus/content/groups/public allowed in here ? We >> are supposed to *not* depend on that repository in any form of >> fashion during productisation aren't we ? >> >> p.s. I think I've asked the above before so i'm sorry if I forgotten >> - if there is a good reason I think we should add that in the >> comments of the qstools-plugin :) >> >> /max >> >>> >>> >>> On 11/14/14 07:38, Pete Muir wrote: >>>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen >>>>> wrote: >>>>> >>>>>>>> Can you please review https://mojo.redhat.com/docs/DOC-997344 >>>>>>>> and confirm if those >>>>>>>> ids are ok. If not, do you mind to place the right information >>>>>>>> at the document? >>>>>>> sorry for late response. >>>>>>> >>>>>>> Looking at this list the only two repositories I consider valid >>>>>>> in production quickstarts >>>>>> production quickstarts aren?t actually a thing :-p >>>>> What word do we use for it then ? it's not community quickstarts >>>>> since they depend on productized bits. >>>> Product quickstarts. >>>> >>>>>>> are: >>>>>>> >>>>>>> redhat-techpreview-all-repository >>>>>>> http://maven.repository.redhat.com/techpreview/all/ >>>>>>> >>>>>>> >>>>>>> redhat-earlyaccess-all-repository (for things not GA) >>>>>>> https://maven.repository.redhat.com/earlyaccess/all/ >>>>>>> >>>>>> These ^^^, plus fusesource, are valid for non-earlyaccess >>>>>> quickstarts >>>>> So the earlyaccess repo is valid for non-earlyaccess quickstarts ? >>>>> seems counterintuitive ? >>>> Yes. A quickstart may be in beta, or a product may be in beta. >>>> These things are orthogonal. >>>> >>>>>>> These are I'm surprised we are now letting in: >>>>>>> >>>>>>> Jboss public repo is not something our productized nor project >>>>>>> quickstarts should depend on is it ? Was there not a requirement >>>>>>> for quickstarts >>>>>>> to *not* rely on this repo that is a big mashup of dependencies >>>>>>> and instead only rely on central published artifacts ? >>>>>>> jboss-public-repository >>>>>>> https://repository.jboss.org/nexus/content/groups/public/ >>>>>>> >>>>>> This ^^^ is valid only for earlyaccess quickstarts >>>>> ...so earlyaccess quickstarts is even earlier than what is in >>>>> earlyaccess maven repo ? >>>>> >>>>> Just trying to do the mapping since this is what we call community >>>>> quickstarts on jboss tools end and we keep it clearly separate >>>>> from production related stuff >>>>> to avoid/reduce confusion. >>>> Correct. It?s much closer to what you call early access in JBDS - >>>> features that aren?t ready to go in to the product yet. >>>> >>>>>>> Fuse reposource repo I thought was only being used for old fuse >>>>>>> releases ? If that is no longer the case then that is not great >>>>>>> since >>>>>>> it seem to have a lot of redundancy of artifacts. >>>>>>> fuse-public-repository >>>>>>> https://repo.fusesource.com/nexus/content/groups/public >>>>>>> >>>>>> It?s still used for Fuse releases AFAIK. >>>>> mkay '/ - i'll try reach Aileen and here what is the plan for it >>>>> and what is stopping them from getting into >>>>> maven.repository.redhat.com. >>>>> >>>>>>> This repo I do not understand what is for and should not be >>>>>>> exposed anywhere IMO. Only relevant to put in testers own >>>>>>> settings.xml is it not ? >>>>>>> jboss-developer-staging-repository >>>>>>> http://jboss-developer.github.io/temp-maven-repo/ >>>>>>> >>>>>> Agreed, this one should never appear in a POM. >>>>> +1 >>>>> >>>>> /max >>>>> >>>>>>> About the ID's correctness/alignment with our tools that is >>>>>>> something Fred should be able to verify better than I. >>>>>>> >>>>>>> /max >>>>>>> >>>>>>>> Pete/Max, >>>>>>>> >>>>>>>> Do you know if Fuse maven repository still valid ? >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I was thinking about the implementation of the repository >>>>>>>>> definition in pom.xml and I want to share my thoughts: >>>>>>>>> >>>>>>>>> - Create a QSTools CHECKER to mark the lack of >>>>>>>>> as a guideline violation if MavenCentralChecker is disabled. >>>>>>>>> - The violation message will instruct to use the new QSTools >>>>>>>>> GOAL that will be created >>>>>>>>> >>>>>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>>>>> - There will be a list of approved repositories and its IDs >>>>>>>>> (redhat techpreview, earlyacess, jboss developer temporary, >>>>>>>>> etc) >>>>>>>>> - QSTools will remove all previous repositories from pom.xml >>>>>>>>> and prompt which repositories should be added. >>>>>>>>> - This will help Quickstarts and demos to be easily buildable >>>>>>>>> from development and production branches and will also allow >>>>>>>>> this list to be bulk updated to remove any previous >>>>>>>>> development repository definition. >>>>>>>>> >>>>>>>>> Please, >>>>>>>>> >>>>>>>>> If you have any feedback on this, feel free to reply. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>>>>> JBoss Developer >>>>>>>>> M: +55-61-9269-6576 >>>>>>>>> >>>>>>>>> Red Hat >>>>>>>>> >>>>>>>>> Better technology. Faster innovation. Powered by community >>>>>>>>> collaboration. >>>>>>>>> See how it works at www.redhat.com >>>>>>>>> > >>>>>>>>> >>>>>>>>> LinkedIn >>>>>>>> > Youtube >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> jbossdeveloper mailing list >>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jbossdeveloper mailing list >>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>> >>>>>>> >>>>>>> /max >>>>>>> http://about.me/maxandersen >>>>> >>>>> /max >>>>> http://about.me/maxandersen >> >> >> /max >> http://about.me/maxandersen /max http://about.me/maxandersen From benevides at redhat.com Tue Apr 21 17:20:40 2015 From: benevides at redhat.com (Rafael Benevides) Date: Tue, 21 Apr 2015 17:20:40 -0400 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> <5536516F.5010407@redhat.com> <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> Message-ID: <5536BF28.8070609@redhat.com> This is enforced by QE. I don't know what they use to do that but maybe Paul Gier or Marek N can answer that (I'm copying them). QSTools provides a GUI for add/remove these repositories but it needs a human interaction to choose the proper ones. On 4/21/15 16:53, Max Rydahl Andersen wrote: > On 21 Apr 2015, at 15:32, Rafael Benevides wrote: > >> Np, Max. >> >> They will be used just "if required" for dependencies that were not >> released yet because we want/need that the -develop branch should be >> buildable for Quickstarts contributors. >> >> During the productisation procedures, the only repository allowed >> will be "maven.repository.redhat.com". > > ah yes, now I remember. > > Can you point me to where that is enforced ? > https://github.com/jboss-developer/maven-qstools-plugin/blob/master/config/qstools_config.yaml#L24 > seem to just be the global list ? > > /max > >> On 4/21/15 03:54, Max Rydahl Andersen wrote: >>> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: >>> >>>> Hi all, >>>> >>>> The definition in pom.xml was included as part of >>>> EAP 7 plan: https://mojo.redhat.com/docs/DOC-1020116 >>> >>> I noticed this linked to a link that says a repo named >>> "temp-maven-repo" is in the list of approved repositories ? Is that >>> really intended ? >>> >>> And why is the very global >>> repository.jboss.org/nexus/content/groups/public allowed in here ? >>> We are supposed to *not* depend on that repository in any form of >>> fashion during productisation aren't we ? >>> >>> p.s. I think I've asked the above before so i'm sorry if I forgotten >>> - if there is a good reason I think we should add that in the >>> comments of the qstools-plugin :) >>> >>> /max >>> >>>> >>>> >>>> On 11/14/14 07:38, Pete Muir wrote: >>>>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen >>>>>> wrote: >>>>>> >>>>>>>>> Can you please review https://mojo.redhat.com/docs/DOC-997344 >>>>>>>>> and confirm if those >>>>>>>>> ids are ok. If not, do you mind to place the right information >>>>>>>>> at the document? >>>>>>>> sorry for late response. >>>>>>>> >>>>>>>> Looking at this list the only two repositories I consider valid >>>>>>>> in production quickstarts >>>>>>> production quickstarts aren?t actually a thing :-p >>>>>> What word do we use for it then ? it's not community quickstarts >>>>>> since they depend on productized bits. >>>>> Product quickstarts. >>>>> >>>>>>>> are: >>>>>>>> >>>>>>>> redhat-techpreview-all-repository >>>>>>>> http://maven.repository.redhat.com/techpreview/all/ >>>>>>>> >>>>>>>> >>>>>>>> redhat-earlyaccess-all-repository (for things not GA) >>>>>>>> https://maven.repository.redhat.com/earlyaccess/all/ >>>>>>>> >>>>>>> These ^^^, plus fusesource, are valid for non-earlyaccess >>>>>>> quickstarts >>>>>> So the earlyaccess repo is valid for non-earlyaccess quickstarts >>>>>> ? seems counterintuitive ? >>>>> Yes. A quickstart may be in beta, or a product may be in beta. >>>>> These things are orthogonal. >>>>> >>>>>>>> These are I'm surprised we are now letting in: >>>>>>>> >>>>>>>> Jboss public repo is not something our productized nor project >>>>>>>> quickstarts should depend on is it ? Was there not a >>>>>>>> requirement for quickstarts >>>>>>>> to *not* rely on this repo that is a big mashup of dependencies >>>>>>>> and instead only rely on central published artifacts ? >>>>>>>> jboss-public-repository >>>>>>>> https://repository.jboss.org/nexus/content/groups/public/ >>>>>>>> >>>>>>> This ^^^ is valid only for earlyaccess quickstarts >>>>>> ...so earlyaccess quickstarts is even earlier than what is in >>>>>> earlyaccess maven repo ? >>>>>> >>>>>> Just trying to do the mapping since this is what we call >>>>>> community quickstarts on jboss tools end and we keep it clearly >>>>>> separate from production related stuff >>>>>> to avoid/reduce confusion. >>>>> Correct. It?s much closer to what you call early access in JBDS - >>>>> features that aren?t ready to go in to the product yet. >>>>> >>>>>>>> Fuse reposource repo I thought was only being used for old fuse >>>>>>>> releases ? If that is no longer the case then that is not great >>>>>>>> since >>>>>>>> it seem to have a lot of redundancy of artifacts. >>>>>>>> fuse-public-repository >>>>>>>> https://repo.fusesource.com/nexus/content/groups/public >>>>>>>> >>>>>>> It?s still used for Fuse releases AFAIK. >>>>>> mkay '/ - i'll try reach Aileen and here what is the plan for it >>>>>> and what is stopping them from getting into >>>>>> maven.repository.redhat.com. >>>>>> >>>>>>>> This repo I do not understand what is for and should not be >>>>>>>> exposed anywhere IMO. Only relevant to put in testers own >>>>>>>> settings.xml is it not ? >>>>>>>> jboss-developer-staging-repository >>>>>>>> http://jboss-developer.github.io/temp-maven-repo/ >>>>>>>> >>>>>>> Agreed, this one should never appear in a POM. >>>>>> +1 >>>>>> >>>>>> /max >>>>>> >>>>>>>> About the ID's correctness/alignment with our tools that is >>>>>>>> something Fred should be able to verify better than I. >>>>>>>> >>>>>>>> /max >>>>>>>> >>>>>>>>> Pete/Max, >>>>>>>>> >>>>>>>>> Do you know if Fuse maven repository still valid ? >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I was thinking about the implementation of the repository >>>>>>>>>> definition in pom.xml and I want to share my thoughts: >>>>>>>>>> >>>>>>>>>> - Create a QSTools CHECKER to mark the lack of >>>>>>>>>> as a guideline violation if MavenCentralChecker is disabled. >>>>>>>>>> - The violation message will instruct to use the new QSTools >>>>>>>>>> GOAL that will be created >>>>>>>>>> >>>>>>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>>>>>> - There will be a list of approved repositories and its IDs >>>>>>>>>> (redhat techpreview, earlyacess, jboss developer temporary, etc) >>>>>>>>>> - QSTools will remove all previous repositories from pom.xml >>>>>>>>>> and prompt which repositories should be added. >>>>>>>>>> - This will help Quickstarts and demos to be easily buildable >>>>>>>>>> from development and production branches and will also allow >>>>>>>>>> this list to be bulk updated to remove any previous >>>>>>>>>> development repository definition. >>>>>>>>>> >>>>>>>>>> Please, >>>>>>>>>> >>>>>>>>>> If you have any feedback on this, feel free to reply. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>>>>>> JBoss Developer >>>>>>>>>> M: +55-61-9269-6576 >>>>>>>>>> >>>>>>>>>> Red Hat >>>>>>>>>> >>>>>>>>>> Better technology. Faster innovation. Powered by community >>>>>>>>>> collaboration. >>>>>>>>>> See how it works at www.redhat.com >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> LinkedIn >>>>>>>>> > Youtube >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> jbossdeveloper mailing list >>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>> >>>>>>>> >>>>>>>> /max >>>>>>>> http://about.me/maxandersen >>>>>> >>>>>> /max >>>>>> http://about.me/maxandersen >>> >>> >>> /max >>> http://about.me/maxandersen > > > /max > http://about.me/maxandersen From mnovotny at redhat.com Wed Apr 22 02:46:56 2015 From: mnovotny at redhat.com (Marek Novotny) Date: Wed, 22 Apr 2015 08:46:56 +0200 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: <5536BF28.8070609@redhat.com> References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> <5536516F.5010407@redhat.com> <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> <5536BF28.8070609@redhat.com> Message-ID: <553743E0.2020605@redhat.com> Rafael, I am not sure with the "enforced by QE". They definitely should look at QS pom.xml files to check if there is not valid repository, but you know that they still need to verify QS with their own Maven setup as the repository content is not there until GA happens. On 21.4.2015 23:20, Rafael Benevides wrote: > This is enforced by QE. I don't know what they use to do that but maybe > Paul Gier or Marek N can answer that (I'm copying them). > > QSTools provides a GUI for add/remove these repositories but it needs a > human interaction to choose the proper ones. I am not familiarized with the new updates to QSTools after WFK 2.7.0.GA release, but I recall at time for WFK 2.7.0 I just ran the QSTools repositories goal and it did changes without a GUI, so if there is a GUI, it is huge enhancement ;) > > On 4/21/15 16:53, Max Rydahl Andersen wrote: >> On 21 Apr 2015, at 15:32, Rafael Benevides wrote: >> >>> Np, Max. >>> >>> They will be used just "if required" for dependencies that were not >>> released yet because we want/need that the -develop branch should be >>> buildable for Quickstarts contributors. >>> >>> During the productisation procedures, the only repository allowed >>> will be "maven.repository.redhat.com". >> >> ah yes, now I remember. >> >> Can you point me to where that is enforced ? >> https://github.com/jboss-developer/maven-qstools-plugin/blob/master/config/qstools_config.yaml#L24 >> seem to just be the global list ? >> >> /max >> >>> On 4/21/15 03:54, Max Rydahl Andersen wrote: >>>> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: >>>> >>>>> Hi all, >>>>> >>>>> The definition in pom.xml was included as part of >>>>> EAP 7 plan: https://mojo.redhat.com/docs/DOC-1020116 >>>> >>>> I noticed this linked to a link that says a repo named >>>> "temp-maven-repo" is in the list of approved repositories ? Is that >>>> really intended ? >>>> >>>> And why is the very global >>>> repository.jboss.org/nexus/content/groups/public allowed in here ? >>>> We are supposed to *not* depend on that repository in any form of >>>> fashion during productisation aren't we ? >>>> >>>> p.s. I think I've asked the above before so i'm sorry if I forgotten >>>> - if there is a good reason I think we should add that in the >>>> comments of the qstools-plugin :) >>>> >>>> /max >>>> >>>>> >>>>> >>>>> On 11/14/14 07:38, Pete Muir wrote: >>>>>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen >>>>>>> wrote: >>>>>>> >>>>>>>>>> Can you please review https://mojo.redhat.com/docs/DOC-997344 >>>>>>>>>> and confirm if those >>>>>>>>>> ids are ok. If not, do you mind to place the right information >>>>>>>>>> at the document? >>>>>>>>> sorry for late response. >>>>>>>>> >>>>>>>>> Looking at this list the only two repositories I consider valid >>>>>>>>> in production quickstarts >>>>>>>> production quickstarts aren?t actually a thing :-p >>>>>>> What word do we use for it then ? it's not community quickstarts >>>>>>> since they depend on productized bits. >>>>>> Product quickstarts. >>>>>> >>>>>>>>> are: >>>>>>>>> >>>>>>>>> redhat-techpreview-all-repository >>>>>>>>> http://maven.repository.redhat.com/techpreview/all/ >>>>>>>>> >>>>>>>>> >>>>>>>>> redhat-earlyaccess-all-repository (for things not GA) >>>>>>>>> https://maven.repository.redhat.com/earlyaccess/all/ >>>>>>>>> >>>>>>>> These ^^^, plus fusesource, are valid for non-earlyaccess >>>>>>>> quickstarts >>>>>>> So the earlyaccess repo is valid for non-earlyaccess quickstarts >>>>>>> ? seems counterintuitive ? >>>>>> Yes. A quickstart may be in beta, or a product may be in beta. >>>>>> These things are orthogonal. >>>>>> >>>>>>>>> These are I'm surprised we are now letting in: >>>>>>>>> >>>>>>>>> Jboss public repo is not something our productized nor project >>>>>>>>> quickstarts should depend on is it ? Was there not a >>>>>>>>> requirement for quickstarts >>>>>>>>> to *not* rely on this repo that is a big mashup of dependencies >>>>>>>>> and instead only rely on central published artifacts ? >>>>>>>>> jboss-public-repository >>>>>>>>> https://repository.jboss.org/nexus/content/groups/public/ >>>>>>>>> >>>>>>>> This ^^^ is valid only for earlyaccess quickstarts >>>>>>> ...so earlyaccess quickstarts is even earlier than what is in >>>>>>> earlyaccess maven repo ? >>>>>>> >>>>>>> Just trying to do the mapping since this is what we call >>>>>>> community quickstarts on jboss tools end and we keep it clearly >>>>>>> separate from production related stuff >>>>>>> to avoid/reduce confusion. >>>>>> Correct. It?s much closer to what you call early access in JBDS - >>>>>> features that aren?t ready to go in to the product yet. >>>>>> >>>>>>>>> Fuse reposource repo I thought was only being used for old fuse >>>>>>>>> releases ? If that is no longer the case then that is not great >>>>>>>>> since >>>>>>>>> it seem to have a lot of redundancy of artifacts. >>>>>>>>> fuse-public-repository >>>>>>>>> https://repo.fusesource.com/nexus/content/groups/public >>>>>>>>> >>>>>>>> It?s still used for Fuse releases AFAIK. >>>>>>> mkay '/ - i'll try reach Aileen and here what is the plan for it >>>>>>> and what is stopping them from getting into >>>>>>> maven.repository.redhat.com. >>>>>>> >>>>>>>>> This repo I do not understand what is for and should not be >>>>>>>>> exposed anywhere IMO. Only relevant to put in testers own >>>>>>>>> settings.xml is it not ? >>>>>>>>> jboss-developer-staging-repository >>>>>>>>> http://jboss-developer.github.io/temp-maven-repo/ >>>>>>>>> >>>>>>>> Agreed, this one should never appear in a POM. >>>>>>> +1 >>>>>>> >>>>>>> /max >>>>>>> >>>>>>>>> About the ID's correctness/alignment with our tools that is >>>>>>>>> something Fred should be able to verify better than I. >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>>> Pete/Max, >>>>>>>>>> >>>>>>>>>> Do you know if Fuse maven repository still valid ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I was thinking about the implementation of the repository >>>>>>>>>>> definition in pom.xml and I want to share my thoughts: >>>>>>>>>>> >>>>>>>>>>> - Create a QSTools CHECKER to mark the lack of >>>>>>>>>>> as a guideline violation if MavenCentralChecker is disabled. >>>>>>>>>>> - The violation message will instruct to use the new QSTools >>>>>>>>>>> GOAL that will be created >>>>>>>>>>> >>>>>>>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>>>>>>> - There will be a list of approved repositories and its IDs >>>>>>>>>>> (redhat techpreview, earlyacess, jboss developer temporary, etc) >>>>>>>>>>> - QSTools will remove all previous repositories from pom.xml >>>>>>>>>>> and prompt which repositories should be added. >>>>>>>>>>> - This will help Quickstarts and demos to be easily buildable >>>>>>>>>>> from development and production branches and will also allow >>>>>>>>>>> this list to be bulk updated to remove any previous >>>>>>>>>>> development repository definition. >>>>>>>>>>> >>>>>>>>>>> Please, >>>>>>>>>>> >>>>>>>>>>> If you have any feedback on this, feel free to reply. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>>>>>>> JBoss Developer >>>>>>>>>>> M: +55-61-9269-6576 >>>>>>>>>>> >>>>>>>>>>> Red Hat >>>>>>>>>>> >>>>>>>>>>> Better technology. Faster innovation. Powered by community >>>>>>>>>>> collaboration. >>>>>>>>>>> See how it works at www.redhat.com >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> LinkedIn >>>>>>>>>> > Youtube >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>>> >>>>>>>>> >>>>>>>>> /max >>>>>>>>> http://about.me/maxandersen >>>>>>> >>>>>>> /max >>>>>>> http://about.me/maxandersen >>>> >>>> >>>> /max >>>> http://about.me/maxandersen >> >> >> /max >> http://about.me/maxandersen > -- Marek Novotny -- WFK and Seam Product Lead Red Hat Czech s.r.o. Purkynova 99 612 45 Brno From pmuir at redhat.com Wed Apr 22 06:53:43 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 22 Apr 2015 11:53:43 +0100 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: <5536BF28.8070609@redhat.com> References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> <5536516F.5010407@redhat.com> <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> <5536BF28.8070609@redhat.com> Message-ID: Rafael, would a good feature request be adding repository profiles, so you can easily switch between lists. For example -Dqstools.profile=development or -Dqstools.profile=release > On 21 Apr 2015, at 22:20, Rafael Benevides wrote: > > This is enforced by QE. I don't know what they use to do that but maybe Paul Gier or Marek N can answer that (I'm copying them). > > QSTools provides a GUI for add/remove these repositories but it needs a human interaction to choose the proper ones. > > On 4/21/15 16:53, Max Rydahl Andersen wrote: >> On 21 Apr 2015, at 15:32, Rafael Benevides wrote: >> >>> Np, Max. >>> >>> They will be used just "if required" for dependencies that were not released yet because we want/need that the -develop branch should be buildable for Quickstarts contributors. >>> >>> During the productisation procedures, the only repository allowed will be "maven.repository.redhat.com". >> >> ah yes, now I remember. >> >> Can you point me to where that is enforced ? https://github.com/jboss-developer/maven-qstools-plugin/blob/master/config/qstools_config.yaml#L24 seem to just be the global list ? >> >> /max >> >>> On 4/21/15 03:54, Max Rydahl Andersen wrote: >>>> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: >>>> >>>>> Hi all, >>>>> >>>>> The definition in pom.xml was included as part of EAP 7 plan: https://mojo.redhat.com/docs/DOC-1020116 >>>> >>>> I noticed this linked to a link that says a repo named "temp-maven-repo" is in the list of approved repositories ? Is that really intended ? >>>> >>>> And why is the very global repository.jboss.org/nexus/content/groups/public allowed in here ? We are supposed to *not* depend on that repository in any form of fashion during productisation aren't we ? >>>> >>>> p.s. I think I've asked the above before so i'm sorry if I forgotten - if there is a good reason I think we should add that in the comments of the qstools-plugin :) >>>> >>>> /max >>>> >>>>> >>>>> >>>>> On 11/14/14 07:38, Pete Muir wrote: >>>>>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen wrote: >>>>>>> >>>>>>>>>> Can you please review https://mojo.redhat.com/docs/DOC-997344 and confirm if those ids are ok. If not, do you mind to place the right information at the document? >>>>>>>>> sorry for late response. >>>>>>>>> >>>>>>>>> Looking at this list the only two repositories I consider valid in production quickstarts >>>>>>>> production quickstarts aren?t actually a thing :-p >>>>>>> What word do we use for it then ? it's not community quickstarts since they depend on productized bits. >>>>>> Product quickstarts. >>>>>> >>>>>>>>> are: >>>>>>>>> >>>>>>>>> redhat-techpreview-all-repository >>>>>>>>> http://maven.repository.redhat.com/techpreview/all/ >>>>>>>>> >>>>>>>>> redhat-earlyaccess-all-repository (for things not GA) >>>>>>>>> https://maven.repository.redhat.com/earlyaccess/all/ >>>>>>>> These ^^^, plus fusesource, are valid for non-earlyaccess quickstarts >>>>>>> So the earlyaccess repo is valid for non-earlyaccess quickstarts ? seems counterintuitive ? >>>>>> Yes. A quickstart may be in beta, or a product may be in beta. These things are orthogonal. >>>>>> >>>>>>>>> These are I'm surprised we are now letting in: >>>>>>>>> >>>>>>>>> Jboss public repo is not something our productized nor project quickstarts should depend on is it ? Was there not a requirement for quickstarts >>>>>>>>> to *not* rely on this repo that is a big mashup of dependencies and instead only rely on central published artifacts ? >>>>>>>>> jboss-public-repository >>>>>>>>> https://repository.jboss.org/nexus/content/groups/public/ >>>>>>>> This ^^^ is valid only for earlyaccess quickstarts >>>>>>> ...so earlyaccess quickstarts is even earlier than what is in earlyaccess maven repo ? >>>>>>> >>>>>>> Just trying to do the mapping since this is what we call community quickstarts on jboss tools end and we keep it clearly separate from production related stuff >>>>>>> to avoid/reduce confusion. >>>>>> Correct. It?s much closer to what you call early access in JBDS - features that aren?t ready to go in to the product yet. >>>>>> >>>>>>>>> Fuse reposource repo I thought was only being used for old fuse releases ? If that is no longer the case then that is not great since >>>>>>>>> it seem to have a lot of redundancy of artifacts. >>>>>>>>> fuse-public-repository >>>>>>>>> https://repo.fusesource.com/nexus/content/groups/public >>>>>>>> It?s still used for Fuse releases AFAIK. >>>>>>> mkay '/ - i'll try reach Aileen and here what is the plan for it and what is stopping them from getting into maven.repository.redhat.com. >>>>>>> >>>>>>>>> This repo I do not understand what is for and should not be exposed anywhere IMO. Only relevant to put in testers own settings.xml is it not ? >>>>>>>>> jboss-developer-staging-repository >>>>>>>>> http://jboss-developer.github.io/temp-maven-repo/ >>>>>>>> Agreed, this one should never appear in a POM. >>>>>>> +1 >>>>>>> >>>>>>> /max >>>>>>> >>>>>>>>> About the ID's correctness/alignment with our tools that is something Fred should be able to verify better than I. >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>>> Pete/Max, >>>>>>>>>> >>>>>>>>>> Do you know if Fuse maven repository still valid ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I was thinking about the implementation of the repository definition in pom.xml and I want to share my thoughts: >>>>>>>>>>> >>>>>>>>>>> - Create a QSTools CHECKER to mark the lack of as a guideline violation if MavenCentralChecker is disabled. >>>>>>>>>>> - The violation message will instruct to use the new QSTools GOAL that will be created >>>>>>>>>>> >>>>>>>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>>>>>>> - There will be a list of approved repositories and its IDs (redhat techpreview, earlyacess, jboss developer temporary, etc) >>>>>>>>>>> - QSTools will remove all previous repositories from pom.xml and prompt which repositories should be added. >>>>>>>>>>> - This will help Quickstarts and demos to be easily buildable from development and production branches and will also allow this list to be bulk updated to remove any previous development repository definition. >>>>>>>>>>> >>>>>>>>>>> Please, >>>>>>>>>>> >>>>>>>>>>> If you have any feedback on this, feel free to reply. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>>>>>>> JBoss Developer >>>>>>>>>>> M: +55-61-9269-6576 >>>>>>>>>>> >>>>>>>>>>> Red Hat >>>>>>>>>>> >>>>>>>>>>> Better technology. Faster innovation. Powered by community collaboration. >>>>>>>>>>> See how it works at www.redhat.com > >>>>>>>>>>> >>>>>>>>>>> LinkedIn > Youtube > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>>> _______________________________________________ >>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>> >>>>>>>>> /max >>>>>>>>> http://about.me/maxandersen >>>>>>> >>>>>>> /max >>>>>>> http://about.me/maxandersen >>>> >>>> >>>> /max >>>> http://about.me/maxandersen >> >> >> /max >> http://about.me/maxandersen > From manderse at redhat.com Wed Apr 22 07:00:19 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 22 Apr 2015 13:00:19 +0200 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> <5536516F.5010407@redhat.com> <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> <5536BF28.8070609@redhat.com> Message-ID: <4C0695CC-0247-4DEB-AACC-75BDFB9994A8@redhat.com> On 22 Apr 2015, at 12:53, Pete Muir wrote: > Rafael, would a good feature request be adding repository profiles, so > you can easily switch between lists. For example > -Dqstools.profile=development or -Dqstools.profile=release +1 it seems like we validate better during development than at the actual release point. having the qstools report on issues for release would be great and something others could do more easily than rely on full QE/brew setup environment. /max > >> On 21 Apr 2015, at 22:20, Rafael Benevides >> wrote: >> >> This is enforced by QE. I don't know what they use to do that but >> maybe Paul Gier or Marek N can answer that (I'm copying them). >> >> QSTools provides a GUI for add/remove these repositories but it needs >> a human interaction to choose the proper ones. >> >> On 4/21/15 16:53, Max Rydahl Andersen wrote: >>> On 21 Apr 2015, at 15:32, Rafael Benevides wrote: >>> >>>> Np, Max. >>>> >>>> They will be used just "if required" for dependencies that were not >>>> released yet because we want/need that the -develop branch should >>>> be buildable for Quickstarts contributors. >>>> >>>> During the productisation procedures, the only repository allowed >>>> will be "maven.repository.redhat.com". >>> >>> ah yes, now I remember. >>> >>> Can you point me to where that is enforced ? >>> https://github.com/jboss-developer/maven-qstools-plugin/blob/master/config/qstools_config.yaml#L24 >>> seem to just be the global list ? >>> >>> /max >>> >>>> On 4/21/15 03:54, Max Rydahl Andersen wrote: >>>>> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> The definition in pom.xml was included as part of >>>>>> EAP 7 plan: https://mojo.redhat.com/docs/DOC-1020116 >>>>> >>>>> I noticed this linked to a link that says a repo named >>>>> "temp-maven-repo" is in the list of approved repositories ? Is >>>>> that really intended ? >>>>> >>>>> And why is the very global >>>>> repository.jboss.org/nexus/content/groups/public allowed in here ? >>>>> We are supposed to *not* depend on that repository in any form of >>>>> fashion during productisation aren't we ? >>>>> >>>>> p.s. I think I've asked the above before so i'm sorry if I >>>>> forgotten - if there is a good reason I think we should add that >>>>> in the comments of the qstools-plugin :) >>>>> >>>>> /max >>>>> >>>>>> >>>>>> >>>>>> On 11/14/14 07:38, Pete Muir wrote: >>>>>>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen >>>>>>>> wrote: >>>>>>>> >>>>>>>>>>> Can you please review >>>>>>>>>>> https://mojo.redhat.com/docs/DOC-997344 >>>>>>>>>>> and confirm if >>>>>>>>>>> those ids are ok. If not, do you mind to place the right >>>>>>>>>>> information at the document? >>>>>>>>>> sorry for late response. >>>>>>>>>> >>>>>>>>>> Looking at this list the only two repositories I consider >>>>>>>>>> valid in production quickstarts >>>>>>>>> production quickstarts aren?t actually a thing :-p >>>>>>>> What word do we use for it then ? it's not community >>>>>>>> quickstarts since they depend on productized bits. >>>>>>> Product quickstarts. >>>>>>> >>>>>>>>>> are: >>>>>>>>>> >>>>>>>>>> redhat-techpreview-all-repository >>>>>>>>>> http://maven.repository.redhat.com/techpreview/all/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> redhat-earlyaccess-all-repository (for things not GA) >>>>>>>>>> https://maven.repository.redhat.com/earlyaccess/all/ >>>>>>>>>> >>>>>>>>> These ^^^, plus fusesource, are valid for non-earlyaccess >>>>>>>>> quickstarts >>>>>>>> So the earlyaccess repo is valid for non-earlyaccess >>>>>>>> quickstarts ? seems counterintuitive ? >>>>>>> Yes. A quickstart may be in beta, or a product may be in beta. >>>>>>> These things are orthogonal. >>>>>>> >>>>>>>>>> These are I'm surprised we are now letting in: >>>>>>>>>> >>>>>>>>>> Jboss public repo is not something our productized nor >>>>>>>>>> project quickstarts should depend on is it ? Was there not a >>>>>>>>>> requirement for quickstarts >>>>>>>>>> to *not* rely on this repo that is a big mashup of >>>>>>>>>> dependencies and instead only rely on central published >>>>>>>>>> artifacts ? >>>>>>>>>> jboss-public-repository >>>>>>>>>> https://repository.jboss.org/nexus/content/groups/public/ >>>>>>>>>> >>>>>>>>> This ^^^ is valid only for earlyaccess quickstarts >>>>>>>> ...so earlyaccess quickstarts is even earlier than what is in >>>>>>>> earlyaccess maven repo ? >>>>>>>> >>>>>>>> Just trying to do the mapping since this is what we call >>>>>>>> community quickstarts on jboss tools end and we keep it clearly >>>>>>>> separate from production related stuff >>>>>>>> to avoid/reduce confusion. >>>>>>> Correct. It?s much closer to what you call early access in >>>>>>> JBDS - features that aren?t ready to go in to the product yet. >>>>>>> >>>>>>>>>> Fuse reposource repo I thought was only being used for old >>>>>>>>>> fuse releases ? If that is no longer the case then that is >>>>>>>>>> not great since >>>>>>>>>> it seem to have a lot of redundancy of artifacts. >>>>>>>>>> fuse-public-repository >>>>>>>>>> https://repo.fusesource.com/nexus/content/groups/public >>>>>>>>>> >>>>>>>>> It?s still used for Fuse releases AFAIK. >>>>>>>> mkay '/ - i'll try reach Aileen and here what is the plan for >>>>>>>> it and what is stopping them from getting into >>>>>>>> maven.repository.redhat.com. >>>>>>>> >>>>>>>>>> This repo I do not understand what is for and should not be >>>>>>>>>> exposed anywhere IMO. Only relevant to put in testers own >>>>>>>>>> settings.xml is it not ? >>>>>>>>>> jboss-developer-staging-repository >>>>>>>>>> http://jboss-developer.github.io/temp-maven-repo/ >>>>>>>>>> >>>>>>>>> Agreed, this one should never appear in a POM. >>>>>>>> +1 >>>>>>>> >>>>>>>> /max >>>>>>>> >>>>>>>>>> About the ID's correctness/alignment with our tools that is >>>>>>>>>> something Fred should be able to verify better than I. >>>>>>>>>> >>>>>>>>>> /max >>>>>>>>>> >>>>>>>>>>> Pete/Max, >>>>>>>>>>> >>>>>>>>>>> Do you know if Fuse maven repository still valid ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I was thinking about the implementation of the repository >>>>>>>>>>>> definition in pom.xml and I want to share my thoughts: >>>>>>>>>>>> >>>>>>>>>>>> - Create a QSTools CHECKER to mark the lack of >>>>>>>>>>> /> as a guideline violation if MavenCentralChecker is >>>>>>>>>>>> disabled. >>>>>>>>>>>> - The violation message will instruct to use the new >>>>>>>>>>>> QSTools GOAL that will be created >>>>>>>>>>>> >>>>>>>>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>>>>>>>> - There will be a list of approved repositories and its IDs >>>>>>>>>>>> (redhat techpreview, earlyacess, jboss developer temporary, >>>>>>>>>>>> etc) >>>>>>>>>>>> - QSTools will remove all previous repositories from >>>>>>>>>>>> pom.xml and prompt which repositories should be added. >>>>>>>>>>>> - This will help Quickstarts and demos to be easily >>>>>>>>>>>> buildable from development and production branches and will >>>>>>>>>>>> also allow this list to be bulk updated to remove any >>>>>>>>>>>> previous development repository definition. >>>>>>>>>>>> >>>>>>>>>>>> Please, >>>>>>>>>>>> >>>>>>>>>>>> If you have any feedback on this, feel free to reply. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>>>>>>>> JBoss Developer >>>>>>>>>>>> M: +55-61-9269-6576 >>>>>>>>>>>> >>>>>>>>>>>> Red Hat >>>>>>>>>>>> >>>>>>>>>>>> Better technology. Faster innovation. Powered by community >>>>>>>>>>>> collaboration. >>>>>>>>>>>> See how it works at www.redhat.com >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> LinkedIn >>>>>>>>>>> > Youtube >>>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>>>> >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /max >>>>>>>>>> http://about.me/maxandersen >>>>>>>> >>>>>>>> /max >>>>>>>> http://about.me/maxandersen >>>>> >>>>> >>>>> /max >>>>> http://about.me/maxandersen >>> >>> >>> /max >>> http://about.me/maxandersen >> /max http://about.me/maxandersen From benevides at redhat.com Wed Apr 22 08:51:34 2015 From: benevides at redhat.com (Rafael Benevides) Date: Wed, 22 Apr 2015 08:51:34 -0400 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: <4C0695CC-0247-4DEB-AACC-75BDFB9994A8@redhat.com> References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> <5536516F.5010407@redhat.com> <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> <5536BF28.8070609@redhat.com> <4C0695CC-0247-4DEB-AACC-75BDFB9994A8@redhat.com> Message-ID: <55379956.6020604@redhat.com> Excellent suggestion. I've created https://issues.jboss.org/browse/JDF-815 for do it. Marek, Sorry, It's not a GUI, but a textual UI as you used. Nothing changed since them. But it will be gone when we have JDF-815 implemented. On 4/22/15 07:00, Max Rydahl Andersen wrote: > On 22 Apr 2015, at 12:53, Pete Muir wrote: > >> Rafael, would a good feature request be adding repository profiles, >> so you can easily switch between lists. For example >> -Dqstools.profile=development or -Dqstools.profile=release > > +1 > > it seems like we validate better during development than at the actual > release point. having the qstools > report on issues for release would be great and something others could > do more easily than rely on full QE/brew setup environment. > > /max > >> >>> On 21 Apr 2015, at 22:20, Rafael Benevides >>> wrote: >>> >>> This is enforced by QE. I don't know what they use to do that but >>> maybe Paul Gier or Marek N can answer that (I'm copying them). >>> >>> QSTools provides a GUI for add/remove these repositories but it >>> needs a human interaction to choose the proper ones. >>> >>> On 4/21/15 16:53, Max Rydahl Andersen wrote: >>>> On 21 Apr 2015, at 15:32, Rafael Benevides wrote: >>>> >>>>> Np, Max. >>>>> >>>>> They will be used just "if required" for dependencies that were >>>>> not released yet because we want/need that the -develop branch >>>>> should be buildable for Quickstarts contributors. >>>>> >>>>> During the productisation procedures, the only repository allowed >>>>> will be "maven.repository.redhat.com". >>>> >>>> ah yes, now I remember. >>>> >>>> Can you point me to where that is enforced ? >>>> https://github.com/jboss-developer/maven-qstools-plugin/blob/master/config/qstools_config.yaml#L24 >>>> seem to just be the global list ? >>>> >>>> /max >>>> >>>>> On 4/21/15 03:54, Max Rydahl Andersen wrote: >>>>>> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> The definition in pom.xml was included as part of >>>>>>> EAP 7 plan: https://mojo.redhat.com/docs/DOC-1020116 >>>>>> >>>>>> I noticed this linked to a link that says a repo named >>>>>> "temp-maven-repo" is in the list of approved repositories ? Is >>>>>> that really intended ? >>>>>> >>>>>> And why is the very global >>>>>> repository.jboss.org/nexus/content/groups/public allowed in here >>>>>> ? We are supposed to *not* depend on that repository in any form >>>>>> of fashion during productisation aren't we ? >>>>>> >>>>>> p.s. I think I've asked the above before so i'm sorry if I >>>>>> forgotten - if there is a good reason I think we should add that >>>>>> in the comments of the qstools-plugin :) >>>>>> >>>>>> /max >>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/14/14 07:38, Pete Muir wrote: >>>>>>>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>>>> Can you please review >>>>>>>>>>>> https://mojo.redhat.com/docs/DOC-997344 >>>>>>>>>>>> and confirm if >>>>>>>>>>>> those ids are ok. If not, do you mind to place the right >>>>>>>>>>>> information at the document? >>>>>>>>>>> sorry for late response. >>>>>>>>>>> >>>>>>>>>>> Looking at this list the only two repositories I consider >>>>>>>>>>> valid in production quickstarts >>>>>>>>>> production quickstarts aren?t actually a thing :-p >>>>>>>>> What word do we use for it then ? it's not community >>>>>>>>> quickstarts since they depend on productized bits. >>>>>>>> Product quickstarts. >>>>>>>> >>>>>>>>>>> are: >>>>>>>>>>> >>>>>>>>>>> redhat-techpreview-all-repository >>>>>>>>>>> http://maven.repository.redhat.com/techpreview/all/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> redhat-earlyaccess-all-repository (for things not GA) >>>>>>>>>>> https://maven.repository.redhat.com/earlyaccess/all/ >>>>>>>>>>> >>>>>>>>>> These ^^^, plus fusesource, are valid for non-earlyaccess >>>>>>>>>> quickstarts >>>>>>>>> So the earlyaccess repo is valid for non-earlyaccess >>>>>>>>> quickstarts ? seems counterintuitive ? >>>>>>>> Yes. A quickstart may be in beta, or a product may be in beta. >>>>>>>> These things are orthogonal. >>>>>>>> >>>>>>>>>>> These are I'm surprised we are now letting in: >>>>>>>>>>> >>>>>>>>>>> Jboss public repo is not something our productized nor >>>>>>>>>>> project quickstarts should depend on is it ? Was there not a >>>>>>>>>>> requirement for quickstarts >>>>>>>>>>> to *not* rely on this repo that is a big mashup of >>>>>>>>>>> dependencies and instead only rely on central published >>>>>>>>>>> artifacts ? >>>>>>>>>>> jboss-public-repository >>>>>>>>>>> https://repository.jboss.org/nexus/content/groups/public/ >>>>>>>>>>> >>>>>>>>>> This ^^^ is valid only for earlyaccess quickstarts >>>>>>>>> ...so earlyaccess quickstarts is even earlier than what is in >>>>>>>>> earlyaccess maven repo ? >>>>>>>>> >>>>>>>>> Just trying to do the mapping since this is what we call >>>>>>>>> community quickstarts on jboss tools end and we keep it >>>>>>>>> clearly separate from production related stuff >>>>>>>>> to avoid/reduce confusion. >>>>>>>> Correct. It?s much closer to what you call early access in JBDS >>>>>>>> - features that aren?t ready to go in to the product yet. >>>>>>>> >>>>>>>>>>> Fuse reposource repo I thought was only being used for old >>>>>>>>>>> fuse releases ? If that is no longer the case then that is >>>>>>>>>>> not great since >>>>>>>>>>> it seem to have a lot of redundancy of artifacts. >>>>>>>>>>> fuse-public-repository >>>>>>>>>>> https://repo.fusesource.com/nexus/content/groups/public >>>>>>>>>>> >>>>>>>>>> It?s still used for Fuse releases AFAIK. >>>>>>>>> mkay '/ - i'll try reach Aileen and here what is the plan for >>>>>>>>> it and what is stopping them from getting into >>>>>>>>> maven.repository.redhat.com. >>>>>>>>> >>>>>>>>>>> This repo I do not understand what is for and should not be >>>>>>>>>>> exposed anywhere IMO. Only relevant to put in testers own >>>>>>>>>>> settings.xml is it not ? >>>>>>>>>>> jboss-developer-staging-repository >>>>>>>>>>> http://jboss-developer.github.io/temp-maven-repo/ >>>>>>>>>>> >>>>>>>>>> Agreed, this one should never appear in a POM. >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>>>> About the ID's correctness/alignment with our tools that is >>>>>>>>>>> something Fred should be able to verify better than I. >>>>>>>>>>> >>>>>>>>>>> /max >>>>>>>>>>> >>>>>>>>>>>> Pete/Max, >>>>>>>>>>>> >>>>>>>>>>>> Do you know if Fuse maven repository still valid ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> I was thinking about the implementation of the repository >>>>>>>>>>>>> definition in pom.xml and I want to share my thoughts: >>>>>>>>>>>>> >>>>>>>>>>>>> - Create a QSTools CHECKER to mark the lack of >>>>>>>>>>>> /> as a guideline violation if MavenCentralChecker is >>>>>>>>>>>>> disabled. >>>>>>>>>>>>> - The violation message will instruct to use the new >>>>>>>>>>>>> QSTools GOAL that will be created >>>>>>>>>>>>> >>>>>>>>>>>>> - Create another QSTools GOAL to setup the repositories. >>>>>>>>>>>>> - There will be a list of approved repositories and its >>>>>>>>>>>>> IDs (redhat techpreview, earlyacess, jboss developer >>>>>>>>>>>>> temporary, etc) >>>>>>>>>>>>> - QSTools will remove all previous repositories from >>>>>>>>>>>>> pom.xml and prompt which repositories should be added. >>>>>>>>>>>>> - This will help Quickstarts and demos to be easily >>>>>>>>>>>>> buildable from development and production branches and >>>>>>>>>>>>> will also allow this list to be bulk updated to remove any >>>>>>>>>>>>> previous development repository definition. >>>>>>>>>>>>> >>>>>>>>>>>>> Please, >>>>>>>>>>>>> >>>>>>>>>>>>> If you have any feedback on this, feel free to reply. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> *Rafael Benevides | Senior Software Engineer* >>>>>>>>>>>>> JBoss Developer >>>>>>>>>>>>> M: +55-61-9269-6576 >>>>>>>>>>>>> >>>>>>>>>>>>> Red Hat >>>>>>>>>>>>> >>>>>>>>>>>>> Better technology. Faster innovation. Powered by community >>>>>>>>>>>>> collaboration. >>>>>>>>>>>>> See how it works at www.redhat.com >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> LinkedIn >>>>>>>>>>>> > Youtube >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> jbossdeveloper mailing list >>>>>>>>>>>> jbossdeveloper at lists.jboss.org >>>>>>>>>>>> >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /max >>>>>>>>>>> http://about.me/maxandersen >>>>>>>>> >>>>>>>>> /max >>>>>>>>> http://about.me/maxandersen >>>>>> >>>>>> >>>>>> /max >>>>>> http://about.me/maxandersen >>>> >>>> >>>> /max >>>> http://about.me/maxandersen >>> > > > /max > http://about.me/maxandersen From kpiwko at redhat.com Thu Apr 30 06:04:58 2015 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 30 Apr 2015 12:04:58 +0200 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: <5536BF28.8070609@redhat.com> References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> <5536516F.5010407@redhat.com> <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> <5536BF28.8070609@redhat.com> Message-ID: I'm not aware of Wolf Validator tool being able to check what repository URLs are in pom.xml file, it basically complains if there are any repository elements. Maybe EAP QE has additional checks in place (in CC). I've created a feature request to have this feature added: https://issues.jboss.org/browse/WOLF-72 Cheers, Karel On Tue, Apr 21, 2015 at 11:20 PM, Rafael Benevides wrote: > This is enforced by QE. I don't know what they use to do that but maybe > Paul Gier or Marek N can answer that (I'm copying them). > > QSTools provides a GUI for add/remove these repositories but it needs a > human interaction to choose the proper ones. > > On 4/21/15 16:53, Max Rydahl Andersen wrote: > > On 21 Apr 2015, at 15:32, Rafael Benevides wrote: > > > >> Np, Max. > >> > >> They will be used just "if required" for dependencies that were not > >> released yet because we want/need that the -develop branch should be > >> buildable for Quickstarts contributors. > >> > >> During the productisation procedures, the only repository allowed > >> will be "maven.repository.redhat.com". > > > > ah yes, now I remember. > > > > Can you point me to where that is enforced ? > > > https://github.com/jboss-developer/maven-qstools-plugin/blob/master/config/qstools_config.yaml#L24 > > seem to just be the global list ? > > > > /max > > > >> On 4/21/15 03:54, Max Rydahl Andersen wrote: > >>> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: > >>> > >>>> Hi all, > >>>> > >>>> The definition in pom.xml was included as part of > >>>> EAP 7 plan: https://mojo.redhat.com/docs/DOC-1020116 > >>> > >>> I noticed this linked to a link that says a repo named > >>> "temp-maven-repo" is in the list of approved repositories ? Is that > >>> really intended ? > >>> > >>> And why is the very global > >>> repository.jboss.org/nexus/content/groups/public allowed in here ? > >>> We are supposed to *not* depend on that repository in any form of > >>> fashion during productisation aren't we ? > >>> > >>> p.s. I think I've asked the above before so i'm sorry if I forgotten > >>> - if there is a good reason I think we should add that in the > >>> comments of the qstools-plugin :) > >>> > >>> /max > >>> > >>>> > >>>> > >>>> On 11/14/14 07:38, Pete Muir wrote: > >>>>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen > >>>>>> wrote: > >>>>>> > >>>>>>>>> Can you please review https://mojo.redhat.com/docs/DOC-997344 > >>>>>>>>> and confirm if those > >>>>>>>>> ids are ok. If not, do you mind to place the right information > >>>>>>>>> at the document? > >>>>>>>> sorry for late response. > >>>>>>>> > >>>>>>>> Looking at this list the only two repositories I consider valid > >>>>>>>> in production quickstarts > >>>>>>> production quickstarts aren?t actually a thing :-p > >>>>>> What word do we use for it then ? it's not community quickstarts > >>>>>> since they depend on productized bits. > >>>>> Product quickstarts. > >>>>> > >>>>>>>> are: > >>>>>>>> > >>>>>>>> redhat-techpreview-all-repository > >>>>>>>> http://maven.repository.redhat.com/techpreview/all/ > >>>>>>>> > >>>>>>>> > >>>>>>>> redhat-earlyaccess-all-repository (for things not GA) > >>>>>>>> https://maven.repository.redhat.com/earlyaccess/all/ > >>>>>>>> > >>>>>>> These ^^^, plus fusesource, are valid for non-earlyaccess > >>>>>>> quickstarts > >>>>>> So the earlyaccess repo is valid for non-earlyaccess quickstarts > >>>>>> ? seems counterintuitive ? > >>>>> Yes. A quickstart may be in beta, or a product may be in beta. > >>>>> These things are orthogonal. > >>>>> > >>>>>>>> These are I'm surprised we are now letting in: > >>>>>>>> > >>>>>>>> Jboss public repo is not something our productized nor project > >>>>>>>> quickstarts should depend on is it ? Was there not a > >>>>>>>> requirement for quickstarts > >>>>>>>> to *not* rely on this repo that is a big mashup of dependencies > >>>>>>>> and instead only rely on central published artifacts ? > >>>>>>>> jboss-public-repository > >>>>>>>> https://repository.jboss.org/nexus/content/groups/public/ > >>>>>>>> > >>>>>>> This ^^^ is valid only for earlyaccess quickstarts > >>>>>> ...so earlyaccess quickstarts is even earlier than what is in > >>>>>> earlyaccess maven repo ? > >>>>>> > >>>>>> Just trying to do the mapping since this is what we call > >>>>>> community quickstarts on jboss tools end and we keep it clearly > >>>>>> separate from production related stuff > >>>>>> to avoid/reduce confusion. > >>>>> Correct. It?s much closer to what you call early access in JBDS - > >>>>> features that aren?t ready to go in to the product yet. > >>>>> > >>>>>>>> Fuse reposource repo I thought was only being used for old fuse > >>>>>>>> releases ? If that is no longer the case then that is not great > >>>>>>>> since > >>>>>>>> it seem to have a lot of redundancy of artifacts. > >>>>>>>> fuse-public-repository > >>>>>>>> https://repo.fusesource.com/nexus/content/groups/public > >>>>>>>> > >>>>>>> It?s still used for Fuse releases AFAIK. > >>>>>> mkay '/ - i'll try reach Aileen and here what is the plan for it > >>>>>> and what is stopping them from getting into > >>>>>> maven.repository.redhat.com. > >>>>>> > >>>>>>>> This repo I do not understand what is for and should not be > >>>>>>>> exposed anywhere IMO. Only relevant to put in testers own > >>>>>>>> settings.xml is it not ? > >>>>>>>> jboss-developer-staging-repository > >>>>>>>> http://jboss-developer.github.io/temp-maven-repo/ > >>>>>>>> > >>>>>>> Agreed, this one should never appear in a POM. > >>>>>> +1 > >>>>>> > >>>>>> /max > >>>>>> > >>>>>>>> About the ID's correctness/alignment with our tools that is > >>>>>>>> something Fred should be able to verify better than I. > >>>>>>>> > >>>>>>>> /max > >>>>>>>> > >>>>>>>>> Pete/Max, > >>>>>>>>> > >>>>>>>>> Do you know if Fuse maven repository still valid ? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> > >>>>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> I was thinking about the implementation of the repository > >>>>>>>>>> definition in pom.xml and I want to share my thoughts: > >>>>>>>>>> > >>>>>>>>>> - Create a QSTools CHECKER to mark the lack of > >>>>>>>>>> as a guideline violation if MavenCentralChecker is disabled. > >>>>>>>>>> - The violation message will instruct to use the new QSTools > >>>>>>>>>> GOAL that will be created > >>>>>>>>>> > >>>>>>>>>> - Create another QSTools GOAL to setup the repositories. > >>>>>>>>>> - There will be a list of approved repositories and its IDs > >>>>>>>>>> (redhat techpreview, earlyacess, jboss developer temporary, etc) > >>>>>>>>>> - QSTools will remove all previous repositories from pom.xml > >>>>>>>>>> and prompt which repositories should be added. > >>>>>>>>>> - This will help Quickstarts and demos to be easily buildable > >>>>>>>>>> from development and production branches and will also allow > >>>>>>>>>> this list to be bulk updated to remove any previous > >>>>>>>>>> development repository definition. > >>>>>>>>>> > >>>>>>>>>> Please, > >>>>>>>>>> > >>>>>>>>>> If you have any feedback on this, feel free to reply. > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> > >>>>>>>>>> *Rafael Benevides | Senior Software Engineer* > >>>>>>>>>> JBoss Developer > >>>>>>>>>> M: +55-61-9269-6576 > >>>>>>>>>> > >>>>>>>>>> Red Hat > >>>>>>>>>> > >>>>>>>>>> Better technology. Faster innovation. Powered by community > >>>>>>>>>> collaboration. > >>>>>>>>>> See how it works at www.redhat.com > >>>>>>>>>> > > >>>>>>>>>> > >>>>>>>>>> LinkedIn >>>>>>>>>> > Youtube > >>>>>>>>>> >>>>>>>>>> > > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> jbossdeveloper mailing list > >>>>>>>>>> jbossdeveloper at lists.jboss.org > >>>>>>>>>> > >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> jbossdeveloper mailing list > >>>>>>>>> jbossdeveloper at lists.jboss.org > >>>>>>>>> > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper > >>>>>>>>> > >>>>>>>> > >>>>>>>> /max > >>>>>>>> http://about.me/maxandersen > >>>>>> > >>>>>> /max > >>>>>> http://about.me/maxandersen > >>> > >>> > >>> /max > >>> http://about.me/maxandersen > > > > > > /max > > http://about.me/maxandersen > > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150430/9f2389a3/attachment-0001.html From benevides at redhat.com Thu Apr 30 11:37:39 2015 From: benevides at redhat.com (Rafael Benevides) Date: Thu, 30 Apr 2015 11:37:39 -0400 Subject: [jbossdeveloper] definition in pom.xml for Quickstarts and Demos In-Reply-To: References: <54539501.8030609@redhat.com> <54540075.6020403@redhat.com> <5562D685-7586-4765-9094-1D1397B72D63@redhat.com> <553547DF.8010209@redhat.com> <5066B84B-B9E0-4047-AC72-58201F20ED32@redhat.com> <5536516F.5010407@redhat.com> <61A591BE-249E-4E56-A791-C2E58419C057@redhat.com> <5536BF28.8070609@redhat.com> Message-ID: <55424C43.7030902@redhat.com> Thanks so much, Karel! On 4/30/15 06:04, Karel Piwko wrote: > I'm not aware of Wolf Validator tool being able to check what > repository URLs are in pom.xml file, it basically complains if there > are any repository elements. Maybe EAP QE has additional checks in > place (in CC). > > I've created a feature request to have this feature added: > > https://issues.jboss.org/browse/WOLF-72 > > Cheers, > > Karel > > On Tue, Apr 21, 2015 at 11:20 PM, Rafael Benevides > > wrote: > > This is enforced by QE. I don't know what they use to do that but > maybe > Paul Gier or Marek N can answer that (I'm copying them). > > QSTools provides a GUI for add/remove these repositories but it > needs a > human interaction to choose the proper ones. > > On 4/21/15 16:53, Max Rydahl Andersen wrote: > > On 21 Apr 2015, at 15:32, Rafael Benevides wrote: > > > >> Np, Max. > >> > >> They will be used just "if required" for dependencies that were not > >> released yet because we want/need that the -develop branch > should be > >> buildable for Quickstarts contributors. > >> > >> During the productisation procedures, the only repository allowed > >> will be "maven.repository.redhat.com > ". > > > > ah yes, now I remember. > > > > Can you point me to where that is enforced ? > > > https://github.com/jboss-developer/maven-qstools-plugin/blob/master/config/qstools_config.yaml#L24 > > seem to just be the global list ? > > > > /max > > > >> On 4/21/15 03:54, Max Rydahl Andersen wrote: > >>> On 20 Apr 2015, at 20:39, Rafael Benevides wrote: > >>> > >>>> Hi all, > >>>> > >>>> The definition in pom.xml was included as part of > >>>> EAP 7 plan: https://mojo.redhat.com/docs/DOC-1020116 > >>> > >>> I noticed this linked to a link that says a repo named > >>> "temp-maven-repo" is in the list of approved repositories ? Is > that > >>> really intended ? > >>> > >>> And why is the very global > >>> repository.jboss.org/nexus/content/groups/public > allowed > in here ? > >>> We are supposed to *not* depend on that repository in any form of > >>> fashion during productisation aren't we ? > >>> > >>> p.s. I think I've asked the above before so i'm sorry if I > forgotten > >>> - if there is a good reason I think we should add that in the > >>> comments of the qstools-plugin :) > >>> > >>> /max > >>> > >>>> > >>>> > >>>> On 11/14/14 07:38, Pete Muir wrote: > >>>>>> On 14 Nov 2014, at 10:51, Max Rydahl Andersen > >>>>>> > wrote: > >>>>>> > >>>>>>>>> Can you please review > https://mojo.redhat.com/docs/DOC-997344 > >>>>>>>>> and confirm if > those > >>>>>>>>> ids are ok. If not, do you mind to place the right > information > >>>>>>>>> at the document? > >>>>>>>> sorry for late response. > >>>>>>>> > >>>>>>>> Looking at this list the only two repositories I consider > valid > >>>>>>>> in production quickstarts > >>>>>>> production quickstarts aren?t actually a thing :-p > >>>>>> What word do we use for it then ? it's not community > quickstarts > >>>>>> since they depend on productized bits. > >>>>> Product quickstarts. > >>>>> > >>>>>>>> are: > >>>>>>>> > >>>>>>>> redhat-techpreview-all-repository > >>>>>>>> http://maven.repository.redhat.com/techpreview/all/ > >>>>>>>> > >>>>>>>> > >>>>>>>> redhat-earlyaccess-all-repository (for things not GA) > >>>>>>>> https://maven.repository.redhat.com/earlyaccess/all/ > >>>>>>>> > >>>>>>> These ^^^, plus fusesource, are valid for non-earlyaccess > >>>>>>> quickstarts > >>>>>> So the earlyaccess repo is valid for non-earlyaccess > quickstarts > >>>>>> ? seems counterintuitive ? > >>>>> Yes. A quickstart may be in beta, or a product may be in beta. > >>>>> These things are orthogonal. > >>>>> > >>>>>>>> These are I'm surprised we are now letting in: > >>>>>>>> > >>>>>>>> Jboss public repo is not something our productized nor > project > >>>>>>>> quickstarts should depend on is it ? Was there not a > >>>>>>>> requirement for quickstarts > >>>>>>>> to *not* rely on this repo that is a big mashup of > dependencies > >>>>>>>> and instead only rely on central published artifacts ? > >>>>>>>> jboss-public-repository > >>>>>>>> https://repository.jboss.org/nexus/content/groups/public/ > >>>>>>>> > >>>>>>> This ^^^ is valid only for earlyaccess quickstarts > >>>>>> ...so earlyaccess quickstarts is even earlier than what is in > >>>>>> earlyaccess maven repo ? > >>>>>> > >>>>>> Just trying to do the mapping since this is what we call > >>>>>> community quickstarts on jboss tools end and we keep it clearly > >>>>>> separate from production related stuff > >>>>>> to avoid/reduce confusion. > >>>>> Correct. It?s much closer to what you call early access in > JBDS - > >>>>> features that aren?t ready to go in to the product yet. > >>>>> > >>>>>>>> Fuse reposource repo I thought was only being used for > old fuse > >>>>>>>> releases ? If that is no longer the case then that is not > great > >>>>>>>> since > >>>>>>>> it seem to have a lot of redundancy of artifacts. > >>>>>>>> fuse-public-repository > >>>>>>>> https://repo.fusesource.com/nexus/content/groups/public > >>>>>>>> > >>>>>>> It?s still used for Fuse releases AFAIK. > >>>>>> mkay '/ - i'll try reach Aileen and here what is the plan > for it > >>>>>> and what is stopping them from getting into > >>>>>> maven.repository.redhat.com > . > >>>>>> > >>>>>>>> This repo I do not understand what is for and should not be > >>>>>>>> exposed anywhere IMO. Only relevant to put in testers own > >>>>>>>> settings.xml is it not ? > >>>>>>>> jboss-developer-staging-repository > >>>>>>>> http://jboss-developer.github.io/temp-maven-repo/ > >>>>>>>> > >>>>>>> Agreed, this one should never appear in a POM. > >>>>>> +1 > >>>>>> > >>>>>> /max > >>>>>> > >>>>>>>> About the ID's correctness/alignment with our tools that is > >>>>>>>> something Fred should be able to verify better than I. > >>>>>>>> > >>>>>>>> /max > >>>>>>>> > >>>>>>>>> Pete/Max, > >>>>>>>>> > >>>>>>>>> Do you know if Fuse maven repository still valid ? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> > >>>>>>>>> On 10/31/14 11:56, Rafael Benevides wrote: > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> I was thinking about the implementation of the repository > >>>>>>>>>> definition in pom.xml and I want to share my thoughts: > >>>>>>>>>> > >>>>>>>>>> - Create a QSTools CHECKER to mark the lack of > > >>>>>>>>>> as a guideline violation if MavenCentralChecker is > disabled. > >>>>>>>>>> - The violation message will instruct to use the new > QSTools > >>>>>>>>>> GOAL that will be created > >>>>>>>>>> > >>>>>>>>>> - Create another QSTools GOAL to setup the repositories. > >>>>>>>>>> - There will be a list of approved repositories and its IDs > >>>>>>>>>> (redhat techpreview, earlyacess, jboss developer > temporary, etc) > >>>>>>>>>> - QSTools will remove all previous repositories from > pom.xml > >>>>>>>>>> and prompt which repositories should be added. > >>>>>>>>>> - This will help Quickstarts and demos to be easily > buildable > >>>>>>>>>> from development and production branches and will also > allow > >>>>>>>>>> this list to be bulk updated to remove any previous > >>>>>>>>>> development repository definition. > >>>>>>>>>> > >>>>>>>>>> Please, > >>>>>>>>>> > >>>>>>>>>> If you have any feedback on this, feel free to reply. > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> > >>>>>>>>>> *Rafael Benevides | Senior Software Engineer* > >>>>>>>>>> JBoss Developer > >>>>>>>>>> M: +55-61-9269-6576 > >>>>>>>>>> > >>>>>>>>>> Red Hat > >>>>>>>>>> > >>>>>>>>>> Better technology. Faster innovation. Powered by community > >>>>>>>>>> collaboration. > >>>>>>>>>> See how it works at www.redhat.com > > >>>>>>>>>> > > >>>>>>>>>> > >>>>>>>>>> LinkedIn >>>>>>>>>> > Youtube > >>>>>>>>>> >>>>>>>>>> > > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> jbossdeveloper mailing list > >>>>>>>>>> jbossdeveloper at lists.jboss.org > > >>>>>>>>>> > > >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> jbossdeveloper mailing list > >>>>>>>>> jbossdeveloper at lists.jboss.org > > >>>>>>>>> > > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper > >>>>>>>>> > >>>>>>>> > >>>>>>>> /max > >>>>>>>> http://about.me/maxandersen > >>>>>> > >>>>>> /max > >>>>>> http://about.me/maxandersen > >>> > >>> > >>> /max > >>> http://about.me/maxandersen > > > > > > /max > > http://about.me/maxandersen > > _______________________________________________ > jbossdeveloper mailing list > jbossdeveloper at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossdeveloper > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20150430/8048d153/attachment-0001.html