Hi Igor,
I just thinking about it again.
Yes, I agree, it would be a little bit confusing to have two extension points to something similar. But what if MavenRuntimeLaunchSupport generates a temporary properties file for the actual launch? It should use then the already existing extension point to gather the list of referenced workspace resolvable dependencies, and pass this file instead of the workspaceState.properties file. It would work only if the launch is about a workspace artifact, so it won't work (I think) for launches initiated from pom.xml files outside of a workspace project (I mean, pom.xml not related to a workspace project). And another problem is the resolving of plugins in workspace.
Another issue is that the classifierClasspathProvider extension point is defined in m2e.jdt plugin, not in m2e.core, which contains the WorkspaceStateWriter. And it is created with a different view in mind: to support the classpath generation from Maven Dependencies classpath container for a normal java class launch.
Maybe it would be better to solve this issue from another direction, and give an extension point to get the list of classifiers and output locations for a project, and use this information during java launch as well, because it can support maven launch at the same time. Or have both, and use this as fallback, if there is no classifierClasspathProvider.
My problem with the classifierClasspathProvider is that i have to create separate extension for different classifiers. In our case, when there are a few classifiers generated with jar plugin, it would be enough to have one extension which can analyze jar plugin executions, so if somebody defines a new execution with a new classifier, it could work without having to create a new eclipse plugin.
The advantage of classifierClaspathProvider is that it can register multiple locations for one classifier (as BlankClassifierClasspathProvider does).
So I think, both extensions are required...
However, if you see EjbClientClasspathProvider, the main logic can be used to generate entries into workspace state file. Or the same for WarClassesClassifierProvider. Both check some plugin configuration for the decision, but when a launch is about to execute and for a dependent project, and not at project import/update time.
My suggestion is just to put this logic somewhere where the workspace state properties file is generated, to support maven launch, too.
Best regards,
-- Vazul
