]
Tomaz Cerar commented on WFCORE-424:
------------------------------------
[~brian.stansberry] looks like another good example where introducing "class
loading" subsystem could be useful, this way it could expose deployment model with
this info. But that only applies for deployed apps.
.jar's on "current runtime classpath"
-------------------------------------
Key: WFCORE-424
URL:
https://issues.jboss.org/browse/WFCORE-424
Project: WildFly Core
Issue Type: Feature Request
Components: Modules
Reporter: Ondrej Zizka
Assignee: David Lloyd
Fix For: 1.0.0.CR1
(Based on JBDS use case - see EAP6-1)
In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven
project, against a remote server, ...(?) )
The classpath would be:
* for the deployment after deployed
* for a generic deployment if it was deployed right now - what would WildFly use?
* for the deployment before deployed - sounds a bit advanced but technically possible
We (David, Stuart, Jason, Max, Ondra) have discussed this on EAP F2F 2014.
The output was that we don't need exact classpath / list of jars which would probably
end up being almost all modules; rather we need the direct deps. As someone said -
"just to get rid of the red lines in the IDE".
The non-maven compilation use case is that the user has a server in a directory, and the
jars to build against should all be in there. So the IDE should be able to ask WildFly for
a list of .jar's to build the application against, and just use that instead of
forcing the user to gather them manually.