Re: [jdf-dev] Stacks 1.1 format proposal

Fred/Max I was thinking about this, and I have the following proposal. Please feel free to comment: Today on 1.0 stacks there's the repositoryURL attribute on both Archetype and ArchetypeVersion. Shouldn't we say that a non-empty repositoryURL means that it needs to add that URL to the ~/.m2/settings.xml ?

Em 19/08/13 11:31, Fred Bricon escreveu: >We could treat enterprise versions the same way we currently treat >"blank" versions. >i.e. the default (community) archetype would have an enterprise >attribute pointing at the corresponding archetype. >See https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 >for instance. > > >Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : >>On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >>> >>>Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>>>On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>>>>You're right Max. >>>>> >>>>>That was the proposal. And we should think a little bit more >>>>>about the workflow since the plan is to change Archetypes >>>>>GAV to: org.jboss.archetypes.eap: >>>>>jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>>> >>>>>I believe that the "product focus" idea is to have this EAP >>>>>archetypes as the default of "Create a Java EE XXX app..." >>>>>(without enterprise flag) but my concern is about the setup >>>>>of EAP repository setup. >>>> >>>>That part is the smallest problem ;) We already support it. >>>> >>>>Try create an enterprise archetype in JBDS while running with >>>>~/.m2/settings.xml that does >>>>*not* have access to the enterprise artifacts. We'll warn and >>>>guide you to add maven.repository url) >>>> >>>>We do that based on a list of key artifacts we check - this is >>>>currently outside stacks.yml, >>>>but could probably make sense to add this bit of info so other >>>>than jbds can do similar things. >>>> >>>>My main concern is how to find out which archetypes that >>>>matches and how to toggle/manage them. >>> >>>Shouldn't this new GAV change help you to find out ? >> >>I would rather not rely on GAV to decide that if can be avoided. >> >>But your suggestion is that the group "org.jboss.archetypes.eap" >>decides it - >>which would be the "non-product" version ? there is no 1-to-1 mapping. >> >>Thing is that we loose the ability to toggle when the mvn wizard >>is running - the decision have to be made upfront. >> >>But I think we'll just have to drop that "feature" and force users >>to know more upfront - >>possibly in the case no runtime is known give them a choice of >>possible archetypes for JavaEE ? >> >>Fred - do you forsee issues/concerns ? >> >>/max >> >>>> >>>>/max >>>> >>>> >>>>>I could be wrong but that's is how I understand that part of >>>>>the plan. >>>>> >>>>> >>>>>Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>>>On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>>>I probably missed it but where does it say the >>>>>>>enterprise flag goes away for archetypes? >>>>>> >>>>>>thats in the other thread(s) about changing the way things >>>>>>are released/versioned. >>>>>> >>>>>>Here it was suggested archetypes would be productized >>>>>>similar to quickstarts, thus >>>>>>there would be forks/duplicates instead of one version we >>>>>>could use and then toggle >>>>>>between one or the other target..thus no enterprise flag. >>>>>> >>>>>>At least thats how I understood the proposal and we should >>>>>>work with Rafael on >>>>>>that. >>>>>> >>>>>> >>>>>>/max >>>>>> >>>>>>>Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>>> >>>>>>>>On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>>>>>>>>Hi all, >>>>>>>>> >>>>>>>>>I'm resurrecting this subject because Forge Team >>>>>>>>>started to brainstorm about the Stacks Add-on to >>>>>>>>>Forge. >>>>>>>>> >>>>>>>>>Max, >>>>>>>>> >>>>>>>>>Do you have some thoughts/considerations on this: >>>>>>>>> >>>>>>>>>- Change format (getting the opportunity of repo location change) >>>>>>>>>vs >>>>>>>>>- Still using the same format with workarounds >>>>>>>> >>>>>>>>I would like that Fred B. takes a look at this and >>>>>>>>give his feedback since he been doing most of the >>>>>>>>license/repositoryurl workarounds we need. >>>>>>>> >>>>>>>>But from top of my head: >>>>>>>> >>>>>>>>I don't see how stacks 1.0 can change location (i.e. >>>>>>>>url) since that will break JBDS 7.0/JBT 4.1 users. Are >>>>>>>>you really talking about a physical move, or simply >>>>>>>>where you would out the "next" version ? The 1.0 url >>>>>>>>is stuck and should stay there for years from what I >>>>>>>>can see. >>>>>>>> >>>>>>>>About "rename licenses to metdata"...I never realized >>>>>>>>those names were tied to element defined as licenses. >>>>>>>>Shouldn't it be licenses AND releaseversions or >>>>>>>>something ? what other metadata is needed here ? >>>>>>>>...and if it is just to avoid repeating it is this >>>>>>>>just like "entities" like in a DTD ? >>>>>>>>About "repositoryUrl and extrarepositories" to >>>>>>>>bomversion then this seem to be a variation on how we >>>>>>>>in eclipse decides wether we need to add something to >>>>>>>>the users settings.xml or not ? In that case then >>>>>>>>repositoryurl/extrarepositories are not the only >>>>>>>>information relevant. Its more relevant to know which >>>>>>>>key artifacts to look for. We added that to our own >>>>>>>>examples metadata - Fred knows more. >>>>>>>> >>>>>>>>Then based on the availability of these artifaacts we >>>>>>>>either warn or not. If a warning we then suggest to >>>>>>>>add maven.enterprise.redhat.com/techpreview/all to the >>>>>>>>~/.m2/settings.xml. We do *not* add invidivual >>>>>>>>repositories (like EAP600 and EAP601) to users >>>>>>>>settings nor pom.xml - that would be bad form IMO. In >>>>>>>>any case - I don't think repositoryurl and >>>>>>>>extrarepositories are good on its own - needs more >>>>>>>>info. >>>>>>>> >>>>>>>>My biggest gotcha with upcoming changes is how the >>>>>>>>tools can/should cope with archetypes not having >>>>>>>>enterprise flag anymore. That at least from where I'm >>>>>>>>looking changes the workflow we need to provide to the >>>>>>>>user since we just starts with user requesting "Create >>>>>>>>a JavaEE Web app" ...and how do we ensure the >>>>>>>>archetypes stay consistent (before just a simple flag) >>>>>>>>now its spread between multiple repositories/archetype >>>>>>>>versions. >>>>>>>> >>>>>>>> >>>>>>>>/max >>>>>>>> >>>>>>>>> >>>>>>>>>Thanks >>>>>>>>> >>>>>>>>>Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>>>Hi all, >>>>>>>>>> >>>>>>>>>>As part of the "new organization" plan, it's a >>>>>>>>>>good time to update stacks format since it will be >>>>>>>>>>hosted on the new github organization. >>>>>>>>>>I've analyzed the changes need and attached a >>>>>>>>>>Stacks 1.1 proposal to see if everyone agrees on >>>>>>>>>>that or if should we keep using 1.0 format >>>>>>>>>> >>>>>>>>>>Changes from 1.0 to 1.1 >>>>>>>>>> >>>>>>>>>>- Rename Licenses to Metadata >>>>>>>>>> >>>>>>>>>> Justification: I've been using Licenses today as an metadata >>>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>>> repositories, licenses, etc: >>>>>>>>>>https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Workaround: Leave it as it is >>>>>>>>>> >>>>>>>>>>- add repositoryURL and extraRepositories to BomVersion. >>>>>>>>>> >>>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>>> repositories are Required: >>>>>>>>>>https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Some BOMs needs more than one repo as JPP ( >>>>>>>>>>JPP is built on >>>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>>> >>>>>>>>>> Workaround: Create an standard tag called *repositories* and >>>>>>>>>> add every non maven central repository required. >>>>>>>>>> >>>>>>>>>>So I'd like to here your thoughts about it and >>>>>>>>>>analyze possible impacts on this format change. >>>>>>>>>>OBS.: Remember that stacks 1.0 repo is planned to >>>>>>>>>>be moved to jboss-developer github organization. >>>>>>>>>>So it's a good change to update it. The 1.0 and >>>>>>>>>>1.1 should coexist for a while and maybe >>>>>>>>>>stacks-client should have a "migration" feature to >>>>>>>>>>permit a smooth transition. >>>>>>>>>> >>>>>>>>>>Thank you >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>-- >>>>>>>>>>Rafael Benevides | Senior Software Engineer >>>>>>>>>>Red Hat Brazil >>>>>>>>>>+55-61-9269-6576 >>>>>>>>>> >>>>>>>>>>Better technology. Faster innovation. Powered by >>>>>>>>>>community collaboration. >>>>>>>>>>See how it works at redhat.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>_______________________________________________ >>>>>>>>>>jdf-dev mailing list >>>>>>>>>>jdf-dev(a)lists.jboss.org >>>>>>>>>>https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>>>> >>>>>>> >>>>> >>> >