Just had a look and if this Still means the archetypes now wont be
shared ( there will be different GAV's for community and product) I'm missing how
we'll know which to show/use in jboss central - and if it's all enterprise then it
becomes impossible to use/try these without adding
maven.enterprise.redhat.com to
settings.xml.
The latter is probably just what me must live with but the "multiple
archetypes" for javaee web app and no easy way to have these for I.e. wildfly 8
Before Productization has content ready worries me.
We definitely plan to have archetypes for WF8, just in the sandbox, not in the main repo.
Now I'm on pto - see you 3 weeks.
/max (sent from my phone)
> On 04/07/2013, at 16.23, Rafael Benevides <benevides(a)redhat.com> wrote:
>
> After considering the feedback and after more brainstorming over the migration plan,
we have a now a more detailed and tunned proposal on the new versioning and organization
strategy. In the attached PDF you will find this detailed plan with all artifacts changes
needed.
>
> It's also a good opportunity to update stacks.yaml format (and client) to 1.1.0
>
> Please, take a look on the attached plan and let us know what you think about it. The
migration work should start by now on developer branches.
>
> Thank you
>
> Em 25/04/13 14:18, Rafael Benevides escreveu:
>> One thing that came in my mind is when to move the versions of Archetypes,
Runtimes and BOMs to Stacks.yaml?
>>
>> I used to add only .Final (will be -bom-x) version of BOMs to Stacks.yaml.
>>
>> In the Case of Archetypes, I'm continuously updating it to the latest version
(even being a CR - Candidate Release).
>>
>> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it with the
"Early Access" label.
>>
>> Do we still follow this schema ?
>>
>> BOM: Only -bom-X release ?
>> Archetypes: Every -atype-X release ?
>> Runtime: Every "Early Access" and Product release ?
>>
>> By the way? How will we differ the "Candidate Release" from
".Final" Release ?
>>
>> Em 25/04/13 11:20, Marek Novotny escreveu:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>> On 04/25/2013 04:13 PM, Pete Muir wrote:
>>>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen
<manderse(a)redhat.com> wrote:
>>>>>
>>>>> Trying to grok consequences.
>>>>>
>>>>> On first read it seems it does not change anything - stacks.yml will
just refer to these and we can use them.
>>>>>
>>>>> But will the archetypes still support enterprise=true|false flag ?
>>>> No. They will be product only. There may be other upstream community
archetypes, but they will be project specifically.
>>>>
>>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into
products or does that go away for these cases?
>>>> No, these are the product BOMs.
>>>>
>>>> We would no longer bundle them in the product zip repos, instead just
deliver them online via
maven.repository.redhat.com
>>> that supposes to finish/change the uploading process as
>>> maven.repository.redhat.com's content is currently only extracted
>>> product zips.
>>>>> /max
>>>>>
>>>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil,
and came up with the following proposal:
>>>>>>
>>>>>> * jdf plugin for forge - longer term needs rolling into Forge
core. This is issue
https://issues.jboss.org/browse/FORGE-378. As this is proposed for
Forge 2, we suggest not altering the version or group id of this plugin
>>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id
when we do the next major release only
>>>>>> * quickstarts
>>>>>> - change group id to follow products:
>>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc.
>>>>>> - add a sandbox group id which covers quickstarts not in
products
>>>>>> - change versions to follow products major.minor.micro version,
with a qualifier to allow bug fixes:
>>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc
>>>>>> * archetypes
>>>>>> - use group id scheme same as quickstarts but use
org.jboss.archetype.eap etc.
>>>>>> - follow same version scheme as quickstarts, but use -atype-1
etc.
>>>>>> * BOMs
>>>>>> - use group id scheme same as quickstarts but use
org.jboss.bom.eap etc.
>>>>>> - follow same version scheme as quickstarts, but use -bom-1
>>>>>> - projects will be encouraged to create BOMs as well
>>>>>>
>>>>>> Let me know what you think,
>>>>>>
>>>>>> Pete
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>> - -- Marek Novotny
>>> - -- WFK and Seam Product Lead
>>>
>>> Red Hat Czech s.r.o.
>>> Purkynova 99
>>> 612 45 Brno
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>> Comment: Using GnuPG with undefined -
http://www.enigmail.net/
>>>
>>> iEYEARECAAYFAlF5O8sACgkQU4HO8G8hNxXwkACdHa/hQ2cX1lF7FfjB7KblcaWF
>>> HZIAoLpXaKeyW4aEu9eWk/m+Pu75PvcY
>>> =68YA
>>> -----END PGP SIGNATURE-----
>>>
_______________________________________________
>>> jdf-dev mailing list
>>> jdf-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jdf-dev
>
> <Newversionandorganizationstrategy.pdf>
> _______________________________________________
> jdf-dev mailing list
> jdf-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jdf-dev