[forge-dev] JBoss Stacks: Requirements

James Perkins jperkins at redhat.com
Tue Jul 3 11:53:35 EDT 2012

On 07/03/2012 08:20 AM, Pete Muir wrote:
> On 3 Jul 2012, at 16:14, James Perkins wrote:
>> The main idea behind the supportVersions (probably a bad name) was something like:
>> 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.
I see now. The more I think about it, the more I agree. it's probably a 
bad idea. Using a properties based approach you describe below would 
work for this.
>> 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 for anything.
> We could do that as well.
>    7.0.1.Final:
>      properties:
>        arguments: -logmodule
>        cli: not-available
I like this approach.
>> 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.
Works for me. I have no real need for it. Just thought if it was useful 
for others, I would use it too.
James R. Perkins
JBoss by Red Hat

More information about the forge-dev mailing list