Thanks for reporting.
I'll work on that.
I removed the master branch (default to 1.0.0.Final now) since it was
causing too many confusions when people wanted to open a PR.
Em 16/08/13 15:02, Lincoln Baxter escreveu:
Looks like the link to the stacks.yaml file is broken on this guide
btw-
http://www.jboss.org/jdf/stack/plugin-jdf/
----- Original Message -----
From: "Pete Muir" <pmuir(a)redhat.com>
To: "Max Rydahl Andersen" <manderse(a)redhat.com>
Cc: "Rafael Benevides" <benevides(a)redhat.com>, "Fred Bricon"
<fbricon(a)redhat.com>, "jdf-dev" <jdf-dev(a)lists.jboss.org>, "Max
Rydahl Andersen" <max.andersen(a)redhat.com>, "Lincoln Baxter"
<lbaxter(a)redhat.com>, "George Gastaldi" <ggastald(a)redhat.com>
Sent: Friday, August 16, 2013 1:14:01 PM
Subject: Re: [jdf-dev] Stacks 1.1 format proposal
Can't we add metadata to stacks for this particular thing:
product: eap
enterprise: true|false
and then you can pick the one you want.
On 16 Aug 2013, at 09:17, Max Rydahl Andersen <manderse(a)redhat.com> wrote:
> 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