Eclipse is indeed not very flexible about managing launch configuration. When launching the « application » of the Java project, it is fine to take time to tune things. But for unit tests, it is a pain. And especially as you pointed out is that Eclipse doesn’t allow to edit the container after creating it (for some reason it is hard coded within Eclipse that only a few kind can be edited).
So to be pragmatic, our projects always compile, run tests and run the app with the same classpath, a classpath which includes all that is needed for the 3 use cases (compile, test, run). Since each of the 3 use cases have their own Ivy configuration, theoretically, the computed 3 classpaths merge as a classpath which won’t correctly represent neither of the 3. In practice it works. And there is always the CI which will do the compilation and the test checks with the proper classpaths. And the runtime classpath will be tested by running the app when doing the integration tests. To actually have better classpaths within Eclipse, I guess the solution would be to be closer to the OSGi model. First the project should be split between the main Java and the tests. For instance the test classes will never be in the deployed classpath, so they shouldn’t appear in the runtime classpath of the application. So the tests and the main Java should be in different projects. Just like OSGi projects. A second step would be to make the Ivy container have two facets, one for compilation, and one for runtime. I just had a very quick look at the Eclipse API, and there seems to be something to do. There is already an « IvyDERuntimeClasspathEntryResolver ». Today it just blindly use the classpath defined, just correctly handle the projects dependencies which are kind of special in the Ivy use case. Maybe here it could do better and use another Ivy configuration for the runtime. This is just guesswork though. Nicolas > Le 12 déc. 2014 à 23:14, Hamlin, J.C. <j.c.ham...@sap.com> a écrit : > > In our ivy.xml we setup configurations that mirror the maven scopes: compile, > test, and runtime. We also setup three IvyDE classpath containers in each of > our Eclipse projects, one for each scope. Compile and test are not > transitive: if you directly depend on something you must add it to your > ivy.xml to indicate that it is a required direct dependency of your project. > The runtime IvyDE classpath container actually includes everything from > compile, test, and runtime and resolves all three configurations transitively > to bring in all required jars to enable a suitable runtime environment for > the tests of that project (which we run through the TestNG test runner). > > We have 100s of projects imported into the workspace, and each one is > configured this way, each with its own ivy.xml and using a shared > ivysettings.xml. > > Ideally, we'd like the runtime container to not be available during compile, > so people don't accidentally directly link to something that is supposed to > be a runtime-only dependency, and so that auto-complete doesn't litter your > dialogs with classes that you are not supposed to use directly. The runtime > container can be huge because of the transitive resolve, so it would be best > if it wasn't in the .classpath. So, that would mean only defining two > classpath containers: compile and test in the .classpath file. And that that > works great for compiling. However, that makes it so that when new launch > configurations are created (like right click and Run As... Java Application, > TestNG test, etc) those launch configurations, are by default, incorrect and > the run configuration fails. > > Now, we know that you can manually add an IvyDE classpath container to each > launch configuration. So, you would right click on a test, select Run As > TestNG, let it fail, edit the new and automatically created launch > configuration for it and add the new IvyDE container to the classpath for the > launch configuration. The problem is, manually configuring an IvyDE container > for every auto-created launch configuration is a pain. It takes about a > minute and about a hundred mouse clicks and keystrokes to use the GUI to > manually create the runtime container in each launch configuration. And if > you mess up and want to edit the IvyDE classpath container after it is > created, you cannot: the edit button is greyed out. So you have to delete it > and start over. Alternately, you can save the launch configuration to your > project, edit it by hand and copy over the already configured container from > another launch configuration, refresh Eclipse, and then it will work. This is > also a pain, and very difficult to train 100s of developers how to use. > > Is it possible to setup on a project-by-project basis a pre-configured > runtime classpath container using IvyDE that automatically get added to every > automatically created launch configuration for that project? Or, if not, is > there a better way of handling it? The maven classpath container that is in > the .classpath and the one that gets automatically added to launch > configurations seems smart: it resolves compile/test at compile time, and > comple/test/runtime at runtime, so it works as expected. Can IvyDE do this, > or can it be made to do it? > > I am interested to know how other folks on this email list using IvyDE handle > this problem. Do you do what we do, and just put the runtime jars into the > .classpath? Or do you have a better way of handling runtime dependencies for > launch configurations? > > -J.C. >
