| Re: [m2e-dev] Classifiers and workspace resolution during maven launch |
I really wish Fred would comment here, but from my somewhat uneducated
point of view classified dependency resolution during java app/test
launch should be the same as when launching maven build. In both cases
classified dependencies should be resolved to a filesystem location (or
locations).
Here is what I would do
Introduce new extension point that takes workspace project and returns
artifactKey->location(s) map. The extensions will be registered for
specific packaging types. The default implementation will implement the
same logic as WorkspaceStateWriter.
The new extension will need to be defined in m2e.core because it will be
used in both in m2e.jdt and m2e.launch.
Deprecated existing IClassifierClasspathProvider extension point but
still support it.
If an artifact is resolved to multiple locations, as I understand is the
case for some wtp-specific cases, such artifact should not be written to
workspacestate.properties file. This is actually a missing feature in
Maven core, but to support it properly would need some major changes. I
don't think it's worth it, or at least this should be handled as a
separate enhancement request.
I don't mind moving workspacestate.properties generation to per-maven
launch. It will likely be little faster overall, but I don't think the
difference will be all that much. I believe content of all
workspacestate.properties files should be exactly the same for the same
workspace.
--
Regards,
Igor
On 2014-07-18, 11:23, László Váradi wrote:
Hi Igor,
<mailto:igor@xxxxxxxxxxxxxx>>: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
2014-07-17 15:04 GMT+02:00 Igor Fedorenko <igor@xxxxxxxxxxxxxx_________________________________________________
I am okay with this idea but I am not sure how the new proposed
extension point will align with existing classifierClasspathProviders.
@Fred what do you think?
--
Regards,
Igor
On 2014-07-17, 13:54, László Váradi wrote:
Hi Igor, hi all
I just wonder if m2e would support this (resolve "classified"
workspace
dependencies during maven launch) with a new extension point
definition.
An extension point may got IMavenProjectFacade, and would return
a list
of classifiers and locations, and WorkspaceStateWriter could use
this
list to generate the workspace state properties file. The special
"tests" classifier could be handled also by such a class.
In our case, the project has multiple jar plugin executions, with
different classifiers. The different executions just differs from
different include and exclude patterns.
So we could create our extension point to handle this configuration.
Maybe somebody could write an extension point for ejb plugin, which
would support the generateClient attribute, to setup the ejb-client
classifier for that project, etc...
If this is acceptable, then I would be happy to provide a patch.
Best regards,
-- Vazul
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>https://dev.eclipse.org/__mailman/listinfo/m2e-dev
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
_________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>https://dev.eclipse.org/__mailman/listinfo/m2e-dev
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
--
"Tőled tudják, hogy testvérek vagyunk?"
http://www.youtube.com/watch?feature=player_detailpage&v=qw1R794sutQ#t=2765s
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-dev