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