[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] resolving implicit dependency in project configurator
|
You are correct, there is one and only one ILifecycleMapping/2 per
project. ILifecycleMapping2 won't help if you expect to have multiple
AbstractMavenLifecycleParticipant's. Looks like m2e needs some new APIs
to properly support this scenario.
Also, even though it is possible to embed the 'separate core jar' in an
eclipse plugin, there is no way to guarantee the embedded version will
match the version use by projects at cli (think different plugin
versions in pom.xml). For this reason it is always desirable to delegate
execution to the code coming from project extensions realm.
--
Regards,
Igor
On 12-06-17 6:20 AM, Aliaksei Lahachou wrote:
Hello Igor,
The "proper" implementation described by seems like what I need. But as
far as I understand, ILifecycleMapping/2 is intended to map a complete
lifecycle/packaging, not a single plugin. What happens if there is more
than one connector mapped to the same packaging? Will they be called in
order?
My plugin modifies the model and may add or updates dependencies. The
logic is already contained in a separate core jar, so it should be
possible to use it as is in an Eclipse plugin. I just cannot figure out
how to make m2e see these changes.
Regards,
htfv (Aliaksei Lahachou)
On Fri, Jun 1, 2012 at 4:56 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:
I have not looked at Fred's answer, but here is an alternative take ;-)
1. This is actually tricky. "Proper" implementation has to resolve
dependencies in the context of a project, which will take into account
project-specific repositories, dependencyManagement and other aspects of
maven dependency resolution logic. The easiest way to do this is to
inject <dependency> element into MavenProject model and let standard
m2e/maven dependency resolver do its thing. There is prototype support
for doing this from m2e extensions, but it is not used by any extension
I know of. If you are willing to risk it, have a look at
ILifecycleMapping2 and DefaultMavenDependencyResolver__. It should be
possible to subclass/wrap DefaultMavenDependencyResolver and
inject implicit dependencies before delegating to the default
implementation. As usual, if this does not work, I am willing to
consider quality patches.
2. As explain in [1], lifecycle mapping metadata provided by m2e
extensions takes preference over metadata provided by maven plugins. In
other words, m2e will use mapping metadata provided by your extension
and ignore the plugin's.
[1] http://wiki.eclipse.org/M2E___plugin_execution_not_covered
<http://wiki.eclipse.org/M2E_plugin_execution_not_covered>
--
Regards,
Igor
On 12-05-31 12:31 PM, Andrew Eisenberg wrote:
Some more, related questions.
1. It turns out that not only do I need to add a single dependency,
but I also need to add some transitive dependencies. What is the
recommended way to track down transitive dependencies
2. The plugin that I am writing the configurator for already has a
lifecycle-mapping-metadata.xml included. It has this action:
<action>
<execute>
<runOnIncremental>true</__runOnIncremental>
<runOnConfiguration>false</__runOnConfiguration>
</execute>
</action>
Now, the configurator needs to do more than just execute the plugin.
I first need to configure a few natures, add a few things to the
classpath, etc. And then I need to execute the plugin. What is the
recommended way of doing this?
thanks for your help.
Andrew
On Wed, May 30, 2012 at 3:16 PM, Andrew
Eisenberg<andrew@xxxxxxxxxxxx <mailto:andrew@xxxxxxxxxxxx>> wrote:
Yep. This works. Very nice.
On Wed, May 30, 2012 at 1:16 PM, Andrew
Eisenberg<andrew@xxxxxxxxxxxx <mailto:andrew@xxxxxxxxxxxx>>
wrote:
Thanks. I'll give this a try.
On Wed, May 30, 2012 at 12:25 PM, Igor
Fedorenko<igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:
IMaven#resolve can be used to resolve an artifact
from specified Maven
repositories. This call will download the artifact
if necessary. There
is currently no proper way to force re-resolution of
the artifact if
it's available in maven local repository, but you
may be able to use
ArtifactRepository.__setReleaseUpdatePolicy and/or
.setSnapshotUpdatePolicy.
--
Regards,
Igor
On 12-05-30 1:39 PM, Andrew Eisenberg wrote:
Hi all,
I am creating a project configurator for a maven
plugin and maven
extension. The extension (among other things)
adds an implicit
dependency to the project. I would like to
replicate this
functionality inside of the project
configurator. I know the
artifact, group, and version of the dependency.
My question is: how
to I resolve that to get a jar file in the local
repo? Furthermore,
if the artifact has not been downloaded yet, how
do I force it to be
so?
thanks,
_________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<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
<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
<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
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
