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