If you have Maven project that depends on other projects within the workspace (some in compile scope and others in test scope), the scope doesn't appear in the dependencies list:
It seems impossible to include those projects that are compile scope dependencies while disabling those that are test dependencies.
If you try to untick manually all the classes entries (for the other projects within the workspace) and then only tick the ones required, all the classes entries are then ticked,even though they had been unticked explicitly. (This only shows after re-opening the configuration dialog.)
I'm not familiar with this code, but it seems this could be due to some identifier collision (for all the projects enabled via workspace resolution).
A quick look at net.sourceforge.eclipsejetty.util.Dependency seems to indicate that some of the ID is based on the last directory name only:
genericId = runtimeClasspathEntry.getPath().toFile().getName();
Assuming this is how workspace dependencies are used, all these projects would typically be in a directory called ${project_loc}/target/classes, so getName() would return classes for all of them.
If this genericId is then assumed to be a unique identifier to tick what's included and excluded from the classpath, this could create a naming collision problem, and cause the inability to separate them.
If you have Maven project that depends on other projects within the workspace (some in
compilescope and others intestscope), the scope doesn't appear in the dependencies list:It seems impossible to include those projects that are
compilescope dependencies while disabling those that aretestdependencies.If you try to untick manually all the
classesentries (for the other projects within the workspace) and then only tick the ones required, all theclassesentries are then ticked,even though they had been unticked explicitly. (This only shows after re-opening the configuration dialog.)I'm not familiar with this code, but it seems this could be due to some identifier collision (for all the projects enabled via workspace resolution).
A quick look at
net.sourceforge.eclipsejetty.util.Dependencyseems to indicate that some of the ID is based on the last directory name only:Assuming this is how workspace dependencies are used, all these projects would typically be in a directory called
${project_loc}/target/classes, sogetName()would returnclassesfor all of them.If this
genericIdis then assumed to be a unique identifier to tick what's included and excluded from the classpath, this could create a naming collision problem, and cause the inability to separate them.