[jboss-jira] [JBoss JIRA] (WFCORE-424) .jar's on "current runtime classpath"

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-424:
------------------------------------
    Component/s:     (was: CLI)


I'm removing the CLI component as I don't see the need for anything specific in the CLI other than the core ability to execute whatever low-level ops a user types in.

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



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)