Re: Cannot build current master.

[Karl Heinz Marbaise]

Hi,

interesting, cause I couldn't reproduce the issue on my system ..only 
the build server shows an test failure...


I need to investigage the reason for that ...cause other tests from the 
same folder working...


Are you running on Linux / Mac / Windows ? Java Version?

Kind regards
Karl Heinz

On 11/10/16 01:27, Christian Schulte wrote:

Just updated current master and am getting test failures. Just my local
checkout?

$ env LC_ALL=C git branch
* master
  maven-3.x-next

$ env LC_ALL=C git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

testInvalidArtifactIdInPluginManagement(org.apache.maven.model.validation.DefaultModelValidatorTest)
Time elapsed: 0.04 sec  <<< FAILURE!
junit.framework.AssertionFailedError: missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml
at
org.apache.maven.model.validation.DefaultModelValidatorTest.read(DefaultModelValidatorTest.java:46)
at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:79)
at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:59)
at
org.apache.maven.model.validation.DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement(DefaultModelValidatorTest.java:647)

Failed tests:

DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement:647->validateRaw:59->validateRaw:79->read:46
missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml

[INFO] Maven Model Builder  FAILURE [
22.377 s]


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Cannot build current master.

[Christian Schulte]

Just updated current master and am getting test failures. Just my local
checkout?

$ env LC_ALL=C git branch
* master
  maven-3.x-next

$ env LC_ALL=C git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

testInvalidArtifactIdInPluginManagement(org.apache.maven.model.validation.DefaultModelValidatorTest)
Time elapsed: 0.04 sec  <<< FAILURE!
junit.framework.AssertionFailedError: missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml
at
org.apache.maven.model.validation.DefaultModelValidatorTest.read(DefaultModelValidatorTest.java:46)
at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:79)
at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:59)
at
org.apache.maven.model.validation.DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement(DefaultModelValidatorTest.java:647)

Failed tests:

DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement:647->validateRaw:59->validateRaw:79->read:46
missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml

[INFO] Maven Model Builder  FAILURE [
22.377 s]


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #127: [SUREFIRE-1293] Simplify org.apache.maven....

[Tibor17]

Github user Tibor17 commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/127#discussion_r82700832
  
--- Diff: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/TestSetRunListener.java
 ---
