Re: [jdf-dev] Stacks 1.1 format proposal

On Mon, Aug 19, 2013 at 11:55:17AM -0300, Rafael Benevides wrote: > Ha! > > We just talked about that on today's meeting! One more reason to > update stacks format ;) yes, I think this has merrit but if I grok the updated version model won't there be a 1-N mapping here ?

i.e. JavaEE project archetype will exist in multiple versions, community version for wildfly 7, then EAP 6 version, soon wildfly 8 ?

Also JavaEE project will need to target different runtimes x different specs (for now JavaEE 6 but JavaEE 7 will be there soon). > 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 >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> >