You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
If you have Maven project that depends on other projects within the workspace (some in
compile
scope and others intest
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 aretest
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 theclasses
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:Assuming this is how workspace dependencies are used, all these projects would typically be in a directory called
${project_loc}/target/classes
, sogetName()
would returnclasses
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.The text was updated successfully, but these errors were encountered: