://bit.ly/UbNKLD
On 9/25/2014 11:09 AM, Igor Fedorenko wrote:
What maven version do you use?
On September 24, 2014 9:00:00 PM EDT, Mark Nelson
mark.x.nel...@oracle.com wrote:
Hi Igor,
I am trying to use this okhttp-based wagon, but it is giving me
an odd error that I have not seen before.
I tried
There is yet another http connector implementation [1] (the more the
merrier, right? :-) ). It is based on square okhttp client and is pretty
simple. I didn't try redirects, but auth credentials are not scoped to a
specific url, so there is a chance this connector may work.
This is the connector
11g: Advanced BPMN Topics
by Mark Nelson and Tanya Williams
http://bit.ly/UbNKLD
On 9/25/2014 7:54 AM, Igor Fedorenko wrote:
There is yet another http connector implementation [1] (the more the
merrier, right? :-) ). It is based on square okhttp client and is
pretty
simple. I didn't try
/25/2014 11:09 AM, Igor Fedorenko wrote:
What maven version do you use?
On September 24, 2014 9:00:00 PM EDT, Mark Nelson
mark.x.nel...@oracle.com wrote:
Hi Igor,
I am trying to use this okhttp-based wagon, but it is giving me an
odd
error that I have not seen before.
I tried different versions
I haven't checked version 3.0.0, but version 1.3.9 used to have sources
with GPL headers and was rejected by Eclipse IP team. Probably worth to
double-check this has been cleaned up.
--
Regards,
Igor
On 2014-09-22, 12:14, Kristian Rosenvold wrote:
dependency
You need to use org.apache.maven.plugins.annotations.Component
annotation inside maven plugins, I don't believe plexus @Requirement
works.
--
Regards,
Igor
On 2014-09-22, 18:34, animator wrote:
The main problem from the topic finally I managed to resolve. The problem was
wrong configuration in
On 2014-09-21, 12:14, Hervé BOUTEMY wrote:
hte attribute without property seems to be expected to be a Plexus
component, but you didn't declare it:
Is this specific to reporting plugins? I believe regular plugins
can have @Parameter's without properties and/or default values.
--
Regards,
Igor
We can move to the newer version of guava. This was one of the reasons I
updated to the latest sisu, I was told it did not depend on any internal
guava apis any more. Of course, somebody will have to check what guava
version is compatible with JDK 9 before we upgrade.
--
Regards,
Igor
On
would make a lot of people happy :) I'm sure the
guava devs will incorporate such a replacement if it shows up, but to
my understanding this is guavas problem not ours (a SEP).
Kristian
2014-09-15 13:24 GMT+02:00 Igor Fedorenko i...@ifedorenko.com:
We can move to the newer version of guava
.
thanks,
Robert
[1] https://jira.codehaus.org/browse/MNG-5562
Op Thu, 28 Aug 2014 05:17:55 +0200 schreef ifedore...@apache.org:
aether 1.0
Signed-off-by: Igor Fedorenko ifedore...@apache.org
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos
e3000a09c - 8980f67b9
MNG-5670 guard against ConcurrentModificationException iterating over
System properties
Signed-off-by: Igor Fedorenko ifedore...@apache.org
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/8980f67b
Tree: http
You need to use plugin testing 2.1 with maven 3.0.x.
I don't know what version of Guava was included in maven 3.0.x, but your
plugin will need to use compatible version to be able to use plugin
testing. unit tests currently have one flat classpath, so can't have
multiple versions of the same
I am trying to assess potential impact of a performance regression on
the current master. I believe the problem has to do with inconsistent
caching of ModelData instances and is similar/related to MNG-5312 [1]
that was fixed back in 2012. Unfortunately, MNG-5312 didn't have any
test case so I am
Public
The harness https://github.com/takari/maven-performance-tests
The results http://ci.takari.io:8080/job/maven-performance-tests_master/
--
Regards,
Igor
On 2014-07-21, 11:53, Hervé BOUTEMY wrote:
Great.
Is this perf harness private or public?
Are the results public?
Regards,
Hervé
I debugged it some time ago and I think there is a bug with default
values of List parameters. I didn't have time to fix it though.
--
Regards,
Igor
On 2014-07-16, 17:10, Karl Heinz Marbaise wrote:
Hi,
currently i found an issue which i want to know if it's a know issue or
a misunderstanding
MNG-5663 [1] looks like the same problem and there is a (somewhat large
and convoluted) example. The problem seems to be triggered by use of
inherited ${property} to define import scoped dependency version, but I
could not easily setup a standalone project to trigger this.
[1]
Distribution Area.
Also, I am still hopelessly lost in site publishing, so I'd appreciate
if somebody double-checked I haven't missed anything.
--
Regards,
Igor
On 2014-07-08, 15:58, Igor Fedorenko wrote:
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11740version
van Zyl wrote:
+1
On Jul 8, 2014, at 7:58 AM, Igor Fedorenko i...@ifedorenko.com wrote:
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11740version=20039
There are no issues left in JIRA
Staging repo:
https://repository.apache.org/content/repositories
not midnight:
If I'm correct, following have joined at least 2 times or are Maven PMC
22:00-23:00 (CEST) Robert Scholte, Hervé Boutemy, Karl-Heinz Marbaise,
Mark Struberg
21:00-22:00 (IST) Stephen Connolly
unknown, please complete
Jason van Zyl
Igor Fedorenko
Manfred Moser
Mark Derricutt
Emily Blades
I am trying to stage maven plugin test 3.2.0 but Nexus does not let me
close the staging repository because of gpg signature validation
failure. Looks like nexus is configured to check three key servers,
http://gpg-keyserver.de/, http://pool.sks-keyservers.net:11371 and
http://pgp.mit.edu:11371
Never mind, nexus was just tired, it worked the second time I attempted
to close the repo.
--
Regards,
Igor
On 2014-07-08, 15:01, Igor Fedorenko wrote:
I am trying to stage maven plugin test 3.2.0 but Nexus does not let me
close the staging repository because of gpg signature validation
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11740version=20039
There are no issues left in JIRA
Staging repo:
https://repository.apache.org/content/repositories/maven-1039/
I am not sure I understand your concern about Maven versions. The test
harness itself can be built with pretty much any version of Maven and I
expect any 3.x to work, but the plugins that use plugin testing 3.2.0
will have to use depend on Maven 3.2.1 or newer.
--
Regards,
Igor
On 2014-07-09,
On 2014-07-07, 1:56, Mark Derricutt wrote:
That would in part align things with Aether's somewhat annoying/retarded
behaviour of saying oh I see com.acme:special tool:1.0-alpha-1 but it
came from repo-1, not repo-2 - so suck it up - I can't resolve this..
I can understand the idea behind this
SessionScope and MojoExecutionScope introduced in maven 3.2.1 require
explicit support from maven-plugin-testing-harness. Unfortunately, there
is no clean/straightforward way to introduce such support and still be
able to use maven-plugin-testing-harness with earlier versions of maven.
What
Components decide how often then are instantiated, so AssemblyArchiver
implementation(s) need to be changed.
You can use instantiationStrategy=per-lookup to indicate new instance
is created each time component is injected. This is standard plexus/sisu
feature and should work on all Maven
continue to work as-is. We increase major
part when we remove supported elements or change meaning of existing
elements.
--
Regards,
Igor
On 2014-06-19, 20:22, Stephen Connolly wrote:
On Friday, 20 June 2014, Igor Fedorenko i...@ifedorenko.com wrote:
I am not sure I follow.
Do you want
of configuration, why does the format need major version bump?
--
Regards,
Igor
On Friday, 20 June 2014, Igor Fedorenko i...@ifedorenko.com wrote:
I think ad-hoc aggregators are an interesting use case and I need to
think about it some more before I decide how I'd like to support it.
Anyways, all
On 2014-06-19, 10:30, Stephen Connolly wrote:
- Igor is*mostly* right in that we should not deploy the pom that is used
to build to the repository...
- Where Igor is wrong is that for packagingpom/packaging we should
actually deploy the build time pom to the repository... probably with the
wrote:
On 19 June 2014 15:48, Igor Fedorenko i...@ifedorenko.com wrote:
On 2014-06-19, 10:30, Stephen Connolly wrote:
- Igor is*mostly* right in that we should not deploy the pom that is
used
to build to the repository...
- Where Igor is wrong is that for packagingpom/packaging we should
FWIW, m2e is happy with the staged 3.2.2 and so is one of the bigger
projects I deal with at $DAY_WORK.
Noticed a couple of small-ish problems
release notes are missing MNG-2199 [1], which I believe was merged to
master and is part of staged 3.2.2.
the release binary includes license files for
I got 503 page several times during the day and evening yesterday.
--
Regards,
Igor
On 2014-06-18, 9:13, Jason van Zyl wrote:
Two times during the one hour window that I was trying to release that the
service was not available. It was an Apache page but I assume Nexus wasn't
running behind
What does @requiresSession do (or did)?
--
Regards,
Igor
On 2014-06-13, 21:39, Benson Margulies wrote:
Is there one?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail:
and/or after these inherited
executions?
Thanks,
Robert
Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
i...@ifedorenko.com:
Misconfigured execution order should be reported as build failer.
I don't see how profiles make this problem more complicated. It maybe
little tedious to configure
I haven't used testing harness 1.3 for many years now, but in case you
want to see how nice version 3.1 is, I just pushed sample maven plugin
to github
https://github.com/ifedorenko/com.ifedorenko.sample-maven-plugin
--
Regards,
Igor
On 2014-06-12, 15:01, Benson Margulies wrote:
So, I
in mind: what to do if executions are defined in the parent and you
want to execute your plugin before and/or after these inherited
executions?
Thanks,
Robert
Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
i...@ifedorenko.com:
Misconfigured execution order should be reported as build
+0200 schreef Igor Fedorenko
i...@ifedorenko.com:
Consider the following parent pom.xml snippet
plugin
groupIdfoo/groupId
artifactIdbar/artifactId
version1/version
executions
execution
idmunchy/id
phase.../phase
goalsgoal.../goal
+1 for hangouts. As much as I'd love to see the city and finally have a
drink with Tamas, I almost certainly won't be able to come to Budapest.
I am not sure I will be able to attend weekly hangouts (or bi-weekly or
any scheduled, really) but if somebody works on a specific feature I am
profile will need to define execution with id of the final
step and add dependsOf=id-of-sign-step.
--
Regards,
Igor
On 2014-06-11, 15:17, Jörg Schaible wrote:
Hi Igor,
Igor Fedorenko wrote:
More I think about it, less I like the idea of explicit order values. I
think this will be rather
in your example,
the release profile will need to define execution with id of the final
step and add dependsOf=id-of-sign-step.
--
Regards,
Igor
On 2014-06-11, 15:17, Jörg Schaible wrote:
Hi Igor,
Igor Fedorenko wrote:
More I think about it, less I like the idea of explicit order values. I
think
, the developer had control over all the id executions and
explicitly ordered them. This won't be the case all the time. What happens
when you mix ordering and unspecified?
Cheers,
Paul
On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko i...@ifedorenko.com
wrote:
Mojo executions bound
not not a fan of the step-# naming because it's a prefix but
it is more descriptive; I would prefer to just simply allow the developer
to suffix with a -# (dash number). Thoughts on which nomenclature is better?
Cheers,
Paul
On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com
I haven't looked at the patch, but I know at least one case when it'd be
nice to have explicit control over execution order within a build phase.
Lets say you have two plugins, plugin-a with two goals a1 and a2, and
plugin-b with goal b1. It is currently not possible to express the
following
Yes, I was also thinking before/after as a way to solve this. We can
probably use xml attributes without breaking compat with artifact
consumers, so I think this can be done in Maven 3.x.
--
Regards,
Igor
On 2014-06-04, 10:09, Robert Scholte wrote:
Hi Paul,
that's my understanding as well.
run things pre/post goal. I am
pretty sure Jason wanted to get rid of that perspective with this 2.x
design, but maybe things are coming full circle?
Cheers,
Paul
On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote:
Yes, I was also thinking before/after as a way to solve
run things pre/post goal. I am
pretty sure Jason wanted to get rid of that perspective with this 2.x
design, but maybe things are coming full circle?
Cheers,
Paul
On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com
wrote:
Yes, I was also thinking before/after as a way
Can you explain your usecase in more details? In particular, how this
class folder is consumed during build time and at runtime. I am trying
to understand why packaging a class folder is huge overhead.
--
Regards,
Igor
On 2014-05-29, 3:39, Petar Tahchiev wrote:
Hi guys,
here's an interesting
LifeCycleParticipant#afterProjectsRead is called after projects pom.xml
are read and MavenProject instances created but *before* actual build
starts. It is called for entire session and not any reactor project in
particular.
--
Regards,
Igor
On 2014-05-23, 21:03, William Ferguson wrote:
Thanks
Please don't use Github PL merge functionality. This will create merge
commits... and I seriously dislike merge commits, hate them, actually.
--
Regards,
Igor
On 2014-05-24, 12:39, Jason van Zyl wrote:
The mechanics of processing PRs from repos we have access to is all
good. But the Apache
the discussion history if anyone wants to see how the end result
came to be.
--
Regards,
Igor
On 2014-05-24, 13:06, Michael Osipov wrote:
Am 2014-05-24 18:57, schrieb Igor Fedorenko:
Please don't use Github PL merge functionality. This will create merge
commits... and I seriously dislike merge
?
William
On Wed, May 21, 2014 at 11:20 AM, Igor Fedorenko i...@ifedorenko.com
wrote:
MavenLifecycleParticipant comes from a build extension, so build
extensions are loaded for sure.
Most likely the problem has to do with thread context classloader, you
need to set it to project extensions realm
be aware of from setting the
Thread#contextClassloader to MaveProject#classReam at that point in the
lifecycle?
William
On Wed, May 21, 2014 at 11:20 AM, Igor Fedorenko i...@ifedorenko.comwrote:
MavenLifecycleParticipant comes from a build extension, so build
extensions are loaded for sure.
Most
on this precise method: there is a TODO in the
interface about this, and when you read DefaultMaven, you see the reason why
this method can't have extensions = too early = the TODO comment
Regards,
Hervé
Le mardi 20 mai 2014 21:20:36 Igor Fedorenko a écrit :
MavenLifecycleParticipant comes from a build
MavenLifecycleParticipant comes from a build extension, so build
extensions are loaded for sure.
Most likely the problem has to do with thread context classloader, you
need to set it to project extensions realm (as returned by
MavenProject.getClassRealm) to be able to lookup project build
You are probably missing maven-compat from your plugin dependencies. I
usually add this with scope=test unless my code explicitly depends on
classes from that artifact.
--
Regards,
Igor
On 2014-05-06, 9:33, Jochen Wiedmann wrote:
Hi,
I am trying to implement a test case for a plugin,
If all compiler delegates have the same groupId/artifactId but different
versions, then you can use standard maven plugin dependency resolution
to achieve something very similar. Specify the default delegate
groupId/artifactId/version as direct plugin dependency, but the user
will still be able
Maven does not provide generic way to skip mojo executions. This needs
to be explicitly implemented in my-maven-plugin.
--
Regards,
Igor
On 2014-04-22, 12:13, DK wrote:
If I add the following to my Maven plugin configuration it still executes the
plugin goal.
Is there something I need to do in
, I indeed never
see it as a sustainable place for my artifacts, only deploy is (and still
temporary for non releases).
Yes, I think we should rename that tag.
And if not we should stop telling people it must not be seen as a
repository, but as a cache...
Le 15 avr. 2014 11:32, Igor Fedorenko i
localRepository currently works as both a cache or artifacts from
remote repositories and as a repository of locally installed artifacts.
Do you suggest we get rid of locally installed functionality (which I
personally very much in favour) or you want to just change the name
(which I think will
We've introduced AbstractMavenLifecycleParticipant#afterSessionEnd for
this very purpose in 3.2.1, it is called after all projects are built
and gives build extensions the chance to do any necessary cleanup. You
will have to require your plugin to have extensionstrue/extensions
in pom.xml,
The scope of plexus-build-api is strictly limited to eclipse
integration. As such, it does not provide enough fidelity to implement
proper command line incremental build. In fact, even inside eclipse
plexus-build-api does not correctly handle stale output cleanup, so we
have to do Project/Clean
Out of curiosity, how do you plan to deal with multiple development
streams with different latest version depending on the stream? If, for
example, somebody decided to release maven 3.0.6, it'd need to be
compared to 3.0.5, not 3.2.1.
--
Regards,
Igor
On 2014-03-12, 8:30, Simone Tripodi wrote:
If you are an Eclipse user, you may want to try my Maven Development
Tools [1], which lets you debug through mojo and maven core code right
from m2e workspace.
There is no MavenProject#getProjectBuilderConfiguration in any version
of Maven I checked (3.2.1, 3.1.2, 2.0.9), check current master
No, not possible. MavenProject instances are read at the very beginning
of the build and do not change during the build.
--
Regards,
Igor
On 2014-02-26, 15:10, DK wrote:
I'm looking for a way to refresh/reload the parent and child poms from within
my Mojo i.e.
@Component
protected
You need to add maven-compat as a dependency.
--
Regards,
Igor
On 2/22/2014, 12:27, Benson Margulies wrote:
Further down the message, this boils down to a failure to find an
ArtifactResolver.
On Sat, Feb 22, 2014 at 12:04 PM, Benson Margulies
bimargul...@gmail.com wrote:
(RecipeHelper.java:167)
at org.apache.xbean.recipe.ObjectRecipe.setProperty(ObjectRecipe.java:466)
... 43 more
On Sat, Feb 22, 2014 at 12:29 PM, Igor Fedorenko i...@ifedorenko.com wrote:
You need to add maven-compat as a dependency.
--
Regards,
Igor
On 2/22/2014, 12:27, Benson Margulies wrote
I think this message comes from a Nexus server, and the plugin refers
to Nexus plugin running on the server. Almost looks like a broken Nexus
installation, but it's been some time since I last looked at Nexus.
--
Regards,
Igor
On 2/22/2014, 19:08, Martin Gainty wrote:
I *think* the sonatype
I think this is reasonable.
One observation. Maven does not have an API, plugins and projects can
access pretty much anything from the core. Add to this three distinct
user communities -- (end) users, plugin developers and embedders -- and
I think pretty much any change will break somebody. This
Maven Core is in git and has been for quite some time now... or you mean
some other Mave Core?
https://git-wip-us.apache.org/repos/asf?p=maven.git
--
Regards,
Igor
On 2/20/2014, 16:12, Paul Benedict wrote:
Would it be a good test to first try migrating individual plugin projects
to GIT before
Jason, Stephen, other PMC members,
I can't really know if there is behind-the-scenes pmc-only discussion
going on, but is there any chance to get 3.2.1 released this week?
I need to do legal/IP paperwork for upcoming m2e 1.5 release by
this coming Friday, and I would really like to list Maven
Eclipse development process distinguishes several build types [1], so I
am wondering if you really want to do weekly full releases or your
goal is to have something closer to integration builds in eclipse
nomenclature.
I see two major downsides doing weekly full releases.
First, one week just
The Apache Maven team is pleased to announce the release of the Apache
Maven Plugin Testing, version 3.1.0
The Maven Plugin Testing contains the necessary tools to be able
to test Maven Plugins.
http://maven.apache.org/plugin-testing/
You should specify the version in your project's dependency
Thank you, Robert.
I just sent release announcement, hopefully my email does
not bounce this time.
--
Regards,
Igor
On 2/15/2014, 5:17, Robert Scholte wrote:
Done,
I'll update the board report as well.
Robert
Op Wed, 12 Feb 2014 16:34:26 +0100 schreef Igor Fedorenko
ifedore...@apache.org
+1 all m2e tests pass
--
Regards,
Igor
On 2/14/2014, 12:58, Jason van Zyl wrote:
Hi,
Time to release Maven 3.2.1!
Here is a link to Jira with 33 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=20041
Staging repo:
Please keep @Typed annotation available outside of core.
I use @Typed annotation in one of my (private) core extensions where I
need a class to implement an interface but not make that interface
visible for injection in other components.
--
Regards,
Igor
On 2/13/2014, 9:43, Jason van Zyl
core does not seem like nice thing.
Kristian (Who will only touch ee stuff with a pitchfork)
2014-02-13 18:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com:
Please keep @Typed annotation available outside of core.
I use @Typed annotation in one of my (private) core extensions where I
need
and the new correct code path will introduce unnecessary
support burden on Maven core developers and confusion to Maven API users.
http://xkcd.com/1172/
--
Regards,
Igor
On 2/11/2014, 17:40, Igor Fedorenko wrote:
This is kinda tricky. We have three cases to consider
1. Plugin depends on main
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Wed, Feb 12, 2014 at 3:05 PM, Igor Fedorenko i...@ifedorenko.com wrote:
I lean towards keeping the current implementation as-is. Jococo maven
plugin
Hi,
The vote has passed with the following result:
+1 (binding): Jason, Olivier, Benson, Hervé
+1 (non binding): Igor
I will promote the artifacts to the central repo.
Can somebody with the awesome PMC powers copy the source release to the
Apache Distribution Area?
--
Regards,
Igor
Can I get another PMC vote please?
--
Regards,
Igor
On 2/8/2014, 1:02, Igor Fedorenko wrote:
Hi,
We solved 2 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11740version=20031
There are still a couple of issues left in JIRA:
https://jira.codehaus.org/browse
This is kinda tricky. We have three cases to consider
1. Plugin depends on main artifact only. For such dependency both 3.1.1
and 3.2.0 use G:A key, so there is no problem there
2. Plugin depends on main and classified artifacts of the same GA. In
this case 3.1.1 picked the last artifact
think it
makes issue tracking and voting easier than re-spinning the same version
number. What are your thoughts?
On Tue, Feb 11, 2014 at 4:40 PM, Igor Fedorenko i...@ifedorenko.com wrote:
This is kinda tricky. We have three cases to consider
1. Plugin depends on main artifact only
http://download.java.net/jdk8/docs/api/java/net/URLClassLoader.html
--
Regards,
Igor
On 2/11/2014, 18:38, Laird Nelson wrote:
On Tue, Feb 11, 2014 at 3:20 PM, Stuart McCulloch mccu...@gmail.com wrote:
I suspect this is related to the change in Classworlds 2.4.1+ to use the
new
No, Maven will (correctly) close URLClassLoaders on java7 and will
continue to work as before on older JVMs. Here is the code that
implements this logic
https://github.com/sonatype/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/ClassWorld.java#L110
--
Regards,
Igor
All important m2e tests pass, +1.
--
Regards,
Igor
On 2/10/2014, 21:18, Jason van Zyl wrote:
Hi,
Time to release Maven 3.2.0!
Here is a link to Jira with 33 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=15565
Staging repo:
I successfully used junit4 parametrized tests with Invoker to run plugin
ITs against multiple versions of Maven. Didn't really need to do
anything special, everything just worked. The only minor inconvenience
was, IIRC, I had to use system properties to tell Invoker maven home.
Should be trivial
the version of a
maven plugin used by an IT.
Don't mess with existing tests. It's always wrong to do it. You're
lazy and stupid if you do it.
On Sun, Feb 9, 2014 at 11:14 PM, Igor Fedorenko i...@ifedorenko.com wrote:
I successfully used junit4 parametrized tests with Invoker to run plugin
ITs against
.
On 10 Feb 2014, at 17:26, Igor Fedorenko wrote:
One of us must have misread the question :-)
I thought Mark asked if it was possible to run the same
clojure-maven-plugin IT with multiple versions of clojure compiler.
Assuming the point of the IT is to test clojure-maven-plugin, I don't
see
/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html
Le jeudi 6 février 2014 20:32:47 Igor Fedorenko a écrit :
Hervé,
Can you explain what confusion this causes?
--
Regards,
Igor
On 2/6/2014, 16:47, Hervé BOUTEMY wrote:
Hi,
You'd better not use the @Component
On 2/8/2014, 9:56, Hervé BOUTEMY wrote:
ok, here the confusion is that there are 2 @Component annotations:
org.apache.maven.plugins.annotations.Component = plugin-tools
and
org.codehaus.plexus.component.annotations.Component = Plexus on Guice
plugin-tools @Component annotation for objects
, the way MavenSession, MavenProject and MojoExecution are
injected isn't done by DI, but by the expression evaluator.
Robert
Op Sat, 08 Feb 2014 17:00:48 +0100 schreef Igor Fedorenko
i...@ifedorenko.com:
On 2/8/2014, 9:56, Hervé BOUTEMY wrote:
ok, here the confusion is that there are 2
/viewvc/maven/plugin-tools/trunk/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/annotations/JavaAnnotationsMojoDescriptorExtractor.java?r1=1341650r2=1343086pathrev=1343086diff_format=h
Le samedi 8 février 2014 11:00:48 Igor Fedorenko a écrit :
On 2/8/2014, 9:56, Hervé
Scholte a écrit :
If I'm correct, these are all the same:
CDI @Inject
Plexus' @Requirement
Plugin's @Component
However, the way MavenSession, MavenProject and MojoExecution are injected
isn't done by DI, but by the expression evaluator.
Robert
Op Sat, 08 Feb 2014 17:00:48 +0100 schreef Igor
Hi,
We solved 2 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11740version=20031
There are still a couple of issues left in JIRA:
Hervé,
Can you explain what confusion this causes?
--
Regards,
Igor
On 2/6/2014, 16:47, Hervé BOUTEMY wrote:
Hi,
You'd better not use the @Component annotation but @Parameter instead: this is
a feature that will be deprecated in future version:
http://jira.codehaus.org/browse/MPLUGIN-257
.
William
On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko i...@ifedorenko.com wrote:
On 2/4/2014, 1:06, William Ferguson wrote:
OK, I'm getting the dependencies to resolve and I can amend the classpath,
but I think I've hit a road block for multi module builds.
LifeCycleParticipant is only ever
if you think this is a worthwhile enterprise
then help me create an issue that spells out what you think needs doing and
I'll try to get back to it in a couple of months.
William
On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko i...@ifedorenko.comwrote:
On 2/4/2014, 1:06, William Ferguson wrote
I don't have all the answers, but I think it is relatively common to
have dependency on something available inside an archive deployed to a
repository and I am interested to figure out how to express such
dependencies in maven.
First, however, I need to apologize for my ignorance about Android
of the project.
If that doesn't work, I'll put together a cut down example.
Thanks.
William
On Thu, Jan 23, 2014 at 9:43 PM, Igor Fedorenko i...@ifedorenko.comwrote:
No, no tricks, as far as I know Plexus (and now Sisu/Guice) only inject
fully configured components. so the behaviour you describe
I'd like to release maven-plugin-test 3.1.0 to include couple of new
APIs I've introduced as per MPLUGINTESTING-36 and MPLUGINTESTING-37?
Does anyone have any outstanding work they want to push before I
initiate the process?
http://jira.codehaus.org/browse/MPLUGINTESTING-36
201 - 300 of 453 matches
Mail list logo
