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