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

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