[
https://issues.jboss.org/browse/WFLY-2766?page=com.atlassian.jira.plugin....
]
Max Rydahl Andersen commented on WFLY-2766:
-------------------------------------------
[~rob.stryker] that question is more on the IDE side to solve not wildfly. We would still
need to include more than they actually ask for - i.e. the javaee spec api jars would be a
basic start, or simply map from eclipse facets to the groupings used in wildfly.
.jar's on "current runtime classpath"
-------------------------------------
Key: WFLY-2766
URL:
https://issues.jboss.org/browse/WFLY-2766
Project: WildFly
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Class Loading, CLI
Affects Versions: 8.0.0.CR1
Reporter: Ondrej Zizka
Assignee: David Lloyd
Fix For: 9.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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira