[jdf-dev] New versioning and organisation strategy

Sat Jul 6 03:22:21 EDT 2013

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.

Now I'm on pto - see you 3 weeks. 

/max (sent from my phone) 

> On 04/07/2013, at 16.23, Rafael Benevides <benevides at 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 at 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev
>>>> 
>>>> _______________________________________________
>>>> jdf-dev mailing list
>>>> jdf-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jdf-dev
> 
> <Newversionandorganizationstrategy.pdf>
> _______________________________________________
> jdf-dev mailing list
> jdf-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jdf-dev