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

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936522#comment-12936522 ] 

Rob Stryker commented on WFLY-2766:
-----------------------------------

One of the issues I see here is that users often start off with minimal dependencies and then add more. In the past we've made most APIs available on the classpath. Take this example:  A user makes a web project, and for a few days just makes servlets and business logic. Then they decide they need mail added.   How would they go about adding this dependency?

If the jars aren't already on the classpath, they won't be able to autocomplete their mail packages as they try to type them in. How would the user be expected to indicate they need mail so that typing in mail works for auto-complete? 
                
> .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