On Mon, Jul 08, 2013 at 02:40:56PM +0100, Pete Muir wrote:
>
> On 6 Jul 2013, at 08:22, Max Andersen <manderse(a)redhat.com> wrote:
>
>> 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.
coming back from pto and its great there will be archetypes for WF8 but that doesn't
solve the problem of knowing which of now potentially many archetypes for a javaee web app
should be used front and center in JBDS Central and we'll need to have
maven.enterprise.redhat.com added to users settings.xml for them to work.
Before we had a default one which could switch between community and product - what do we
use in replacement for that 'ease-of-use' feature ?
/max
>>
>> 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
>