Re: [jdf-dev] Stacks 1.1 format proposal - THE FORMAT WON'T BE UPDATED

Fred, Awesome!!!!! Thanks for testing! For the last, I think we should now check the details around the archetypes (cc Max): - We can just change the GAV and keep the enterprise flag, but it seems that this won't work. Can you confirm that?

- Or totally split the enterprise and "sandbox" archetypes. We can add a label on enterprise ArchetypeVersion on Stacks to identify them.

Thanks once more, Fred. Em 28/08/13 18:31, Fred Bricon escreveu: > Le mardi 27 août 2013 18:34:45, Fred Bricon a écrit : >> Le mardi 27 août 2013 16:11:22, Rafael Benevides a écrit : >>> Hi everybody. >>> >>> After thinking about the effort, management cost, the pro and cons and >>> the benefits that we could get by updating the format I got the >>> following conclusion: >>> >>> IT DOESN'T WORTH TO UPDATE THE FORMAT NOW. >>> >>> We can survive with the workarounds proposed on the first email with >>> the justification of the changes. I'll update the new organization >>> plan to keep the 1.0 format but I'd like to check about moving stacks >>> repo from jdf repository to the new one. >>> >>> As on previous e-mail I saw that github redirects works pretty well >>> with http 301 - moved permanently. >>> >>> I want to get sure that JBDS/JBT can work with this redirection. >> I'll perform some tests tomorrow to check if it works >> > After adding > -Dorg.jboss.tools.stacks.url_stacks=https://raw.github.com/fbricon/jdf-stack/1.0.0.Final/stacks.yaml > to jbdevstudio.ini in JBDS 7.0.0GA, > JBoss central shows the correct stacks (botched on purpose) from > https://raw.github.com/open-archetypes/jdf-stack/1.0.0.Final/stacks.yaml. > > So we're cool. > > >>> >>> Em 26/08/13 06:14, Max Rydahl Andersen escreveu: >>>> On Thu, Aug 22, 2013 at 11:50:46AM -0300, Rafael Benevides wrote: >>>>> 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 ? >>>> >>>> It is not that simple. >>>> >>>> You need list of key artifacts to check for - if the user already >>>> have that available in >>>> their company repository then it is noise to add this url. >>>> >>>> That is why we check if we can resolve the key artifacts, and if they >>>> can't *then* we >>>> suggest adding that repository. >>>> >>>> /max >>>> >>>>> >>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> >> >> _______________________________________________ >> jdf-dev mailing list >> jdf-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jdf-dev > >