]
Brian Stansberry moved WFLY-2766 to WFCORE-424:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-424 (was: WFLY-2766)
Affects Version/s: (was: 8.0.0.CR1)
Component/s: Modules
CLI
(was: Class Loading)
(was: CLI)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
.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, CLI
Reporter: Ondrej Zizka
Assignee: David Lloyd
Fix For: 1.0.0.Beta1
(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.