On 3 Jul 2012, at 16:14, James Perkins wrote:
The main idea behind the supportVersions (probably a bad name) was
availableVersions: 7.0.0.Final, 7.0.1.Final, 7.0.2.Final, 7.1.0.Final, 7.1.1.Final
supportedVersions: 7.1.0.Final, 7.1.1.Final
Just meaning all available version should work, but everything is only guaranteed to work
with the supportedVersions. Maybe a Beta or CR could be in available, but not fully
supported as well. Just a thought that really isn't a big deal.
Yeah, I guess what I'm not getting, is *what* is supported in that version, as that
will change over time. That's why I was proposing a "labels" system, so you
can tag a version as having a capability (like cli or logmodule-needed or whatever). This
way we keep the info (I think) you want, but make it expandable.
What I think would be ideal if it's possible would be to have a properties section
with name value pairs. Then things like the -logmodule or -someOtherArgument could be used
We could do that as well.
I would think the AS downloads would always be a zip as well. If other consumers have no
use for a packaging type it can be left off. Really if we can have a properties section it
could be used in there if needed.
Let's leave it out for now, and Max can comment when he is back.
On 07/03/2012 05:22 AM, Pete Muir wrote:
> On 3 Jul 2012, at 00:23, James Perkins wrote:
>> On 07/02/2012 03:33 PM, Pete Muir wrote:
>>> I chatted with Max at JBoss World about requirements for what I'm
code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project.
>>> The JBoss Stacks project takes all the BOMs, all the archetypes, and all the
runtimes, and identifies which work with which. This can then be used by tools (like JBDS,
Forge, Maven plugins) to correctly configure users projects.
>>> The stacks project requires 3 different dictionaries:
>>> * available BOMs
>>> * available archetypes
>>> * available runtimes
>>> and the ability to see the intersection between these things (i.e. if I'm
on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what
archetypes are available, what is recommended).
>>> The runtime should include a download URL, so that plugins such as James'
AS plugin for forge can download it. It should also contain a some options. I'm not
sure exactly what is needed here, but James can provide details and what makes most
>> So far the only information I would need is the version number, the current
version (both seem to be taken care of so far) and whether or not the version of AS
requires the -logmodule argument for JBoss Modules. Really since that's kind of a
special use case it could just be hard-coded into the plugin code, but having some kind of
metadata for something like that would be ideal IMO.
> So, should we have:
> arguments: [ -logmodule, -someOtherArgument]
> logmodule-argument: required
> I think the former makes more sense.
>>> The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow
categorisation, filtering, sorting
>>> The Yaml parser in use should be pluggable, to avoid introducing uncessary
>>> There should be a recommended runtime per major version and per minor version
(so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can
say "I want JBoss AS 7.0" and you get back 7.0.2.Final).
>>> We're going to need to be careful about compat, eventually, so we need to
get everything in there, and get it right. We'll have a long beta cycle ;-)
>>> There will be a client utility, written in Java. This should be a single
source file, which projects can copy in. It must have no dependencies other than a Yaml
>>> I think Rafael is going to take the lead on this. But we'll decide on
Monday next week.
>> Overall I think this is a great idea. It will be great not to have to hard-code
versions and do a new release every time something new comes out.
>> One suggestion for the YAML;
> So far, what we have doesn't cover all the requirements I wrote here.
>> I see there is a availableVersions, which is great, but I also think a
supportedVersions could be useful.
>> For example in the Forge plugin there is an option to execute CLI commands. That
CLI API wasn't available until 7.1.1 IIRC. It *should* work for 7.0.x, but some
operations that are available 7.1.1 might not be available in 7.0.x.
> I'm not sure what this means. What would be "supported"? We could have
> supported: [cli, full-profile]
> for each version to indicate capabilities.
> Possibly we just generalise that, and your logmodule thing, to
> labels: [cli, logmodule]
> and use "labels" as a place to put extended metadata that some tools want
>> Also the packaging type could be useful too. Again with the AS 7 plugin it's
downloading a ZIP file and extracting the directory structure.
> I think I was assuming it would always be a zip... But we can add this.
James R. Perkins
JBoss by Red Hat