@@ -76,7 +76,7 @@ public TestSetRunListener( ConsoleReporter 
consoleReporter, FileReporter fileRep
StatisticsReporter statisticsReporter, 
boolean trimStackTrace,
boolean isPlainFormat, boolean 
briefOrPlainFormat )
 {
-this.consoleReporter = consoleReporter;
+this.consoleReporter = consoleReporter != null ? consoleReporter : 
new NullConsoleReporter();
--- End diff --

@britter 
>>does this belong into DefaultReporterFactory.createReporter()
If you mean this code:
`ConsoleReporter consoleReporter = shouldReportToConsole() ? new 
ConsoleReporter( consoleLogger ) : null;`

Then I would keep the responsibility of creating anew reporter yet in the 
method `createReporter()`. I am going to fix a bug exactly in this part of code 
after you. We can still improve the code by small incremental changes.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #127: [SUREFIRE-1293] Simplify org.apache.maven....

[Tibor17]

Github user Tibor17 commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/127#discussion_r82699845
  
--- Diff: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/TestSetRunListener.java
 ---
@@ -76,7 +76,7 @@ public TestSetRunListener( ConsoleReporter 
consoleReporter, FileReporter fileRep
StatisticsReporter statisticsReporter, 
boolean trimStackTrace,
boolean isPlainFormat, boolean 
briefOrPlainFormat )
 {
-this.consoleReporter = consoleReporter;
+this.consoleReporter = consoleReporter != null ? consoleReporter : 
new NullConsoleReporter();
--- End diff --

no no, I meant only the scope of this PR. Not whole Surefire of course.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #127: [SUREFIRE-1293] Simplify org.apache.maven....

[Tibor17]

Github user Tibor17 commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/127#discussion_r82699554
  
--- Diff: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/NullConsoleReporter.java
 ---
@@ -33,7 +33,10 @@
 class NullConsoleReporter
 extends ConsoleReporter
 {
-NullConsoleReporter() {
+
+static final NullConsoleReporter INSTANCE = new NullConsoleReporter();
+
+private NullConsoleReporter() {
--- End diff --

here as well
pls run the build. it explores checkstyle erros.
Did you get your IntelliJ Idea now working with our Maven checkstyle?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #127: [SUREFIRE-1293] Simplify org.apache.maven....

[Tibor17]

Github user Tibor17 commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/127#discussion_r82699403
  
--- Diff: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/NullConsoleOutputReceiver.java
 ---
@@ -31,7 +31,13 @@
 implements TestcycleConsoleOutputReceiver
 {
 
-public void testSetStarting( ReportEntry reportEntry )
+static final NullConsoleOutputReceiver INSTANCE = new 
NullConsoleOutputReceiver();
+
+private NullConsoleOutputReceiver()
+{
+}
+
+public void testSetStarting(ReportEntry reportEntry )
--- End diff --

here is checkstyle error


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Christian Schulte]

Am 10/10/16 um 20:49 schrieb Igor Fedorenko:
> Are repositories and other configuration defined in user settings.xml
> take precedence over global settings.xml?

Don't know for sure but would assume so. The current master 4.0.0 super
pom has already been reverted to not change in any way in 3.4.0. I think
that's how it will stay. I will just remove the 4.1.0 super pom and be
done with it.




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Mirko Friedenhagen]

But why would the server settings override the values of the user's
settings? I thought the latter ones always had precedence.

Regards
Mirko
-- 
Sent from my mobile

Am 10.10.2016 22:57 schrieb "Robert Scholte" :

> so this is the first change:
> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=1b00a9e1
> removing it from the POM (I assumed it was really in the Java code)
>
> Maybe this is a candidate to add to a new version of the settings.xml
> This file is a Maven-only file, which makes is easier to change (in
> contrast to the pom).
> That we be much cleaner compared to the profile-hack.
>
> Robert
>
> On Mon, 10 Oct 2016 20:54:41 +0200, Igor Fedorenko 
> wrote:
>
> Not just the url, but all aspect of "central" repository are
>> configurable in user settings.xml today. Even if we provide a better way
>> to express this configuration, I believe the old way should continue to
>> work for a few releases to allow graceful migration. Many users will use
>> multiple versions of maven side-by-side (think jenkins, for example).
>> And more generally, forcing settings.xml update is going to be a major
>> effort for larger organizations, with  100x or 1000x developers.
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[GitHub] maven-surefire issue #126: Make Junit4VersionsIT parameterized

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/126
  
@britter 
The only problem is with workspace for the `Junit4VersionsIT` which is 
`/target/Junit4VersionsIT_testJunit` same for all parameters. Therefore we 
should not take the only single parameter for `unpack( "/junit4" );`. There 
should be used a suffix as the second parameter which segregates the workspaces 
by parameterized runner.
You may fix it in a new PR. This would be helpful in order we want to 
download a zip of workspaces in Jenkins.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #126: Make Junit4VersionsIT parameterized

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/126
  
@britter 
Done.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #125: Consistently rename JUnit 4.x integration tests

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/125
  
@britter
It makes me a problem to merge this PR. Please open a new one with same 
changes.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Robert Scholte]

so this is the first change:
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=1b00a9e1
removing it from the POM (I assumed it was really in the Java code)

Maybe this is a candidate to add to a new version of the settings.xml
This file is a Maven-only file, which makes is easier to change (in  
contrast to the pom).

That we be much cleaner compared to the profile-hack.

Robert

On Mon, 10 Oct 2016 20:54:41 +0200, Igor Fedorenko   
wrote:



Not just the url, but all aspect of "central" repository are
configurable in user settings.xml today. Even if we provide a better way
to express this configuration, I believe the old way should continue to
work for a few releases to allow graceful migration. Many users will use
multiple versions of maven side-by-side (think jenkins, for example).
And more generally, forcing settings.xml update is going to be a major
effort for larger organizations, with  100x or 1000x developers.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Mirko Friedenhagen]

Hello everyone,

this is basically my settings.xml (stripped servers section and a few
sonarqube related properties):




central
*
Internal mirror of all needed dependencies
https://inhouse.server/artifactory/internal-central/




internal-central


https://inhouse.server/artifactory//libs-snapshot-local

https://inhouse.server/artifactory/libs-staging-local


central::default::${distribution.repo.staging}/

central::default::${distribution.repo.snapshot}/




central
Everything via internal-central

https://inhouse.server/artifactory/internal-central/
default

true


true
interval:60






central
Everything via internal-central

https://inhouse.server/artifactory/internal-central/
default

true


true
interval:60






internal-central



Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Mon, Oct 10, 2016 at 8:54 PM, Igor Fedorenko  wrote:
> Not just the url, but all aspect of "central" repository are
> configurable in user settings.xml today. Even if we provide a better way
> to express this configuration, I believe the old way should continue to
> work for a few releases to allow graceful migration. Many users will use
> multiple versions of maven side-by-side (think jenkins, for example).
> And more generally, forcing settings.xml update is going to be a major
> effort for larger organizations, with  100x or 1000x developers.
>
> --
> Regards,
> Igor
>
> On Mon, Oct 10, 2016, at 02:33 PM, Robert Scholte wrote:
>> On Mon, 10 Oct 2016 16:22:20 +0200, Christian Schulte 
>> wrote:
>>
>> > Am 10.10.2016 um 16:16 schrieb Christian Schulte:
>> >> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
>> >>> It is common to use repository with id=central in settings.xml to
>> >>> override central location. This functionality should continue to work,
>> >>> regardless how it is implemented in Maven internally.
>> >>>
>> >>
>> >> 
>> >>
>> >>
>> >
>> > Everyone. Would it be better to not enable that profile by default? So
>> > that a repository needs to be defined manually or Maven will not be able
>> > to download anything? That way users currently overriding 'central'
>> > somehow will not be affected and will just no longer override anything
>> > anymore. The super pom central will just disappear and the settings hold
>> > a template profile users need to enable themselves. Just needs to be
>> > documented in the introductory guides on the site as one of the first
>> > steps to do after installing Maven.
>> >
>> > Regards,
>>
>> So we want the URL of central to be configurable, or at least not
>> hard-coded? Why not define it in a properties file in the ${maven.conf}
>> directory? No profile hack required and a clean settings.xml.
>>
>> my 2 cents,
>> Robert
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #124: Fix formatting, convert tabs to spaces

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/124
  
@britter 
Done
Thx for contributing.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: upgrade maven plugin to run with asm 6?

[Romain Manni-Bucau]

Oh tested 3.4 but missed 3.5. 3.5 solved the issue!

Thanks!

Le 10 oct. 2016 20:31, "Martin Gainty"  a écrit :
>
>
>
>
> > From: rmannibu...@gmail.com
> > Date: Mon, 10 Oct 2016 17:07:54 +0200
> > Subject: Re: upgrade maven plugin to run with asm 6?
> > To: dev@maven.apache.org
> >
> > 2016-10-10 16:54 GMT+02:00 Martin Gainty :
> >
> > >
> > >
> > >
> > > > From: rmannibu...@gmail.com
> > > > Date: Mon, 10 Oct 2016 15:10:33 +0200
> > > > Subject: upgrade maven plugin to run with asm 6?
> > > > To: dev@maven.apache.org
> > > >
> > > > Hi guys,
> > > >
> > > > is there some plans to upgrade maven plugin to asm6 (thinking
> > > > to maven-plugin-tools-annotations and maven-plugin-plugin and more
> > > > concretely to DefaultMojoAnnotationsScanner used to generate the
help
> > > mojo)?
> > > >
> > > > I know there is only the alpha our ATM but I think it would enable
users
> > > to
> > > > start building using asm 6 instead of preventing them to run their
build
> > > > and the later upgrade would be smooth.
> > > MG>craft a q test-harness
> > > MG>switch JAVA to JDK 1.8
> > > MG>in test-harness substitute in asm-6 into dependency-management of
> > > parent pom
> > > MG>mvn package and observe:
> > > MG>ANY TEST ERRORS ?
> > > MG>ANY TEST FAILURES?
> > > MG>is JDKProxy being implemented to implement Interfaces?
> > > MG>is asm-6 being called to extend subclasses?
> > > MG>http://stackoverflow.com/questions/10664182/what-is-
> > > the-difference-between-jdk-dynamic-proxy-and-cglib
> > > MG>if all of these scenarios pass I think you will have a *convincing
> > > case* to upgrade asm to 6 in all plugins
> > > MG>I have a few spare cycles today so let me know if you need any
> > > assistance
> > >
> > >
> > so concretely I wanted to upgrade
> > https://github.com/tomitribe/crest/tree/master/crest-maven-plugin to
asm6
> > to support java 9 (not sure why you spoke of java 8, typo?) but the side
> > effect of upgrading it as a dependency of my project was to break the
> > maven-plugin-plugin. I'm not sure why isolation was broken but I'm very
> > concerned cause soon we'll upgrade the whole tomee stack to asm 6
(xbean,
> > openjpa, cxf, openwebbeans, batchee, tomee itself and probably a few I
> > forget) and most of them have maven plugins and would break.
> >
> > It fails with a NPE in Type.getProxyClass IIRC so maven annotation
scanner
> > doesn't work on java 9.
> MG>JDK 1.9 annotation processor has been "tweaked"
> MG>http://openjdk.java.net/jeps/217
> MG>which is the reason why I suggested using the older annotation scanner
> MG>do we know if error originates from ASM6 upgrade, maven-plugin or
JDK1.9 that said can you post a bug in JIRA?
> MG>https://maven.apache.org/issue-tracking.html
> >
> > Will be a bit short to help in the ~2 coming weeks but if nothing moved
> > next month I'll try to hack something up for sure!
> >
> >
> > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Wordpress Blog
> > > >  | Github  > > rmannibucau> |
> > > > LinkedIn  | Tomitriber
> > > >  | JavaEE Factory
> > > > 
> > >
>

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Igor Fedorenko]

Not just the url, but all aspect of "central" repository are
configurable in user settings.xml today. Even if we provide a better way
to express this configuration, I believe the old way should continue to
work for a few releases to allow graceful migration. Many users will use
multiple versions of maven side-by-side (think jenkins, for example).
And more generally, forcing settings.xml update is going to be a major
effort for larger organizations, with  100x or 1000x developers.

-- 
Regards,
Igor

On Mon, Oct 10, 2016, at 02:33 PM, Robert Scholte wrote:
> On Mon, 10 Oct 2016 16:22:20 +0200, Christian Schulte   
> wrote:
> 
> > Am 10.10.2016 um 16:16 schrieb Christian Schulte:
> >> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> >>> It is common to use repository with id=central in settings.xml to
> >>> override central location. This functionality should continue to work,
> >>> regardless how it is implemented in Maven internally.
> >>>
> >>
> >> 
> >>
> >>
> >
> > Everyone. Would it be better to not enable that profile by default? So
> > that a repository needs to be defined manually or Maven will not be able
> > to download anything? That way users currently overriding 'central'
> > somehow will not be affected and will just no longer override anything
> > anymore. The super pom central will just disappear and the settings hold
> > a template profile users need to enable themselves. Just needs to be
> > documented in the introductory guides on the site as one of the first
> > steps to do after installing Maven.
> >
> > Regards,
> 
> So we want the URL of central to be configurable, or at least not  
> hard-coded? Why not define it in a properties file in the ${maven.conf}  
> directory? No profile hack required and a clean settings.xml.
> 
> my 2 cents,
> Robert
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Igor Fedorenko]

