I think it would be great to have a possibility to transform Maven model
right after it is read, even before execution plan is calculated (for
example in MavenImpl.readProject or
ProjectRegistryManager.readMavenProject before the call to
calculateExecutionPlans). Not only will this allow adding and updating
dependencies but also adding and updating plugin executions. Will you
accept a quality patch if someone creates it?
Regards,
htfv (Aliaksei Lahachou)
On Sun, Jun 17, 2012 at 1:20 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:
You are correct, there is one and only one ILifecycleMapping/2 per
project. ILifecycleMapping2 won't help if you expect to have multiple
AbstractMavenLifecycleParticip__ant'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>
<mailto: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>
<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> <mailto: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> <mailto: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>
<mailto: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>
<mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<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>
<mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<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>
<mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<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>
<mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<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
