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

Max Rydahl Andersen manderse at redhat.com
Tue May 7 13:16:27 EDT 2013


>>> 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.

hmm - wouldn't it be better to have just list of modules in these files
and then we look it up in the modulepath of the specified server ?

or do you expect that file to have releative paths from the module path
to specific files ? Won't that fall apart if users modifies/adjust the 
installed modules somehow ? will it honor patched bits ?

>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.

Sure - we need to get this in place too. But I suggest we put that in
 a seperate jira/thread. 


/max

>-- 
>- DML
>_______________________________________________
>wildfly-dev mailing list
>wildfly-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/wildfly-dev


More information about the wildfly-dev mailing list