On 25 Apr 2013, at 23:27, Max Andersen <manderse(a)redhat.com> 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.
Okey - so either we need some extra metadata somewhere to know which archetype of now
many to choose the right archetype for javaee project.
Or we now require users to select specific runtime before starting to create a project (I
would really not like that since its technically not needed).
Also need to get something in to know which of the two repositories we need to
add/suggest. Earlyaccess or the supported one.
Note - I assume we'll
Still introduce wildfly 8 etc into stacks.yml to get feedback/testing done early here,
correct or?
Yes. I think we can still add upstream stuff to stacks. We may need a way to indicate this
in the format as well.
>
>> 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.
Ok. Any reason to not use -redhat then ?
Is that because they will now be considered a separate deliverable ?
We didn't want to overload the meaning of -redhat-X, but we could do so if you guys
think it is best.
> We would no longer bundle them in the product zip repos, instead just deliver them
online via
maven.repository.redhat.com
Okey so we can't count on them when users have just the zips for the offline mode.
Just something to remember to copy when we go offline.
Yes. These are now an overlay so don't belong to a particular project. I guess we
could do a zip of the overlay if it's really needed.
>
>>
>> /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
>