Are repositories and other configuration defined in user settings.xml
take precedence over global settings.xml? 

-- 
Regards,
Igor

On Mon, Oct 10, 2016, at 10:16 AM, Christian Schulte wrote:
> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> > It is common to use repository with id=central in settings.xml to
> > override central location. This functionality should continue to work,
> > regardless how it is implemented in Maven internally.
> > 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0 Release

[Robert Scholte]

On Mon, 10 Oct 2016 11:08:52 +0200, Stephen Connolly  
 wrote:



On 10 October 2016 at 09:40, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:



https://issues.apache.org/jira/browse/MNG-5971

I would argue that the behaviour change in MNG-5971 should not be
introduced at the same time as a refactoring to move to the new "code
formerly known as Eclipse Aether but now at Apache under a different  
name"

codebase.

So, in short, I think of the 10 issues, only one "potentially" qualifies
as perhaps maybe requiring a modelVersion bump, and I would not want  
that

included with the other changes for 3.4.x anyway



Reading carefully through this issue I am inclined to lean towards
Stéphane's opinion that it is more of a bug fix than an RFE that has been
reported. That does not mean that the suggested implementation of the fix
is a bug fix or an RFE.

The real root problem here is that import scope was introduced without a
clear specification and there is no clear documentation on how exactly
import scope should work.

We have the principle that anything I declare in my pom wins.
After my pom, the next priority is my parent pom, followed by  
grandparent,

etc.
Only after that do we start looking at things defined in dependencies  
which

will win over anything defined in dependencyManagement...
Finally when resolving conflicts in dependency trees, only at that point  
do

we start getting complex and consider the tree depth... which closest
winning and finally pom order being used to resolve the case where tree
depth is equal (this last one is IMHO a mistake... rather we should fail
the build if pom order is the only way to resolve a conflict as pom order
is magic to most people... at least for inheritance purposes)

ASIDE: why is pom order unclear? Well if I have a  in my
parent and   in my pom, which entries come first...  
parent's
or child's? if the parent's then the parent wins and that breaks  
things...
if the child's then that is counter-intuitive for most people... never  
mind

that this important decision is not documented anywhere... oh and
help:effective-pom shows that the parent entries come first... which is  
at

odds with the child being able to override the parent... so if the child
needs to change the "pom-order" of dependencies inherited from its
parent... sorry out of luck

So what would I expect from scope=import... I would expect it to be an
in-place substitution of the  from the imported pom
(modulo duplicate removal)

In the situation of a lack of specification, fixing the behaviour to work
that way would be a bug fix... a bug fix with big consequences... but  
still

a bug fix within the scope of what we have called modelVersion 4.0.0
(because we added import scope without a clear specification)... it is  
not
furthering the mistake of adding import scope, rather it is clarifying  
the

(non-existing) specification of import scope.

I would not make such a change in 3.4.x though as it would conflate other
important changes that we need people to feel safe adopting so that we  
can

start to move forward again.

But that is my opinion... and I reserve the right to disagree with my own
opinion and to change my mind mid-sentence... especially in the light of  
a

better line of argument... just not seen one yet ;-)


Even if it is a bug, we know there are projects which rely on this  
behavoir for a long time. And for that reason I wouldn't fix it in 3.4.0.  
It would be nice if we could help projects relying on this bug by giving  
them a warning during build, but I can imagine that's hard to identify.


I personally would never set or change elements in a managed dependency  
which have a default value, because it can be confusing in the modules and  
childs using it. But since those elements are there in the model, they can  
be used. So maybe it is just my advice, and for those who want to use  
them, well, they can.


Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Robert Scholte]

On Mon, 10 Oct 2016 16:22:20 +0200, Christian Schulte   
wrote:



Am 10.10.2016 um 16:16 schrieb Christian Schulte:

Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:

It is common to use repository with id=central in settings.xml to
override central location. This functionality should continue to work,
regardless how it is implemented in Maven internally.








Everyone. Would it be better to not enable that profile by default? So
that a repository needs to be defined manually or Maven will not be able
to download anything? That way users currently overriding 'central'
somehow will not be affected and will just no longer override anything
anymore. The super pom central will just disappear and the settings hold
a template profile users need to enable themselves. Just needs to be
documented in the introductory guides on the site as one of the first
steps to do after installing Maven.

Regards,


So we want the URL of central to be configurable, or at least not  
hard-coded? Why not define it in a properties file in the ${maven.conf}  
directory? No profile hack required and a clean settings.xml.


my 2 cents,
Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: upgrade maven plugin to run with asm 6?

[Martin Gainty]

> From: rmannibu...@gmail.com
> Date: Mon, 10 Oct 2016 17:07:54 +0200
> Subject: Re: upgrade maven plugin to run with asm 6?
> To: dev@maven.apache.org
> 
> 2016-10-10 16:54 GMT+02:00 Martin Gainty :
> 
> >
> >
> >
> > > From: rmannibu...@gmail.com
> > > Date: Mon, 10 Oct 2016 15:10:33 +0200
> > > Subject: upgrade maven plugin to run with asm 6?
> > > To: dev@maven.apache.org
> > >
> > > Hi guys,
> > >
> > > is there some plans to upgrade maven plugin to asm6 (thinking
> > > to maven-plugin-tools-annotations and maven-plugin-plugin and more
> > > concretely to DefaultMojoAnnotationsScanner used to generate the help
> > mojo)?
> > >
> > > I know there is only the alpha our ATM but I think it would enable users
> > to
> > > start building using asm 6 instead of preventing them to run their build
> > > and the later upgrade would be smooth.
> > MG>craft a q test-harness
> > MG>switch JAVA to JDK 1.8
> > MG>in test-harness substitute in asm-6 into dependency-management of
> > parent pom
> > MG>mvn package and observe:
> > MG>ANY TEST ERRORS ?
> > MG>ANY TEST FAILURES?
> > MG>is JDKProxy being implemented to implement Interfaces?
> > MG>is asm-6 being called to extend subclasses?
> > MG>http://stackoverflow.com/questions/10664182/what-is-
> > the-difference-between-jdk-dynamic-proxy-and-cglib
> > MG>if all of these scenarios pass I think you will have a *convincing
> > case* to upgrade asm to 6 in all plugins
> > MG>I have a few spare cycles today so let me know if you need any
> > assistance
> >
> >
> so concretely I wanted to upgrade
> https://github.com/tomitribe/crest/tree/master/crest-maven-plugin to asm6
> to support java 9 (not sure why you spoke of java 8, typo?) but the side
> effect of upgrading it as a dependency of my project was to break the
> maven-plugin-plugin. I'm not sure why isolation was broken but I'm very
> concerned cause soon we'll upgrade the whole tomee stack to asm 6 (xbean,
> openjpa, cxf, openwebbeans, batchee, tomee itself and probably a few I
> forget) and most of them have maven plugins and would break.
> 
> It fails with a NPE in Type.getProxyClass IIRC so maven annotation scanner
> doesn't work on java 9.
MG>JDK 1.9 annotation processor has been "tweaked" 
MG>http://openjdk.java.net/jeps/217
MG>which is the reason why I suggested using the older annotation scanner
MG>do we know if error originates from ASM6 upgrade, maven-plugin or JDK1.9 
that said can you post a bug in JIRA?
MG>https://maven.apache.org/issue-tracking.html
> 
> Will be a bit short to help in the ~2 coming weeks but if nothing moved
> next month I'll try to hack something up for sure!
> 
> 
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Wordpress Blog
> > >  | Github  > rmannibucau> |
> > > LinkedIn  | Tomitriber
> > >  | JavaEE Factory
> > > 
> >
  

[VOTE] Release Apache Maven PMD Plugin version 3.7

[Andreas Dangel]

Hi,
 
We solved 11 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12334373=Text
 
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
 
Staging repo:
https://repository.apache.org/content/repositories/maven-1287
https://repository.apache.org/content/repositories/maven-1287/org/apache/maven/plugins/maven-pmd-plugin/3.7/maven-pmd-plugin-3.7-source-release.zip
 
Source release checksum(s):
maven-pmd-plugin-3.7-source-release.zip sha1:
a8ccd94fa6c41ef66ad29932027eb03ca45b402d
 
Staging site:
https://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/
 
Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html
 
Vote open for 72 hours.
 
[ ] +1
[ ] +0
[ ] -1

Regards,
Andreas



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: upgrade maven plugin to run with asm 6?

[Robert Scholte]

hi,

I've already done some improvements on the maven-plugin-plugin 3.5  
(released 2016-08-30) which should work with Java9.

If there's still an issue, let me know.

Robert

On Mon, 10 Oct 2016 17:07:54 +0200, Romain Manni-Bucau  
 wrote:



2016-10-10 16:54 GMT+02:00 Martin Gainty :





> From: rmannibu...@gmail.com
> Date: Mon, 10 Oct 2016 15:10:33 +0200
> Subject: upgrade maven plugin to run with asm 6?
> To: dev@maven.apache.org
>
> Hi guys,
>
> is there some plans to upgrade maven plugin to asm6 (thinking
> to maven-plugin-tools-annotations and maven-plugin-plugin and more
> concretely to DefaultMojoAnnotationsScanner used to generate the help
mojo)?
>
> I know there is only the alpha our ATM but I think it would enable  
users

to
> start building using asm 6 instead of preventing them to run their  
build

> and the later upgrade would be smooth.
MG>craft a q test-harness
MG>switch JAVA to JDK 1.8
MG>in test-harness substitute in asm-6 into dependency-management of
parent pom
MG>mvn package and observe:
MG>ANY TEST ERRORS ?
MG>ANY TEST FAILURES?
MG>is JDKProxy being implemented to implement Interfaces?
MG>is asm-6 being called to extend subclasses?
MG>http://stackoverflow.com/questions/10664182/what-is-
the-difference-between-jdk-dynamic-proxy-and-cglib
MG>if all of these scenarios pass I think you will have a *convincing
case* to upgrade asm to 6 in all plugins
MG>I have a few spare cycles today so let me know if you need any
assistance



so concretely I wanted to upgrade
https://github.com/tomitribe/crest/tree/master/crest-maven-plugin to asm6
to support java 9 (not sure why you spoke of java 8, typo?) but the side
effect of upgrading it as a dependency of my project was to break the
maven-plugin-plugin. I'm not sure why isolation was broken but I'm very
concerned cause soon we'll upgrade the whole tomee stack to asm 6 (xbean,
openjpa, cxf, openwebbeans, batchee, tomee itself and probably a few I
forget) and most of them have maven plugins and would break.

It fails with a NPE in Type.getProxyClass IIRC so maven annotation  
scanner

doesn't work on java 9.

Will be a bit short to help in the ~2 coming weeks but if nothing moved
next month I'll try to hack something up for sure!




>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github  |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)

[Benedikt Ritter]

Hello again,

Tibor Digana  schrieb am Mi., 5. Okt. 2016 um
00:05 Uhr:

> >>Or do we want to even share the test projects and work with profiles in
> the test project pom?
>
> I mean this.
>
> It pretty depends on what we are going to test, either:
> + features of surefire-junit5 provider, or
> + features of junit5 itself.
>
> I would say the provider in the first phase, and in the second phase we
> should identify junit5 features which do not exist in junit4 but may
> influence, e.g. Surefire report.
>
> The main purpose of integration testing is the interoperability between the
> main process of Maven and surefire (forked jvm or in-plugin process).
>
> This would lower the development time because you can already reuse
> existing tests.
> It would be nice to have profiles for vintage and jupiter. If we find out
> difference between reports, this can be a subject to a discovered bug.
> I think we can keep all IT projects and IT classes where they are and we
> can also keep sources using JUnit4 annotations together with JUnit5
> annotations. The best was that you split the JUni5 project into
> junit-jupiter-api and the core modules.
> If we just add junit-jupiter-api to the main  section in
> every POM, we do not break old tests because JUnit5 annotations do not
> break JUnit4 runners. If we want to run JUnit5 tests, then the profiles
> come into the role (one having junit-jupiter-engine
> 
> and
> another profile with junit-vintage-engine
> ,
> and finally profiles for old junit4 or 47). Unfortunately JUnit4 does not
> have separate module with annotations only. Therefore we may use
>  to exclude it if really necessary, see
>
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html
> Do you think this would work?
>

I found a way to this. I've modified the Junit4VersionIT again to run
against JUnit 4 and JUnit 5.

Drawbacks:
- all tests have to be run on Java 8. Otherwise we can't have the JUnit 5
annotations
- the profile for the jupiter engine also needs a dependency to junit 4.x.
Otherwise we get a compilation error because the old annotations are not
available.

I think this could be a starting point. After we have merged #126 from
GitHub, I can build this on top the parameterized test.

Regards,
Benedikt


