>> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev