Agree. 1.7 makes more sense at this point.
On September 27, 2014 1:41:31 PM EDT, Michael Osipov <1983-01...@gmx.net> wrote:
>
>> We moved core to 1.6 some time ago. Time to move everything else as
>well ?
>>
>> Kristian (Who's ready to say "1.7" but we stop by 1.6 first :)
>
>
>I would favor the
e/display/MAVEN/DependencyResolutionException
Thanks again,
Mark Nelson | Architect | 61.2.9491.1177 Platform Engineering Oracle
Development http://redstack.wordpress.com/
"Oracle BPM Suite 11g: Advanced BPMN Topics"
by Mark Nelson and Tanya Williams
http://bit.ly/UbNKLD
On 9/25/2014 12:34 PM,
Aether.
On Sep 24, 2014, at 9:11 PM, Mark Nelson
wrote:
I tired 3.2.1 and 3.2.3.
Mark Nelson | Architect | 61.2.9491.1177
Platform Engineering
Oracle Development
http://redstack.wordpress.com/
"Oracle BPM Suite 11g: Advanced BPMN Topics"
by Mark Nelson and Tanya Williams
http://bi
rg.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
>org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
>org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>
>
>
>Mark Nelson | Architect
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
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
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:
com.google.code.findbugs
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,
Igo
duled for
jdk9. Such a feature 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 :
We can move to the newer ve
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 2014-09
gs as well.
thanks,
Robert
[1] https://jira.codehaus.org/browse/MNG-5562
Op Thu, 28 Aug 2014 05:17:55 +0200 schreef :
aether 1.0
Signed-off-by: Igor Fedorenko
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/2909b5a3
Tree:
7b9
MNG-5670 guard against ConcurrentModificationException iterating over
System properties
Signed-off-by: Igor Fedorenko
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://git-wip-us.apache.org/repos/asf/ma
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 depe
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 w
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é
L
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] http://jira.codehau
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 o
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=117
Jason van Zyl wrote:
+1
On Jul 8, 2014, at 7:58 AM, Igor Fedorenko wrote:
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11740&version=20039
There are no issues left in JIRA
Staging repo:
https://repository.apache.org/content/repositories/maven-1
#x27;s 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 Derricu
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, 0:
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11740&version=20039
There are no issues left in JIRA
Staging repo:
https://repository.apache.org/content/repositories/maven-1039/
http://repository.apache.org/content/repositories/maven-1039/org/apache/maven/plug
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
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 an
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 t
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 peopl
oss
of configuration, why does the format need major version bump?
--
Regards,
Igor
On Friday, 20 June 2014, Igor Fedorenko 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, al
tures 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 wrote:
I am not sure I follow.
Do you want to allow multi-m
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 versio
lan.conno...@gmail.com> wrote:
On 19 June 2014 15:48, Igor Fedorenko 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 pom we should
actually de
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 pom we should
actually deploy the build time pom to the repository... probably with the
classifier `build`...
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 it
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
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: dev-h...@maven.ap
22:43:04 +0200 schreef Igor Fedorenko
:
Consider the following parent pom.xml snippet
foo
bar
1
munchy
...
...
then in the child I believe you can do
foo
bar
1
ne, unless we say: just manage this by ordering your plugins.
Keep 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
:
Mis
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 tried
utions 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
:
Misconfigured execution order should be reported as build failer.
I don't see how profiles make th
Thanks,
Robert
Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko
:
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, but I believe it is always possible to add
depends
lease 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
+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
interested
e developer had control over all the 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
wrote:
Mojo executions bound to in packaging type lifecycl
am 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 w
an 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
wrote:
Yes, I was also thinking before/after as a way to solve this. We
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 wrote:
Yes, I was also thinking before/after as a way to solve this. We can
probably
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.
But
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 exec
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 q
while Gerrit still keeps
all 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...
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 rep
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
oint in the
lifecycle?
William
On Wed, May 21, 2014 at 11:20 AM, Igor Fedorenko
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 re
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 fr
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 wrote:
MavenLifecycleParticipant comes from a build extension, so build
extensions are loaded for sure.
Most likely the problem has
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
extensi
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, utilizing
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 to
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 Fedorenk
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 be confusing)?
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 true
in pom.xml, because regular plugins are
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 af
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 for
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 Ma
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
.java:96)
at org.apache.xbean.recipe.RecipeHelper.convert(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 wrote:
You need to add maven-compat as a dependency.
--
Regards,
Igor
On 2/22/
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
wrote:
Plexus-container-default 1.5.5 changes som
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 3.
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
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
:
Hi,
The vot
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
+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=10500&version=20041
Staging repo:
https://repository.apache.org/conten
quot; then?
Leaking "ee" stuff from 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 :
Please keep @Typed annotation available outside of core.
I use @Typed annotation in one of my
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 wrote:
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
---
--
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 wrote:
I lean towards keeping the current implementation as-is. Jococo maven
plugin relies on a bug in
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
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
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 wrote:
I suspect this is related to the change in Classworlds 2.4.1+ to use the
new ClassLoader.close() method avail
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 wrote:
This is kinda tricky. We have three cases to consider
1. Plugin depends on main artifact only. For such dependency both 3.1.1
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 an
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=11740&version=20031
There are still a couple of issues left in JIRA:
https://jira.codehaus.org/br
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=10500&version=15565
Staging repo:
https://repository.apach
that seems ludicrous.
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
g 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 wrote:
I successfully used junit4 parametrized tests with Invoker to run plugin
ITs again
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 t
17:10:55 Robert 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 F
apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/annotations/JavaAnnotationsMojoDescriptorExtractor.java?r1=1341650&r2=1343086&pathrev=1343086&diff_format=h
Le samedi 8 février 2014 11:00:48 Igor Fedorenko a écrit :
On
ponent
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 Fedorenko
:
On 2/8/2014, 9:56, Hervé BOUTEMY wrote:
ok, here the confusion is that there are 2 @C
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 inje
ven.apache.org/ref/3-LATEST/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 bett
Hi,
We solved 2 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11740&version=20031
There are still a couple of issues left in JIRA:
https://jira.codehaus.org/browse/MPLUGINTESTING-20?jql=project%20%3D%20MPLUGINTESTING%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20prio
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
Re
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
de
understanding of the Maven
core. But as I said before 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 wro
ck to it in a couple of months.
William
On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko 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.
LifeCyclePar
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
http://jira.codehaus.
201 - 300 of 454 matches
Mail list logo