>
> Cheers
> Tibor
>
>
> On Tue, Oct 4, 2016 at 7:48 PM, Benedikt Ritter [via Maven] <
> ml-node+s40175n5882181...@n5.nabble.com> wrote:
>
> > Hello Tibor,
> >
> > Tibor Digana <[hidden email]
> > > schrieb am Di.,
> > 4. Okt. 2016 um
> > 02:29 Uhr:
> >
> > > Can you simplify and speed up writing integration tests in the way that
> > you
> > > would parameterize the existing JUnit 4 testing by adding Maven
> profiles
> > > (one default profile and junit5 profile) having another dependencies
> and
> > > @RunWith(Parameterized.class)?
> > > This would be cool because we can have identical assertion statements,
> > > means behavior, for multiple providers.
> > >
> >
> > I was already thinking about this, because right now I'm duplicating a
> lot
> > of the code from the ITs. This is definitely a good idea. But right know
> I
> > don't have a clear view of how we could implement that. Do we just share
> > the test class and work with separate test projects? Or do we want to
> even
> > share the test projects and work with profiles in the test project pom?
> >
> > JUnit 5 also has support for running legacy tests (they call it
> > "vintage").
> > To make a complete IT suite, we would have to run all the JUnit 4 tests
> > against the JUnit 5 vintage engine as well.
> >
> > Lot a work ahead :-)
> >
> > Regards,
> > Benedikt
> >
> >
> > >
> > > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter <[hidden email]
> > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > now that we have a separate branch for the JUnit 5 support in the
> > > surefire
> > > > repo, I'm asking myself how to much things forward. I've added some
> > > > additional IT implementations in my GitHub fork, but they all fail
> > > because
> > > > the 5.0.0-M2 release of junit-surefire-provider does not implement
> the
> > > > desired features.
> > > >
> > > > At this point I'm pretty much blocked: I can not pick up the latest
> > > changes
> > > > to the JUnit 5 provider, because the JUnit team has not released it.
> > The
> > > > JUnit team does not push the development of the provider further,
> > since
> > > > they don't have integration tests...
> > > > Right now I think it would be best to start implementing a JUnit 5
> > > provider
> > > > ourself in the junit5 branch, so we can add the missing features and
> > have
> > > > it ready when JUnit 5 reaches GA.
> > > >
> > > > Thoughts?
> > > >
> > > > Benedikt
> > > >
> > >
> > >
> > >
> > > --
> > 

[GitHub] maven-surefire issue #126: Make Junit4VersionsIT parameterized

[britter]

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/126
  
We need to rebase the junit5 branch after this has been merged in order to 
pick up this changes.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[SUREFIRE] Hangout with Marc Philipp

[Benedikt Ritter]

Hi,

I've had the chance to talk to Marc Philipp from the JUnit team again, and
I'd like to share with you some of our discussions.

First we talked about the progress with the surefire provider:
Currently I've done not much. We have a junit5 branch with a single PR
merged (the JUnit5VersionsIT). Further more we have some pending PRs which
need to be reviewed/merged. We haven't done any "real" development yet.

I told Marc that a problem with implementing the ITs at the moment is, that
the JUnit 5.0.0-m2 provider implementation is very limited. So we thought
it may be a good thing to depend on the SNAPSHOT of JUnit5 in the junit5 as
long as we do not have our own implementation. This may be fragile, but we
can pick up the latest changes to the provider implementation.

Then we talked about moving the provider code from junit to maven-surefire.
This is clearly the preferred way to go for the junit team. From a user
perspective it would also be better to not have a junit provider and a
maven-surefire provider for junit5.

The problem we identified may be when this code could be released at
maven-surefire. Currently JUnit 5 GA is expected sometime in early 2017. If
the provider code is moved to maven-surefire there should be a release very
soon after the JUnit 5 GA release. Otherwise nobody can use JUnit 5 with
maven.
The alternative would be, that JUnit releases the provider implementation
when they go GA and after that the code is moved to surefire. The problem
with this approach is, that it may lead to confusion for the users.

My personal view is, that it would be good to integrate the provider code
into maven-surefire as soon as possible, but I not yet firm enough with the
code base the be really productive. I hope to get a better understanding of
the codebase during the next few weeks.

Regards,
Benedikt

Re: [SUREFIRE] Jenkins job for junit5 branch

[Benedikt Ritter]

Hi Christopher,

Christofer Dutz  schrieb am Mo., 10. Okt. 2016
um 10:49 Uhr:

> Hi Guys ... I just setup such a build with the Pipeline Plugin for the
> Flex project ... is working nicely. I could help you with this, if you like?
>

I leave this to the maven guys :-)


>
>
> Chris
>
> 
> Von: Tibor Digana 
> Gesendet: Montag, 10. Oktober 2016 08:15:25
> An: dev@maven.apache.org
> Betreff: Re: [SUREFIRE] Jenkins job for junit5 branch
>
> Excellent!
>
> On Sun, Oct 9, 2016 at 2:16 PM, Benedikt Ritter [via Maven] <
> ml-node+s40175n5882475...@n5.nabble.com> wrote:
>
> > Hello,
> >
> > I've created a build job for the junit5 branch [1]. It's a copy of the
> > maven-surefire job with the only difference that it does not publish
> build
> > artifacts to the snapshots repository. It maybe possible to configure
> this
> > more elegantly by using the Jenkins Pipeline Plugin, but I don't know
> how.
> > I think this is good enough for a start.
> >
> > Regards,
> > Benedikt
> >
> > [1] https://builds.apache.org/job/maven-surefire-junit5/
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://maven.40175.n5.nabble.com/SUREFIRE-Jenkins-job-for-
> > junit5-branch-tp5882475.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
> >
> > .
> > NAML
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Re-SUREFIRE-Jenkins-job-for-junit5-branch-tp5882626.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>

[GitHub] maven-surefire pull request #127: [SUREFIRE-1293] Simplify org.apache.maven....

[britter]

Github user britter commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/127#discussion_r82631034
  
--- Diff: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/NullStatisticsReporter.java
 ---
