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

[David M. Lloyd]

On 05/07/2013 09:15 AM, Max Rydahl Andersen wrote:
> 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...

What about (for #2) a file (or files) that maps whatever your facet 
types are to module names and JAR paths, directly?  It seems like it 
should be possible to generate that information at build time.  If we do 
this right, then any add-ons should be able to add their definitions 
when they are installed.

I think #1 is important because if (when?) we make a mistake for #2 on a 
particular release, then you can at least patch JBDS later on to detect 
the faulty version and patch in the right paths.

-- 
- DML