Hi Andreas,
See Robert's change. This maybe helps
https://github.com/apache/maven-surefire/commit/9cb143414134a2c8f0bfec5b84f01571875a26fe
On Thu, Jan 7, 2016 at 9:54 PM, Andreas Gudian
wrote:
> Hey,
>
> funny, I ran into the very same problem when working on
Hi Stuart,
thanks for the explanation !
the map solution also have fit well in my case.
many thanks and best regards,
Cristiano
On 06-01-2016 19:50, Stuart McCulloch wrote:
Hi Cristiano,
Maven core doesn’t expose the “com.google.inject” package to plugins, which
means the Injector class
Excuses, forgot to add the link... :(
I have it working on Maven 3.3.9.
[1] https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color/
With regards,
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in
I think it doesn't work with recent log4j versions because of the missing
fix in
maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
org.apache.logging.slf4j.Log4jLoggerFactory
org.apache.maven.cli.logging.impl.Log4j2Configuration
Igor,
I just discover your thread "logging during multithreaded builds"
It's sad that it didn't move forward.
I understand that https://issues.apache.org/jira/browse/MNG-5836 was also
a limitation to provide the logging configuration from the extension.
On Thu, Jan 7, 2016 at 4:26 AM, Igor
What is [1] Nick ? My blog post ? It is probably outdated :(
On which version of Maven do you try to have it working ?
On Thu, Jan 7, 2016 at 10:17 AM, Nick Stolwijk
wrote:
> Arnaud,
>
> I have followed this blogpost[1] and to see debug information I have to
> adjust my
Github user atanasenko commented on the pull request:
https://github.com/apache/maven/pull/77#issuecomment-169636108
This change actually breaks MNG-5805 test since plexus can no longer call
setPhases with Lifecycle map. However, I think changing the functionality (and
test) to use
GitHub user atanasenko opened a pull request:
https://github.com/apache/maven-integration-testing/pull/13
[MNG-5958] restore binary compatibility of Lifecycle.setPhases
You can merge this pull request into a Git repository by running:
$ git pull
Github user michael-o commented on the pull request:
https://github.com/apache/maven-integration-testing/pull/13#issuecomment-169641948
Thank you. I will have a look and run it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
And the same for logback https://github.com/apache/maven/tree/slf4j-logback
(no jealous)
On Thu, Jan 7, 2016 at 11:35 AM, Arnaud Héritier
wrote:
> I think it doesn't work with recent log4j versions because of the missing
> fix in
>
>
What do you mean Nick ?
I think it was implemented. I have the -X flag which is working with DEBUG
details
On Thu, Jan 7, 2016 at 2:53 AM, Nick Stolwijk
wrote:
> This isn't a mail to convince anyone between Log4J2 or Logback.
>
> I have updated my Maven installation
Arnaud,
I have followed this blogpost[1] and to see debug information I have to
adjust my conf/logging/log4j2.xml instead of just add "-X" to the command
line. Also, if I leave the log4j2.xml on DEBUG level, I don't have to
specify the "-X" parameter to see debug. In my case the "-X" doesn't do
I am migrating plugin to 3.0.0 and I have a problem with a test
because it fails due to maven-plugin-testing-harness:3.0.0 cannot call a
method:
setClassPathScanning(Ljava/lang/String;)Lorg/codehaus/plexus/ContainerConfiguration;
In maven-plugin-testing-harness' code the method
Ha! I'm knee deep in trying to switch maven-release over to Maven 3 and
fighting the AbstractReleaseTestCase is proving too much for my allocated
morning of project time... to say this whole thing is a mess would be an
understatement ;-)
On 7 January 2016 at 12:40, Tibor Digana
That was exactly was I offered to do: new maven-ext-logback module part
of the source tree but not included in the default distribution [1] .
And the consensus was that having optional modules in the core did not
add enough (or any) value to the users, so we decided not to do it. If
other maven
No, I don’t that useful. If it’s an extensions then it can be activated using
the .mvn/extensions.xml and downloaded on demand. I think for Maven 4.x we just
bite the bullet and put Logback in the distribution. Igor and I have done most
of the work in the last while and have implementations for
JBoss has nice solutions with BOM file.
In Maven 4.0 migration we should not forget to provide several
dependencyManagements POM with version 4.0.0 of individual dependencies.
There I can see that e.g. IT testing has recommended set of artifacts with
certain versions.
On Thu, Jan 7, 2016 at 2:05
FWIW, Sisu tries to maintain compatibility across different versions where
possible - if you find that you can’t use a newer release in place of an older
one then you can always report this (http://www.eclipse.org/sisu/support/) with
the details and any test projects/logs. Also note that
And couldn't we have some optional extensions in the distribution ?
Not activated by default but that users can easily activate by moving a jar
?
On Thu, Jan 7, 2016 at 2:51 PM, Jason van Zyl wrote:
> And I liked this extension and wanted it! I only thought it inappropriate
>
You should really try Takari plugin testing harness. It's good, works
for all 3.x maven versions too.
--
Regards,
Igor
On Thu, Jan 7, 2016, at 08:04 AM, Stephen Connolly wrote:
> Ha! I'm knee deep in trying to switch maven-release over to Maven 3 and
> fighting the AbstractReleaseTestCase is
On Thu, Jan 7, 2016 at 9:56 AM, Jason van Zyl wrote:
>
> > On Jan 7, 2016, at 11:43 AM, Arnaud Héritier
> wrote:
> >
> > No problem.
> > Let's do what you want (like always).
>
> Not that I want it, but that’s certainly never been the case. The project
>
On Thu, Jan 7, 2016 at 7:26 AM, Jason van Zyl wrote:
> No, I don’t that useful. If it’s an extensions then it can be activated
> using the .mvn/extensions.xml and downloaded on demand. I think for Maven
> 4.x we just bite the bullet and put Logback in the distribution. Igor and
All this stats talk is irrelevant, McDonalds server millions of hamburgers,
that fact does not make it a 5-star restaurant. My peers do not drive
Lamborghinis but I'll buy one when I can afford it!
Gary
On Wed, Jan 6, 2016 at 2:09 PM, Jason van Zyl wrote:
>
> > On Jan 6, 2016,
No problem.
Let's do what you want (like always).
I agree we are loosing our time.
Have a good day.
On Thu, Jan 7, 2016 at 4:26 PM, Jason van Zyl wrote:
> No, I don’t that useful. If it’s an extensions then it can be activated
> using the .mvn/extensions.xml and downloaded on
Hello,
I'm facing a problem with a plugin that has a custom ArtifactHandler for
a custom packaging type. The custom class is being registered by sisu
and no problem was reported while running a build, except when a project
artifact has one artifact of this custom type as a dependency.
The
This is the branch 3.0-rc1 in surefire project
https://github.com/apache/maven-surefire/tree/3.0-rc1
The problematic project is maven-surefire-report-plugin.
https://github.com/apache/maven-surefire/blob/3.0-rc1/maven-surefire-report-plugin/pom.xml
As we can see
Hi Tibor,
so this is not how it should be done.
Compat contains classes which Maven2 classes which have been replaced by
Maven3 or are not used anymore.
Only plugins which need to stay compatible with Maven2 should include this
dependency.
I'll update the page, because we've decided to
Well, is not the dot the culprit...
I tried with another packaging name and I got the same result.
I still don't know who injects the ArtifactHandler in the dependency...
any idea ?
-
To unsubscribe, e-mail:
Hey,
funny, I ran into the very same problem when working on MCOMIPLER-203 and
after updating to Maven 3.0 dependencies: I'm getting the very same
exception when running the CompilerMojoTestCase.
I'm all ears on how to solve that, so if anyone has a hint... :)
I pushed a branch on github, and,
He claims that Log4j 2 isn’t popular enough. The real reason, as you probably
know, is that Jason seriously dislikes me, although he would never actually say
that as his reason.
Ralph
> On Jan 7, 2016, at 10:56 AM, Jason van Zyl wrote:
>
>
>> On Jan 7, 2016, at 11:43 AM,
Am 2016-01-06 um 22:05 schrieb Tibor Digana:
Hi,
We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333879
There are still a couple of issues left in JIRA:
Hi Tibor,
Bullet 4: Remove maven-compat (or give it the test-scope if it is required
by the maven-plugin-testing-harness)
Now I think you're at a state where Maven2 classes must be replaced with
Maven3 solutions.
Robert
Op Thu, 07 Jan 2016 18:54:06 +0100 schreef Tibor Digana
Now I removed maven-compat completely.
org.apache.maven.shared
maven-artifact-transfer
3.0-SNAPSHOT
It seems release version is not available.
I should resolve compilation error after new 3.0 AtrifactResolver and
I will come back to you.
return artifactResolver.resolveTransitively(
`+1
On Wed, Jan 6, 2016 at 10:05 PM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5858080...@n5.nabble.com> wrote:
> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333879
>
> There are still a couple of issues left in JIRA:
>
>
+1 non-binding, tested with Java 8 and Maven 3.3.9 on a smallish
project that was previously using shade 2.4.1.
Thanks.
On Thu, Jan 7, 2016 at 12:59 PM, Tibor Digana wrote:
> `+1
>
> On Wed, Jan 6, 2016 at 10:05 PM, Tibor Digana-2 [via Maven] <
>
I apologize for this email. It was not meant for this list.
Ralph
> On Jan 7, 2016, at 11:47 AM, Ralph Goers wrote:
>
> He claims that Log4j 2 isn’t popular enough. The real reason, as you
> probably know, is that Jason seriously dislikes me, although he would
Github user atanasenko commented on the pull request:
https://github.com/apache/maven-integration-testing/pull/13#issuecomment-169820952
btw, I'm also seeing a failure in test for MNG-4919, which seems to be
caused by MNG-5359
---
If your project is set up for it, you can reply to
Thx Andreas.
It seems all todo 3.0 plugins are quietly in progress. If we are going to
struggle with the same issue, we should use this thread and post solutions.
LGTM
On Thu, Jan 7, 2016 at 9:54 PM, Andreas Gudian [via Maven] <
ml-node+s40175n5858345...@n5.nabble.com> wrote:
> Hey,
>
> funny, I
After having lost many hours I finally found where the problem is likely
to be... :-(
maven is using aether for dependency resolution, but aether has not a
concept of packaging and extension as maven has. it only has extension.
as a workaround maven is saving the packaging type inside the
39 matches
Mail list logo