@@ -35,7 +36,7 @@
 
 public NullStatisticsReporter()
 {
-super( FileUtils.getTempDirectory() );
+super( FileUtils.getFile( FileUtils.getTempDirectory(), 
RandomStringUtils.randomAlphabetic( 24 ) ) );
--- End diff --

@Tibor17 makes sense. If we change it like this, we don't need the test to 
make sure the null objects can be created. I'll modify the PR to incorporate 
protected default constructors and remove the empty tests.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #127: [SUREFIRE-1293] Simplify org.apache.maven....

[britter]

Github user britter commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/127#discussion_r82631691
  
--- Diff: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/TestSetRunListener.java
 ---
@@ -76,7 +76,7 @@ public TestSetRunListener( ConsoleReporter 
consoleReporter, FileReporter fileRep
StatisticsReporter statisticsReporter, 
boolean trimStackTrace,
boolean isPlainFormat, boolean 
briefOrPlainFormat )
 {
-this.consoleReporter = consoleReporter;
+this.consoleReporter = consoleReporter != null ? consoleReporter : 
new NullConsoleReporter();
--- End diff --

> All of these classes are in surefire-common project. Therefore it would 
be nice not to create a new object new NullConsoleReporter() but instead keep 
it as static final constant in abstract Factory in surefire-common.

Agreed, I can change this.

> I would say that the caller should pass non-null consistent object into 
this class TestSetRunListener via constructor

Yes it would certainly be better to enforce this kinds of invariants. We 
can do it like this, but then the constructor of `TestSetRunListener` has to 
check for null parameters and throw an exception if null is passed.

> If we accepted such paradigm then all such occurrences in this PR would 
have to change it.

I don't understand. Change the whole surefire code base for all occurrences 
of this pattern?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #123: JUnit5: Add test for setting environment v...

[britter]

Github user britter closed the pull request at:

https://github.com/apache/maven-surefire/pull/123


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #123: JUnit5: Add test for setting environment variable...

[britter]

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/123
  
We don't need this anymore, since we'll go with the parameterized test 
approach.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: upgrade maven plugin to run with asm 6?

[Romain Manni-Bucau]

2016-10-10 16:54 GMT+02:00 Martin Gainty :

>
>
>
> > From: rmannibu...@gmail.com
> > Date: Mon, 10 Oct 2016 15:10:33 +0200
> > Subject: upgrade maven plugin to run with asm 6?
> > To: dev@maven.apache.org
> >
> > Hi guys,
> >
> > is there some plans to upgrade maven plugin to asm6 (thinking
> > to maven-plugin-tools-annotations and maven-plugin-plugin and more
> > concretely to DefaultMojoAnnotationsScanner used to generate the help
> mojo)?
> >
> > I know there is only the alpha our ATM but I think it would enable users
> to
> > start building using asm 6 instead of preventing them to run their build
> > and the later upgrade would be smooth.
> MG>craft a q test-harness
> MG>switch JAVA to JDK 1.8
> MG>in test-harness substitute in asm-6 into dependency-management of
> parent pom
> MG>mvn package and observe:
> MG>ANY TEST ERRORS ?
> MG>ANY TEST FAILURES?
> MG>is JDKProxy being implemented to implement Interfaces?
> MG>is asm-6 being called to extend subclasses?
> MG>http://stackoverflow.com/questions/10664182/what-is-
> the-difference-between-jdk-dynamic-proxy-and-cglib
> MG>if all of these scenarios pass I think you will have a *convincing
> case* to upgrade asm to 6 in all plugins
> MG>I have a few spare cycles today so let me know if you need any
> assistance
>
>
so concretely I wanted to upgrade
https://github.com/tomitribe/crest/tree/master/crest-maven-plugin to asm6
to support java 9 (not sure why you spoke of java 8, typo?) but the side
effect of upgrading it as a dependency of my project was to break the
maven-plugin-plugin. I'm not sure why isolation was broken but I'm very
concerned cause soon we'll upgrade the whole tomee stack to asm 6 (xbean,
openjpa, cxf, openwebbeans, batchee, tomee itself and probably a few I
forget) and most of them have maven plugins and would break.

It fails with a NPE in Type.getProxyClass IIRC so maven annotation scanner
doesn't work on java 9.

Will be a bit short to help in the ~2 coming weeks but if nothing moved
next month I'll try to hack something up for sure!


>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github  rmannibucau> |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
>

RE: upgrade maven plugin to run with asm 6?

[Martin Gainty]

> From: rmannibu...@gmail.com
> Date: Mon, 10 Oct 2016 15:10:33 +0200
> Subject: upgrade maven plugin to run with asm 6?
> To: dev@maven.apache.org
> 
> Hi guys,
> 
> is there some plans to upgrade maven plugin to asm6 (thinking
> to maven-plugin-tools-annotations and maven-plugin-plugin and more
> concretely to DefaultMojoAnnotationsScanner used to generate the help mojo)?
> 
> I know there is only the alpha our ATM but I think it would enable users to
> start building using asm 6 instead of preventing them to run their build
> and the later upgrade would be smooth.
MG>craft a q test-harness
MG>switch JAVA to JDK 1.8
MG>in test-harness substitute in asm-6 into dependency-management of parent pom
MG>mvn package and observe:
MG>ANY TEST ERRORS ?
MG>ANY TEST FAILURES?
MG>is JDKProxy being implemented to implement Interfaces?
MG>is asm-6 being called to extend subclasses?
MG>http://stackoverflow.com/questions/10664182/what-is-the-difference-between-jdk-dynamic-proxy-and-cglib
MG>if all of these scenarios pass I think you will have a *convincing case* to 
upgrade asm to 6 in all plugins
MG>I have a few spare cycles today so let me know if you need any assistance


> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github  |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
  

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Christian Schulte]

Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> It is common to use repository with id=central in settings.xml to
> override central location. This functionality should continue to work,
> regardless how it is implemented in Maven internally.
> 

Do you have a wildcard mirror in the settings as well? Overriding
'central' is not enough when the projects to build contain repositories
(maybe central with a different id or something pointing somewhere
else). What I mean is: Overriding 'central' makes no sense most of the
time. This functionality should contine to work, of course.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Christian Schulte]

Am 10.10.2016 um 16:16 schrieb Christian Schulte:
> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
>> It is common to use repository with id=central in settings.xml to
>> override central location. This functionality should continue to work,
>> regardless how it is implemented in Maven internally.
>>
> 
> 
> 
> 

Everyone. Would it be better to not enable that profile by default? So
that a repository needs to be defined manually or Maven will not be able
to download anything? That way users currently overriding 'central'
somehow will not be affected and will just no longer override anything
anymore. The super pom central will just disappear and the settings hold
a template profile users need to enable themselves. Just needs to be
documented in the introductory guides on the site as one of the first
steps to do after installing Maven.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Christian Schulte]

Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> It is common to use repository with id=central in settings.xml to
> override central location. This functionality should continue to work,
> regardless how it is implemented in Maven internally.
> 




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Christian Schulte]

Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> It is common to use repository with id=central in settings.xml to
> override central location. This functionality should continue to work,
> regardless how it is implemented in Maven internally.
> 

That is what has become the default. Did you look at the settings.xml
file? It contains a profile with the central repository. Just disable
that profile or change it. What you did in the past is what gets shipped
by default in 3.4.0-SNAPSHOT. There will be no repositories in the super
pom any more. What exactly does not work for you that way?

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Igor Fedorenko]

It is common to use repository with id=central in settings.xml to
override central location. This functionality should continue to work,
regardless how it is implemented in Maven internally.

-- 
Regards,
Igor

On Mon, Oct 10, 2016, at 09:10 AM, Christian Schulte wrote:
> Am 10/10/16 um 14:45 schrieb Mirko Friedenhagen:
> > Hello,
> > 
> > I just tried to run "mvn help:effective-pom -Doutput=MVNVERSION.xml"
> > on one of our inhouse projects once with 3.3.9 and once with
> > 3.4.0-SNAPSHOT (4ad0fb217c93d36cf3365b83baec48470196f5fa;
> > 2016-10-09T21:16:52+02:00)
> > 
> > 3.4.0 seems not to incorporate settings correctly (or I misconfigured
> > something). We override the 'central' repository in
> > $HOME/.m2/settings.xml and point to our internal Artifactory instance.
> > However in the effective-pom I see re
> > 
> > This is a part of the diff:
> > 
> >  central
> > -Everything via internal-central
> > -http://inhouse.server/artifactory/internal-central/
> > +Central Repository
> > +https://repo.maven.apache.org/maven2
> >
> > 
> > Now I see not only effective-pom is afffected, I am unable to download
> > stuff from our internal Artifactory, so builds fail completely.
> 
> Did you take a look at the 3.4.0-SNAPSHOT settings.xml? You may need to
> disable the profile bringing in the 'central' repository. This is a
> relict of moving the central repository out of the super pom. Super POM
> 4.0.0 has the repository, current master super POM 4.1.0 does not have
> it and needs the profile. This is work in progress. Super POM 4.1.0 will
> get deleted in the next days. Maybe the central repository will be
> removed from super POM 4.0.0 instead. No release notes yet.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

upgrade maven plugin to run with asm 6?

[Romain Manni-Bucau]

Hi guys,

is there some plans to upgrade maven plugin to asm6 (thinking
to maven-plugin-tools-annotations and maven-plugin-plugin and more
concretely to DefaultMojoAnnotationsScanner used to generate the help mojo)?

I know there is only the alpha our ATM but I think it would enable users to
start building using asm 6 instead of preventing them to run their build
and the later upgrade would be smooth.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Christian Schulte]

