Re: [jdf-dev] Stacks 1.1 format proposal

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 >>>>>>> >>>>> >>> >