Re: [jdf-dev] Stacks 1.1 format proposal

MAx, About the metadata: I don't know yet what other metadata is need here and yes it is just to avoid repeating. That's why I thought to use a general name "metadata" to give us more flexibility if something new appears. But that's the minor issue. I'm really concerned about the need to have the repository URL information for BOMs and I didn't want to have this as a Label unless that we judge that we can't change the stacks format. Btw, For how long time we should maintain the stacks format 1.0 ?

Em 12/08/13 11:52, Max Rydahl Andersen escreveu: > > 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 >>