Any usecases? What IDEA's interfaces would benefit from such a separation?

---

Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"

My main one is accuracy of compilation inside the IDE matching that of the external build system. If you introduce a library specifically for testing, you want a safeguard about using it in non-test code without having to think twice. The build scripts obviously have them separate, so it currently has the possibility of succeeding in IDEA, then failing at the build.

In IDEA's interface, it would also help to make some more sensible defaults for what gets packaged in WARs and other J2EE function (no need for test libraries like junit in a WAR).

Ok, I see. Quite reasonable indeed.

This is an twist on multiple old requests for "runtime-only" libraries. For instance, it is quite reasonable to need a JDBC driver to run against, but you essentially never want to actually use any classes out of a JDBC driver jar in production code.

On big win for this is in completion. No need for the completion engine to know about runtime-only classes.

I have a good use case for this. Currently I have 2 modules: A and B.
Both A and B have source and test folders and B depends on A.
IntelliJ does a great job of making sure:

• B src can access A src
  
• B test can access A test
  
• B test can access A src
  
• B src CANNOT access A test

But now I want to jar up A's test and src files.
I can't add both A-src.jar and A-test.jar to B's library b/c then that would mean B src CAN access A tests!

So it would be great if I can add A-src.jar to the src library and A-test.jar to the test library of the B module.
I would prefer not to have to split the B module into 2 modules: Bsrc and Btest.
This is what I'm doing currently, and it's not very clean.

I will like to comment on how I think this is best implemented and how I will use it.

In the module setting's order/export tab, have 2 additional checkbox column (in addition to the export checkbox column). These 2 columns will be "Test Only" and "Runtime Only". These 2 columns are defaulted to unchecked.

Here's the behavior matrix:

Test Only Runtime Only Behavior
-------------

---

---

The library/module can be used by both source code and test code for compilation and runtime

X The library/module can be used only by both test code for compilation and runtime

X The library/module can be used by both source code and test code for runtime only

X X The library/module can be used only by both test code for runtime only


When "Test Only" is not checked for a module, then the dependency is the same as the current implementation: Test can depend on source but not vice versa. When it is checked, then only this module's test code can use that dependent module's code.

I would expect these settings to be exported as such also. For example, if module B depends on module A, and module A has a library L that is marked as "Test Only" and "Runtime Only" and "Exported. Module B can only access library L when running tests.

It will be very useful to have this implemented. With it, I can then have JDBC drivers marked as "Runtime Only" and compile will throw an error if my source code uses this runtime library. Another example is I can have junit.jar marked as "Test Only" and only my test code can use the junit library. I'm sure people will have use cases for when both "Test Only" and "Runtime Only" need to be checked. One example I can think of is if you want to run tests against an experimental jdbc library because it's faster, but you don't want to use it for normal runtime because it's not stable. So in the order/export tab you will see something like this:

Test Only Runtime Only Library
-------------

---

---

X X jdbc-experimental.jar

X jdbc.jar

When you are running tests, jdbc-experimental.jar appears before jdbc.jar, so the runtime classes will first see jdbc-experimental.jar and use those classes. And when you are running the source, only the regular jdbc.jar is available.

I think this will be a very useful feature. I hope to see it implemented soon. Thanks!

This would allow for reasonable workaround for IDEA-3692, by making plugin modules empty modules which depend on pure java libraries. Then depending modules could add compile-time dependency on the java module which contains the depended plugin classes, but actually use the plugin's classes at runtime via <depend>

What's the status on this?

I have a situation where my application is bundled with a cache of data which it then updates at runtime by downloading from a server. When I run the application in idea I have this bunded cache of data as a module library so it can be accessed at runtime (ie the same setup as the application running in the real world).

In my tests, I don't want to use this same cache of data - instead I want to have a separate copy of the cached data which I check into CVS so I know it will never change, and my tests will run consistantly. Unfortunately the only way to do this is to have this separate copy as a module library.

Here I have two problems:
1. I have two sets of cached data as module libraries, and need to change the order depending on whether I'm running the app or running the tests.
2. More importantly, if I forget to change the order back (manual processes are error prone) then when running my application I end up using my test data. This is very bad.

Given that you separate test code from application code, surely it also makes sense to separate the libraries those codebases rely on?

Could someone please update this bug with an indication of:
1. Is more user input required?
2. Has it been implemented?
3. Will it be implemented?

Thanks.

IDEA-15474 gives some more thoughts on configurable classpaths.
Also corresponding to this issue forum thread ( http://intellij.net/forums/message.jspa?messageID=5195750 ) has notion of significant resources waste on useless caching and indexing of runtime-only libraries.
So I join to previous commenter's questions. :)