Am 10/10/16 um 14:45 schrieb Mirko Friedenhagen:
> Hello,
> 
> I just tried to run "mvn help:effective-pom -Doutput=MVNVERSION.xml"
> on one of our inhouse projects once with 3.3.9 and once with
> 3.4.0-SNAPSHOT (4ad0fb217c93d36cf3365b83baec48470196f5fa;
> 2016-10-09T21:16:52+02:00)
> 
> 3.4.0 seems not to incorporate settings correctly (or I misconfigured
> something). We override the 'central' repository in
> $HOME/.m2/settings.xml and point to our internal Artifactory instance.
> However in the effective-pom I see re
> 
> This is a part of the diff:
> 
>  central
> -Everything via internal-central
> -http://inhouse.server/artifactory/internal-central/
> +Central Repository
> +https://repo.maven.apache.org/maven2
>
> 
> Now I see not only effective-pom is afffected, I am unable to download
> stuff from our internal Artifactory, so builds fail completely.

Did you take a look at the 3.4.0-SNAPSHOT settings.xml? You may need to
disable the profile bringing in the 'central' repository. This is a
relict of moving the central repository out of the super pom. Super POM
4.0.0 has the repository, current master super POM 4.1.0 does not have
it and needs the profile. This is work in progress. Super POM 4.1.0 will
get deleted in the next days. Maybe the central repository will be
removed from super POM 4.0.0 instead. No release notes yet.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Mirko Friedenhagen]

Hello,

I just tried to run "mvn help:effective-pom -Doutput=MVNVERSION.xml"
on one of our inhouse projects once with 3.3.9 and once with
3.4.0-SNAPSHOT (4ad0fb217c93d36cf3365b83baec48470196f5fa;
2016-10-09T21:16:52+02:00)

3.4.0 seems not to incorporate settings correctly (or I misconfigured
something). We override the 'central' repository in
$HOME/.m2/settings.xml and point to our internal Artifactory instance.
However in the effective-pom I see re

This is a part of the diff:

 central
-Everything via internal-central
-http://inhouse.server/artifactory/internal-central/
+Central Repository
+https://repo.maven.apache.org/maven2
   

Now I see not only effective-pom is afffected, I am unable to download
stuff from our internal Artifactory, so builds fail completely.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-plugins pull request #38: MJAVADOC-410

[vincent-zurczak]

Github user vincent-zurczak closed the pull request at:

https://github.com/apache/maven-plugins/pull/38


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0 Release

[Stephen Connolly]

On 10 October 2016 at 09:40, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
> https://issues.apache.org/jira/browse/MNG-5971
>
> I would argue that the behaviour change in MNG-5971 should not be
> introduced at the same time as a refactoring to move to the new "code
> formerly known as Eclipse Aether but now at Apache under a different name"
> codebase.
>
> So, in short, I think of the 10 issues, only one "potentially" qualifies
> as perhaps maybe requiring a modelVersion bump, and I would not want that
> included with the other changes for 3.4.x anyway
>
>
Reading carefully through this issue I am inclined to lean towards
Stéphane's opinion that it is more of a bug fix than an RFE that has been
reported. That does not mean that the suggested implementation of the fix
is a bug fix or an RFE.

The real root problem here is that import scope was introduced without a
clear specification and there is no clear documentation on how exactly
import scope should work.

We have the principle that anything I declare in my pom wins.
After my pom, the next priority is my parent pom, followed by grandparent,
etc.
Only after that do we start looking at things defined in dependencies which
will win over anything defined in dependencyManagement...
Finally when resolving conflicts in dependency trees, only at that point do
we start getting complex and consider the tree depth... which closest
winning and finally pom order being used to resolve the case where tree
depth is equal (this last one is IMHO a mistake... rather we should fail
the build if pom order is the only way to resolve a conflict as pom order
is magic to most people... at least for inheritance purposes)

ASIDE: why is pom order unclear? Well if I have a  in my
parent and   in my pom, which entries come first... parent's
or child's? if the parent's then the parent wins and that breaks things...
if the child's then that is counter-intuitive for most people... never mind
that this important decision is not documented anywhere... oh and
help:effective-pom shows that the parent entries come first... which is at
odds with the child being able to override the parent... so if the child
needs to change the "pom-order" of dependencies inherited from its
parent... sorry out of luck

So what would I expect from scope=import... I would expect it to be an
in-place substitution of the  from the imported pom
(modulo duplicate removal)

In the situation of a lack of specification, fixing the behaviour to work
that way would be a bug fix... a bug fix with big consequences... but still
a bug fix within the scope of what we have called modelVersion 4.0.0
(because we added import scope without a clear specification)... it is not
furthering the mistake of adding import scope, rather it is clarifying the
(non-existing) specification of import scope.

I would not make such a change in 3.4.x though as it would conflate other
important changes that we need people to feel safe adopting so that we can
start to move forward again.

But that is my opinion... and I reserve the right to disagree with my own
opinion and to change my mind mid-sentence... especially in the light of a
better line of argument... just not seen one yet ;-)

AW: [SUREFIRE] Jenkins job for junit5 branch

[Christofer Dutz]

Hi Guys ... I just setup such a build with the Pipeline Plugin for the Flex 
project ... is working nicely. I could help you with this, if you like?


Chris


Von: Tibor Digana 
Gesendet: Montag, 10. Oktober 2016 08:15:25
An: dev@maven.apache.org
Betreff: Re: [SUREFIRE] Jenkins job for junit5 branch

Excellent!

On Sun, Oct 9, 2016 at 2:16 PM, Benedikt Ritter [via Maven] <
ml-node+s40175n5882475...@n5.nabble.com> wrote:

> Hello,
>
> I've created a build job for the junit5 branch [1]. It's a copy of the
> maven-surefire job with the only difference that it does not publish build
> artifacts to the snapshots repository. It maybe possible to configure this
> more elegantly by using the Jenkins Pipeline Plugin, but I don't know how.
> I think this is good enough for a start.
>
> Regards,
> Benedikt
>
> [1] https://builds.apache.org/job/maven-surefire-junit5/
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/SUREFIRE-Jenkins-job-for-
> junit5-branch-tp5882475.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-SUREFIRE-Jenkins-job-for-junit5-branch-tp5882626.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: Maven 3.4.0 Release

[Stephen Connolly]

The following issues IMHO all affect build time behaviour and do not affect
dependency consumption.
As such they do not require a modelVersion bump

https://issues.apache.org/jira/browse/MNG-6054
https://issues.apache.org/jira/browse/MNG-5992
https://issues.apache.org/jira/browse/MNG-5968
https://issues.apache.org/jira/browse/MNG-5940
https://issues.apache.org/jira/browse/MNG-4645
https://issues.apache.org/jira/browse/MNG-2478

The following issues affect dependency consumption, but IMHO could be
considered as bug fixes rather than RFEs. Strictly speaking they involve
behaviours that we have never specified and thus it is questionable as to
whether they are deviating from the original intent (in which case they
would be RFEs and warrant a modelVersion bump) or whether they align with
the original intent (which makes them bugs and not requiring of a
modelVersion bump)

https://issues.apache.org/jira/browse/MNG-5527 - clearly a bug
https://issues.apache.org/jira/browse/MNG-4463 - clearly a bug
https://issues.apache.org/jira/browse/MNG-5600 - less clear, import scope
itself should probably have required a modelVersion bump or at least a
clear specification, but that ship has sailed... this new behaviour aligns
with the unspecifiied expectations I would have of how a scope and
exclusions would work, so IMHO that makes it a bug

