[wildfly-dev] Classpath management for as7.2 / eap6.1 / wildfly

[Max Rydahl Andersen]

On Tue, May 07, 2013 at 08:26:24AM -0500, David M. Lloyd wrote:
>On 05/07/2013 07:25 AM, Max Rydahl Andersen wrote:
>>> From what I know of our current schedule, I'm afraid you should not
>>> count on this for the 8.0.0.Alpha1 release.
>>
>> Okey - but we need *something* for AS 7.1+/EAP 6.0+ ..or you should be ok
>> with us "guessing" the list of jars to add...
>>
>> Is there anyway we can figure out the jar location for a set of jars
>> based on a list of module names ? i.e. one that you guys would not call
>> "broken and not supported"  ? :)
>> i.e. a "jboss module/AS aware jar locator"
>>
>> I'm thinking we get our eclipse tooling to understand module names and
>> then use this locator
>> to get the proper jars would be a great start.
>>
>> Then add ons like the txt in root of distribution can be tweaked out on
>> top of this.
>> (since we would need this 'locator' for the txt file anyway - especially
>> with layering and patching
>> being added making hardcoded fileset's not good)
>>
>> Would that be doable ?
>
>Possible, but a lot more work than #1/#2 that I've mentioned, and may
>require resources that are already booked up.  Is there any reason the
>two suggestions I made would not suffice?  Putting things in the
>filesystem is a trivial effort compared to creating APIs that have to be
>supported.

#1 is about identifying the server - seperate problem and not really about classpath definition.
#2 would need to locate the jar info...

/max

>> /max
>>
>>>
>>> The solutions which seem applicable to your concerns which Max and Brian
>>> and I talked about included the following:
>>>
>>> 1. A single top-level txt file whose complete content is the release
>>> name e.g. "WildFly 8" or "JBoss EAP 6.2" etc. (this should be easy)
>>> 2. Packaging JBDS Facet definitions in a well-defined place which
>>> includes the class path information for each technology
>>>
>>> We can definitely do #1 without any substantial effort.  For #2 we would
>>> definitely count on input from you guys (we have no idea what these
>>> definitions look like, though it does seem clear we'd have to use build
>>> information in part to generate these files to ensure the exact JAR
>>> paths (or at least Maven GAV) are properly specified).
>>>
>>> Do you have any expectations beyond what I've listed here?
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>-- 
>- DML
>_______________________________________________
>wildfly-dev mailing list
>wildfly-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/wildfly-dev