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