That just leaves:

https://issues.apache.org/jira/browse/MNG-5971

I would argue that the behaviour change in MNG-5971 should not be
introduced at the same time as a refactoring to move to the new "code
formerly known as Eclipse Aether but now at Apache under a different name"
codebase.

So, in short, I think of the 10 issues, only one "potentially" qualifies as
perhaps maybe requiring a modelVersion bump, and I would not want that
included with the other changes for 3.4.x anyway

On 10 October 2016 at 09:26, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 10 October 2016 at 01:38, Christian Schulte  wrote:
>
>> Am 10/09/16 um 21:44 schrieb Stephen Connolly:
>> > Open issues bound to 3.4.0
>> >
>> > * Introduction of model version 4.1.0.
>> >   https://issues.apache.org/jira/browse/MNG-6082
>> > 
>> >   assignee: Christian Schulte (reporter: Christian Schulte)
>> >
>> >
>> > I am -1 on this change as I understand it as it will break central for
>> > older consumers.
>>
>> That's why I asked what I should do about it. I can easily
>> revert/disable things. I thought we are not going to release 3.4 but 4.0
>> with the new model version and PDT support, no? So there will be a 3.4
>> release? Please see all the issues MNG-6082 is linked to. Not bumping
>> the model version means disabling almost all of the changes done for
>> those issues. I'd really would not want to do that. Yes. Model version
>> 4.1.0 will never get released. I got that. I thought we are already
>> working on model version 5.0.0 / PDT and that will make shipping those
>> changes possible.
>>
>
> Well we need to decide what to do now about cutting a release with the
> code formerly known as Eclipse Aether at its new home... which AIUI is what
> 3.4.0 would be.
>
> We cannot ship anything that deploys a pom with a modelVersion other than
> 4.0.0 IMHO as that would require forking the central repository.
>
> There is still some work to be done on getting the proposals for how to
> move forward safely... and I am not seeing much engagement with the work I
> have been trying to do... which scares me somewhat...
>
> If we need to unwind some of the changes you made that required a
> modelVersion bump then I think we need to do that... but I am not seeing
> others chime in on this topic either...
>
>
>>
>> Regards,
>> --
>> Christian
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: Maven 3.4.0 Release

[Stephen Connolly]

On 10 October 2016 at 01:38, Christian Schulte  wrote:

> Am 10/09/16 um 21:44 schrieb Stephen Connolly:
> > Open issues bound to 3.4.0
> >
> > * Introduction of model version 4.1.0.
> >   https://issues.apache.org/jira/browse/MNG-6082
> > 
> >   assignee: Christian Schulte (reporter: Christian Schulte)
> >
> >
> > I am -1 on this change as I understand it as it will break central for
> > older consumers.
>
> That's why I asked what I should do about it. I can easily
> revert/disable things. I thought we are not going to release 3.4 but 4.0
> with the new model version and PDT support, no? So there will be a 3.4
> release? Please see all the issues MNG-6082 is linked to. Not bumping
> the model version means disabling almost all of the changes done for
> those issues. I'd really would not want to do that. Yes. Model version
> 4.1.0 will never get released. I got that. I thought we are already
> working on model version 5.0.0 / PDT and that will make shipping those
> changes possible.
>

Well we need to decide what to do now about cutting a release with the code
formerly known as Eclipse Aether at its new home... which AIUI is what
3.4.0 would be.

We cannot ship anything that deploys a pom with a modelVersion other than
4.0.0 IMHO as that would require forking the central repository.

There is still some work to be done on getting the proposals for how to
move forward safely... and I am not seeing much engagement with the work I
have been trying to do... which scares me somewhat...

If we need to unwind some of the changes you made that required a
modelVersion bump then I think we need to do that... but I am not seeing
others chime in on this topic either...


>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

Le lundi 10 octobre 2016 02:47:36 Christian Schulte a écrit :
> Am 10/09/16 um 14:10 schrieb Jason van Zyl:
> > The preparation of detailed released notes to be reviewed. The last
> > release was almost a year ago, and an enormous number of behavioral
> > changes have been made in that time-frame. There’s zero documentation
> > outlining these changes thus far in the site as far as I can tell. That’s
> > the only requirement I see.
> I deferred writing documentation (maven site) until things have been
> sorted out. Maybe the list of behavioral changes will soon become much
> smaller maybe even zero.
notice that we also have the Wiki and RFC [1] or Proposals [2] space to 
organize documentation on features while work in progress: this may be a good 
place

Regards,

Hervé

[1] https://cwiki.apache.org/confluence/display/MAVEN/Requests+for+Comment

[2] https://cwiki.apache.org/confluence/display/MAVEN/Proposals


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

Le lundi 10 octobre 2016 00:25:26 Michael Osipov a écrit :
> Am 2016-10-09 um 23:51 schrieb Hervé BOUTEMY:
> > Le dimanche 9 octobre 2016 21:11:03 Michael Osipov a écrit :
> >> Am 2016-10-09 um 20:41 schrieb Robert Scholte:
> >>> Open issues bound to 3.4.0
> >>> 
> >>> * Document how to configure Gossip
> >>> 
> >>>   https://issues.apache.org/jira/browse/MNG-6044
> >>>   assignee: - (reporter: Michael Osipov)
> >> 
> >> I am not able to properly solve this issue because I have no idea about
> >> Gossip. This should really come from Jason Dillon.
> > 
> > I suppose we can read the doc and test ourselves
> > But apart from documentation, there was some complaints about some
> > features
> > available in slf4j-simple that is not available in gossip: I don't know
> > how
> > much people will really have such issue
> 
> Which are? Have you raised them with Jason Dillon?
see "relative timestamp" in 
http://mail-archives.apache.org/mod_mbox/maven-dev/201607.mbox/%3CCAK8jvqxYNK4weM2Frp4Brg3J7EybyjBiCsSRdGuNMQhYAG728Q%40mail.gmail.com%3E

> 
> > an option I tried (and need to finish) is MNG-6093, ie do a little
> > modification of slf4j-simple to add color to the little necessary places.
> > Is such an option, which is not ideal either, better than changing the
> > overall knowledge of people have with slf4j-simple?
> > Any thought?
> 
> A very good idea. Having this upstream in a mainstream library is
> definitively boost acceptance.
now that it works (TM), I'll change the code to be a (little) patch to the 
slf4j-simple source for the official release

> 
> Michael
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [SUREFIRE] Jenkins job for junit5 branch

[Tibor Digana]

Excellent!

On Sun, Oct 9, 2016 at 2:16 PM, Benedikt Ritter [via Maven] <
ml-node+s40175n5882475...@n5.nabble.com> wrote:

> Hello,
>
> I've created a build job for the junit5 branch [1]. It's a copy of the
> maven-surefire job with the only difference that it does not publish build
> artifacts to the snapshots repository. It maybe possible to configure this
> more elegantly by using the Jenkins Pipeline Plugin, but I don't know how.
> I think this is good enough for a start.
>
> Regards,
> Benedikt
>
> [1] https://builds.apache.org/job/maven-surefire-junit5/
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/SUREFIRE-Jenkins-job-for-
> junit5-branch-tp5882475.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-SUREFIRE-Jenkins-job-for-junit5-branch-tp5882626.html
Sent from the Maven Developers mailing list archive at Nabble.com.