Re: [jira] [Commented] (MSHARED-594) NullPointerException is thrown when trying to install a project without POM file

[Karl Heinz Marbaise]

Hi Buillaume,

On 08/10/16 22:08, Guillaume Boué wrote:

Hi,

It is allowed by install:install-file when you set generatePom=false. It
would install for example a JAR without any POM. It is true that you
won't be able to depend on the artifact as-is... perhaps we should force
generatePom=true then?


Haven't thought about that case...
generatePom = true ? may be this is worth to think about it more in detail..


Thanks for explanation..

Kind regards
Karl Heinz



This was a corner-case that I hit for
https://issues.apache.org/jira/browse/MINSTALL-128, and I wanted to keep
the current behaviour.

Guillaume

Le 08/10/2016 à 20:38, Karl Heinz Marbaise a écrit :

Hi Guillaume,

On 08/10/16 20:30, Guillaume Boué (JIRA) wrote:

When creating in-memory Maven projects with the {{ProjectBuilder}},

> it could not have a POM file: the intent is that
>  it only has attached artifacts and only those should get installed.

Maybe I misunderstand a thing here...

But if the project has only attached artifacts and those artifacts
will be installed without a POM how should I ever use them ?


Kind regards
Karl Heinz Marbaise

-
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: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

[Robert Scholte]

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it  
hasn't been pushed to all plugins which should use it instead of the  
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several plugins  
I just hit these edge cases where the local repo is not always the target  
repo.


Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué   
wrote:



Hi,

 From what I checked, I don't think those plugins should be impacted  
since they use the ArtifactInstaller directly, and not the  
ProjectInstaller.


But I can add an overload taking an ArtifactRepository which would get  
the path to the artifact with "artifactRepository.pathOf(artifact)". And  
then go with the one using the RepositoryManager or not, depending on  
whether the ArtifactRepository is null or not.


Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create their  
own local repository, for instance maven-invoker-plugin and  
maven-dependency-plugin. In those cases you should pass the  
ArtifactRepository.
So we will need those versions too, either as overloaded method or  
restored where artifactRepository can be null.


thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200,  wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929&view=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local  
repository should be retrieved from the RepositoryManager


We need to rely on the RepositoryManager to get a hold of the local  
repository base directory.


Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

Modified:  
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
URL:  
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929&r1=1763928&r2=1763929&view=diff
==  
---  
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java  
(original)
+++  
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java  
Sat Oct  8 18:43:58 2016

@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project ) )  
);
-installChecksums( buildingRequest,  
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,  
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,  
artifact, metadataFiles, createChecksum );

 }
 }
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
 if ( file != null && file.isFile() )
 {
 installer.install( buildingRequest,  
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest,  
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,  
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,  
artifact, metadataFiles, createChecksum );

 }
 else if ( !attachedArtifacts.isEmpty() )
@@ -139,7 +139,7 @@ public class DefaultProjectInstaller
 for ( Artifact attached : attachedArtifacts )
 {
 installer.install( buildingRequest,  
Collections.singletonList( attached ) );
-installChecksums( buildingRequest, artifactRepository,  
attached, createChecksum );
+installChecksums( buildingRequest, attached,  
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,  
attached, metadataFiles, createChecksum );

 }
@@ -153,12 +153,12 @@ public class DefaultProjectInstaller
  * the original POM file (cf. MNG-2820). While the plugin  
currently requires Maven 2.0.6, we continue to hash the
  * installed POM for robustness with regard to future changes  
like re-introducing some kind of POM filtering.

  *
+ * @param buildingRequest The project building request, must not  
be null.
  * @param artifact The artifact for which to create checksums,  
must not be null.
  * @param createChecksum {@code true} if checksum should be  
created, otherwise {@code false}.

  * @throws IOException If the checksums could not be installed.
  */
-private void installChecksums( ProjectBuildingRequest  
buildingRequest, ArtifactRepository artifactRepository,
-   Artifact artifact, bo

Re: [jira] [Created] (MINSTALL-128) Replace usage of the deprecated ArtifactFactory

[Karl Heinz Marbaise]

Hi Guillaume,

the code duplication was based on the first steps I had done to move the 
general cases to the shared component...and it's good that you cleaned 
up the code in maven-install-plugin...


Kind regards
Karl Heinz

On 08/10/16 22:06, Guillaume Boué (JIRA) wrote:

Guillaume Boué created MINSTALL-128:
---

 Summary: Replace usage of the deprecated ArtifactFactory
 Key: MINSTALL-128
 URL: https://issues.apache.org/jira/browse/MINSTALL-128
 Project: Maven Install Plugin
  Issue Type: Improvement
  Components: install:install-file
Affects Versions: 2.5.2
Reporter: Guillaume Boué
Assignee: Guillaume Boué
 Fix For: 3.0.0


The {{install-file}} goal is using the deprecated {{ArtifactFactory}}. Instead, 
this goal should create a new Maven project and attach to it all the artifacts 
to install.

As bonus side-effect, this will enable the re-use of the shared component 
{{ProjectDeployer}} and remove the current code duplication for the generation 
of the checksums (there are two {{DualDigester}}: one in the plugin's code and 
one in the shared component used by the {{install}} goal).




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

[GitHub] maven issue #94: MNG-5889 - adding logic that looks for the file argument an...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven/pull/94
  
@rpatrick00 
It looks like "--file" is not recognize but "-file" is recognized.
The second issue where I have `/a/b` folders and `b` contains single 
`pom.xml` and `.mvn` - no multimodule.
`cd /a` which does not have `.mvn` and start `mvn -file b/pom.xml`. There 
my `vm.config` is not applied, why? Tested on Win. I will try in Fedora as well.


---
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: shared: maven-artifact-transfer

[Karl Heinz Marbaise]

Hi,

I'm trying to continue to write tests for the component, but at the 
momemt it seemed to me that I oversight something...(I'm blockhead at 
the moment)


The pom of the component:
https://gist.github.com/khmarbaise/2ed49e791bab6a374b7862691dbfd7b5

and the output if i try to run: mvn clean verify...

https://gist.github.com/khmarbaise/f55b679b775850836f321b78273ca573


So based on the error message (at the end):

2) No implementation for org.eclipse.aether.impl.VersionRangeResolver 
was bound.

  while locating org.eclipse.aether.impl.VersionRangeResolver

It looks like it's missing an implementation for 
VersionRangeResolver...which is part of


  
  org.eclipse.aether
  aether-impl
  0.9.0.M2
  provided


So it should mean that I need to change from provided to test 
scope...but this does not help here...the error message keeps the same...



Maybe someone of you have a hint an idea ?


Kind regards
Karl Heinz Marbaise


On 24/09/16 18:27, Robert Scholte wrote:

On Sat, 24 Sep 2016 11:15:41 +0200, Karl Heinz Marbaise
 wrote:


Hi,

So I'm trying to write more tests on the component...in particular for
the new parts like ProjectInstaller etc. I started with
ProjectInstaller...(Created gist for that:
https://gist.github.com/khmarbaise/1ed421983480e3fef624bf6c8f4844b6).

If I try to run that I'm getting always errors like this:


testShouldInstallSingleArtifact(org.apache.maven.shared.project.install.ProjectInstallerTest)
  Time elapsed: 0.134 sec  <<< ERROR!
org.codehaus.plexus.component.repository.exception.ComponentLookupException:

com.google.inject.ProvisionException: Guice provision errors:

1) Error injecting:
org.apache.maven.shared.artifact.install.internal.Maven31ArtifactInstaller

   at ClassRealm[plexus.core, parent: null]
   at ClassRealm[plexus.core, parent: null]
   while locating
org.apache.maven.shared.artifact.install.ArtifactInstaller annotated
with @com.google.inject.name.Named(value=maven31)

1 error
   role: org.apache.maven.shared.artifact.install.ArtifactInstaller
   roleHint: maven31
at
org.apache.maven.shared.project.install.ProjectInstallerTest.setUp(ProjectInstallerTest.java:46)

Caused by: com.google.inject.ProvisionException:
Guice provision errors:

I had expected that the ArtifactInstaller will be selected
automatically based on the running Maven version (3.3.9)...


No, it is just a JUnit-test like any other. The version of the Maven
dependencies are those specified in the pom.xml. Only when using the
Maven runtime, these dependencies are stripped out and the runtime
versions are used (Plexus Classworld).

Robert



maybe someone has an idea/tip/hint what I'm doing wrong...



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

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

[Karl Heinz Marbaise]

Hi,

Yes it has been introduced by me...and yes not all plugins are using it 
cause I would like to have some tests before spreading it to the "world" 
of plugins..


Kind regards
Karl Heinz


On 09/10/16 11:07, Robert Scholte wrote:

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it
hasn't been pushed to all plugins which should use it instead of the
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several
plugins I just hit these edge cases where the local repo is not always
the target repo.

Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué 
wrote:


Hi,

 From what I checked, I don't think those plugins should be impacted
since they use the ArtifactInstaller directly, and not the
ProjectInstaller.

But I can add an overload taking an ArtifactRepository which would get
the path to the artifact with "artifactRepository.pathOf(artifact)".
And then go with the one using the RepositoryManager or not, depending
on whether the ArtifactRepository is null or not.

Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create
their own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.

thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200,  wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929&view=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager

We need to rely on the RepositoryManager to get a hold of the local
repository base directory.

Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java


Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929&r1=1763928&r2=1763929&view=diff

==
---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
Sat Oct  8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project )
) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 }
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
 if ( file != null && file.isFile() )
 {
 installer.install( buildingRequest,
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 else if ( !attachedArtifacts.isEmpty() )
@@ -139,7 +139,7 @@ public class DefaultProjectInstaller
 for ( Artifact attached : attachedArtifacts )
 {
 installer.install( buildingRequest,
Collections.singletonList( attached ) );
-installChecksums( buildingRequest, artifactRepository,
attached, createChecksum );
+installChecksums( buildingRequest, attached,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
attached, metadataFiles, createChecksum );
 }
@@ -153,12 +153,12 @@ public class DefaultProjectInstaller
  * the original POM file (cf. MNG-2820). While the plugin
currently requires Maven 2.0.6, we continue to hash the
  * installed POM for robustness with regard to future changes
like re-introducing some kind of POM filtering.
  *
+ * @param buildingRequest The project building request, must
not be null.
  * @param artifact The artifact for which to create checksums,
must not be null.
  * @param createChecksum {@code true} if checksum should be
created, otherwise {@code false}.
  * @throws IOException If the checksums could not be installed.
  */
-private void installChec

Re: shared: maven-artifact-transfer

[Robert Scholte]

Hi Karl Heinz,

The VersionRangeResolver is an interface for which Maven has a default  
implementation.
Since maven-transfer-utils depends on Maven 3.0, there's the  
org.apache.maven.repository.internal.DefaultVersionRangeResolver which  
implements the Sonatype version of VersionRangeResolver.
There's simply no Eclipse version implementation available for  
VersionRangeResolver.


In case of unittests, you will always fall back on Sonatype's Aether, only  
with integration tests you can test Eclipse's Aether.


Robert

On Sun, 09 Oct 2016 11:29:59 +0200, Karl Heinz Marbaise  
 wrote:



Hi,

I'm trying to continue to write tests for the component, but at the  
momemt it seemed to me that I oversight something...(I'm blockhead at  
the moment)


The pom of the component:
https://gist.github.com/khmarbaise/2ed49e791bab6a374b7862691dbfd7b5

and the output if i try to run: mvn clean verify...

https://gist.github.com/khmarbaise/f55b679b775850836f321b78273ca573


So based on the error message (at the end):

2) No implementation for org.eclipse.aether.impl.VersionRangeResolver  
was bound.

   while locating org.eclipse.aether.impl.VersionRangeResolver

It looks like it's missing an implementation for  
VersionRangeResolver...which is part of


   
   org.eclipse.aether
   aether-impl
   0.9.0.M2
   provided
 

So it should mean that I need to change from provided to test  
scope...but this does not help here...the error message keeps the same...



Maybe someone of you have a hint an idea ?


Kind regards
Karl Heinz Marbaise


On 24/09/16 18:27, Robert Scholte wrote:

On Sat, 24 Sep 2016 11:15:41 +0200, Karl Heinz Marbaise
 wrote:


Hi,

So I'm trying to write more tests on the component...in particular for
the new parts like ProjectInstaller etc. I started with
ProjectInstaller...(Created gist for that:
https://gist.github.com/khmarbaise/1ed421983480e3fef624bf6c8f4844b6).

If I try to run that I'm getting always errors like this:


testShouldInstallSingleArtifact(org.apache.maven.shared.project.install.ProjectInstallerTest)
  Time elapsed: 0.134 sec  <<< ERROR!
org.codehaus.plexus.component.repository.exception.ComponentLookupException:

com.google.inject.ProvisionException: Guice provision errors:

1) Error injecting:
org.apache.maven.shared.artifact.install.internal.Maven31ArtifactInstaller

   at ClassRealm[plexus.core, parent: null]
   at ClassRealm[plexus.core, parent: null]
   while locating
org.apache.maven.shared.artifact.install.ArtifactInstaller annotated
with @com.google.inject.name.Named(value=maven31)

1 error
   role: org.apache.maven.shared.artifact.install.ArtifactInstaller
   roleHint: maven31
at
org.apache.maven.shared.project.install.ProjectInstallerTest.setUp(ProjectInstallerTest.java:46)

Caused by: com.google.inject.ProvisionException:
Guice provision errors:

I had expected that the ArtifactInstaller will be selected
automatically based on the running Maven version (3.3.9)...


No, it is just a JUnit-test like any other. The version of the Maven
dependencies are those specified in the pom.xml. Only when using the
Maven runtime, these dependencies are stripped out and the runtime
versions are used (Plexus Classworld).

Robert



maybe someone has an idea/tip/hint what I'm doing wrong...



-
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 pull request #125: Consistently rename JUnit 4.x integration ...

[britter]

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

https://github.com/apache/maven-surefire/pull/125#discussion_r82520806
  
--- Diff: 
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/JUnit47ConcurrencyIT.java
 ---
@@ -32,14 +32,14 @@
  *
  * @author Kristian Rosenvold
  */
-public class Junit47concurrencyIT
--- End diff --

@Tibor17 you don't like this change?


---
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 #124: Fix formatting, convert tabs to spaces

[britter]

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/124
  
@Tibor17 easy fix, how about merging it? ;-)


---
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

Maven 3.4.0 Release

[Karl Heinz Marbaise]

Hi to all,

I would like to know what prevents us currently from releasing Maven 3.4.0 ?

Kind regards
Karl Heinz Marbaise

-
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

[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. 

> On Oct 9, 2016, at 6:58 AM, Karl Heinz Marbaise  wrote:
> 
> Hi to all,
> 
> I would like to know what prevents us currently from releasing Maven 3.4.0 ?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



-
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

[Karl Heinz Marbaise]

Hi Jason,


On 09/10/16 14:10, Jason van Zyl wrote:

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.

yes the release notes I see as a real requirement...

which I started a longer time ago...which needs to be updated of course...

https://github.com/khmarbaise/maven-release-notes/blob/master/content/markdown/docs/3.4.0/release-notes.md

Kind regards
Karl Heinz Marbaise





On Oct 9, 2016, at 6:58 AM, Karl Heinz Marbaise  wrote:

Hi to all,

I would like to know what prevents us currently from releasing Maven 3.4.0 ?

Kind regards
Karl Heinz Marbaise

-
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

[SUREFIRE] Jenkins job for junit5 branch

[Benedikt Ritter]

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/

[Jigsaw] First working prototype of maven-jlink-plugin / maven-jmod-plugin

[Karl Heinz Marbaise]

Hi,

I have created the plugins maven-jlink-plugin / maven-jmod-plugin as a 
first prototype (Just to see how / and if it works). Also I have created 
a working example to use them:


https://github.com/khmarbaise/jdk9-jlink-jmod-example/tree/master/maven-example

This has been tested with JDK 9+138 EA Build...

Kind regards
Karl Heinz Marbaise

-
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]

Did we revert the modelVersion bump?

On Sunday 9 October 2016, Karl Heinz Marbaise  wrote:

> Hi Jason,
>
>
> On 09/10/16 14:10, Jason van Zyl wrote:
>
>> 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.
>
> yes the release notes I see as a real requirement...
>
> which I started a longer time ago...which needs to be updated of course...
>
> https://github.com/khmarbaise/maven-release-notes/blob/maste
> r/content/markdown/docs/3.4.0/release-notes.md
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>> On Oct 9, 2016, at 6:58 AM, Karl Heinz Marbaise 
>>> wrote:
>>>
>>> Hi to all,
>>>
>>> I would like to know what prevents us currently from releasing Maven
>>> 3.4.0 ?
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> -
>>> 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
>
>

-- 
Sent from my phone

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

[Benedikt Ritter]

Hello Tibor,

I think I understand what you're thinking of. I'll give it a try and see if
I can come up with something useful :-)

Regards,
Benedikt

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

> Instead of using  in Surefire (may affect the
> ITs), there is a better trick.
> See the POM surefire-junit47.
> You will see the section of compiler endorsed classpath but Surefire has
> different one:
>
>
>
> 
>   maven-dependency-plugin
>   
> 
>   main
>   process-sources
>   
> copy
>   
>   
>
> ${project.build.directory}/endorsed
> false
> true
> 
>   
> junit
> junit
> 4.7
> jar
>   
> 
>   
> 
> 
>   test
>   process-sources
>   
> copy
>   
>   
>
> ${project.build.directory}/endorsed-test
> false
> true
> 
>   
> junit
> junit
> 4.12
> jar
>   
> 
>   
> 
>   
> 
> 
>   maven-compiler-plugin
>   
> 
>   ${project.build.directory}/endorsed
> 
> 
>   ${project.build.directory}/endorsed-test
> 
>   
> 
>
>
>
>
>
> On Tue, Oct 4, 2016 at 7:47 PM, Benedikt Ritter 
> wrote:
>
> > Hello Tibor,
> >
> > Tibor Digana  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 
> > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Tibor
> > >
> >
>
>
>
> --
> Cheers
> Tibor
>

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

[Guillaume Boué]

If the caller needs to force a different local repository than the one 
in the Maven session, they can already call 
"repositoryManager.setLocalRepositoryBasedir" on the building request 
that is passed to ProjectInstaller. This is what the plugins using 
ArtifactInstaller are already doing, and it would be simpler than 
creating a whole new MavenArtifactRepository and passing that. Maybe 
this ArtifactRepository parameter could even be removed?


For now, its current use by the ProjectInstaller is only to get the path 
to the metadata to install checksums for them, and this is only needed 
because there is no "getPathForLocalMetadata" on the RepositoryManager. 
How about adding this method, that would delegate to proper 
implementation classes for Maven 3.1 or 3.0?



Le 09/10/2016 à 11:31, Karl Heinz Marbaise a écrit :

Hi,

Yes it has been introduced by me...and yes not all plugins are using 
it cause I would like to have some tests before spreading it to the 
"world" of plugins..


Kind regards
Karl Heinz


On 09/10/16 11:07, Robert Scholte wrote:

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it
hasn't been pushed to all plugins which should use it instead of the
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several
plugins I just hit these edge cases where the local repo is not always
the target repo.

Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué 
wrote:


Hi,

 From what I checked, I don't think those plugins should be impacted
since they use the ArtifactInstaller directly, and not the
ProjectInstaller.

But I can add an overload taking an ArtifactRepository which would get
the path to the artifact with "artifactRepository.pathOf(artifact)".
And then go with the one using the RepositoryManager or not, depending
on whether the ArtifactRepository is null or not.

Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create
their own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.

thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200,  wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929&view=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager

We need to rely on the RepositoryManager to get a hold of the local
repository base directory.

Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 




Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 



URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929&r1=1763928&r2=1763929&view=diff 



== 


---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 


(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 


Sat Oct  8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project )
) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 }
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
 if ( file != null && file.isFile() )
 {
 installer.install( buildingRequest,
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 else if ( !attachedArtifacts.isEmpty() )
@@ -139,7 +139,7 @@ public class DefaultProjectInstaller
 for ( Artifact attached : attachedArtifacts )
 {
 installer.install( buildingRequest,
Collections.singletonList( attached ) );
-installChecksums( buildingRequest, artifactRepository,
attached, createChecksum );
+

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

[Karl Heinz Marbaise]

Hi Buillaume,

On 09/10/16 14:28, Guillaume Boué wrote:

If the caller needs to force a different local repository than the one
in the Maven session, they can already call
"repositoryManager.setLocalRepositoryBasedir" on the building request
that is passed to ProjectInstaller. This is what the plugins using
ArtifactInstaller are already doing, and it would be simpler than
creating a whole new MavenArtifactRepository and passing that. Maybe
this ArtifactRepository parameter could even be removed?

For now, its current use by the ProjectInstaller is only to get the path
to the metadata to install checksums for them, and this is only needed
because there is no "getPathForLocalMetadata" on the RepositoryManager.
How about adding this method, that would delegate to proper
implementation classes for Maven 3.1 or 3.0?


Sounds better and cleaner...


Kind regards
Karl Heinz





Le 09/10/2016 à 11:31, Karl Heinz Marbaise a écrit :

Hi,

Yes it has been introduced by me...and yes not all plugins are using
it cause I would like to have some tests before spreading it to the
"world" of plugins..

Kind regards
Karl Heinz


On 09/10/16 11:07, Robert Scholte wrote:

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it
hasn't been pushed to all plugins which should use it instead of the
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several
plugins I just hit these edge cases where the local repo is not always
the target repo.

Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué 
wrote:


Hi,

 From what I checked, I don't think those plugins should be impacted
since they use the ArtifactInstaller directly, and not the
ProjectInstaller.

But I can add an overload taking an ArtifactRepository which would get
the path to the artifact with "artifactRepository.pathOf(artifact)".
And then go with the one using the RepositoryManager or not, depending
on whether the ArtifactRepository is null or not.

Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create
their own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.

thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200,  wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929&view=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager

We need to rely on the RepositoryManager to get a hold of the local
repository base directory.

Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java



Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java


URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929&r1=1763928&r2=1763929&view=diff


==

---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

Sat Oct  8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project )
) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 }
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
 if ( file != null && file.isFile() )
 {
 installer.install( buildingRequest,
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 else if ( !attachedArtifacts.isEmpty() )
@@ -139,7 +139,7 @@ public class DefaultProjectInstaller
 for ( Artifact attached : attachedArtifacts )
 {
 installer.install( buildingRequest,
Collections.singletonList( attached ) );
-insta

Re: [Jigsaw] First working prototype of maven-jlink-plugin / maven-jmod-plugin

[Robert Scholte]

Nice, will have a look at it soon.

On Sun, 09 Oct 2016 14:17:18 +0200, Karl Heinz Marbaise  
 wrote:



Hi,

I have created the plugins maven-jlink-plugin / maven-jmod-plugin as a  
first prototype (Just to see how / and if it works). Also I have created  
a working example to use them:


https://github.com/khmarbaise/jdk9-jlink-jmod-example/tree/master/maven-example

This has been tested with JDK 9+138 EA Build...

Kind regards
Karl Heinz Marbaise

-
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: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

[Guillaume Boué]

The only quirk is that 
org.apache.maven.artifact.metadata.ArtifactMetadata is deprecated... so 
this would add usage of the deprecated interface in RepositoryManager. 
What is the alternative for this?



Le 09/10/2016 à 14:36, Karl Heinz Marbaise a écrit :

Hi Buillaume,

On 09/10/16 14:28, Guillaume Boué wrote:

If the caller needs to force a different local repository than the one
in the Maven session, they can already call
"repositoryManager.setLocalRepositoryBasedir" on the building request
that is passed to ProjectInstaller. This is what the plugins using
ArtifactInstaller are already doing, and it would be simpler than
creating a whole new MavenArtifactRepository and passing that. Maybe
this ArtifactRepository parameter could even be removed?

For now, its current use by the ProjectInstaller is only to get the path
to the metadata to install checksums for them, and this is only needed
because there is no "getPathForLocalMetadata" on the RepositoryManager.
How about adding this method, that would delegate to proper
implementation classes for Maven 3.1 or 3.0?


Sounds better and cleaner...


Kind regards
Karl Heinz





Le 09/10/2016 à 11:31, Karl Heinz Marbaise a écrit :

Hi,

Yes it has been introduced by me...and yes not all plugins are using
it cause I would like to have some tests before spreading it to the
"world" of plugins..

Kind regards
Karl Heinz


On 09/10/16 11:07, Robert Scholte wrote:

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it
hasn't been pushed to all plugins which should use it instead of the
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several
plugins I just hit these edge cases where the local repo is not always
the target repo.

Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué 
wrote:


Hi,

 From what I checked, I don't think those plugins should be impacted
since they use the ArtifactInstaller directly, and not the
ProjectInstaller.

But I can add an overload taking an ArtifactRepository which would 
get

the path to the artifact with "artifactRepository.pathOf(artifact)".
And then go with the one using the RepositoryManager or not, 
depending

on whether the ArtifactRepository is null or not.

Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create
their own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.

thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200,  wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929&view=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager

We need to rely on the RepositoryManager to get a hold of the local
repository base directory.

Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 





Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 




URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929&r1=1763928&r2=1763929&view=diff 




== 



---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 



(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 



Sat Oct  8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project )
) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 }
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
 if ( file != null && file.isFile() )
 {
 installer.install( buildingRequest,
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

[Karl Heinz Marbaise]

Hi Guillaume,

This is already used in other locations of the maven-artifact-transfer...

Maven30ArtifactRepositoryAdapter, Maven31ArtifactRepositoryAdapter, 
Maven30ArtifactDeployer, Maven31ArtifactDeployer...only to mention a few...


org.apache.maven.repository.legacy.metadata.ArtifactMetadata is not 
deprecated and the interface



public interface ArtifactMetadata
extends org.apache.maven.repository.legacy.metadata.ArtifactMetadata
{
void merge( ArtifactMetadata metadata );
}

So the question is simply if we need the merge method? But I'm not sure 
if we should go to legacy area here?


Someone who has a better suggestion/alternatives?


Kind regards
Karl Heinz


On 09/10/16 14:54, Guillaume Boué wrote:

The only quirk is that
org.apache.maven.artifact.metadata.ArtifactMetadata is deprecated... so
this would add usage of the deprecated interface in RepositoryManager.
What is the alternative for this?


Le 09/10/2016 à 14:36, Karl Heinz Marbaise a écrit :

Hi Buillaume,

On 09/10/16 14:28, Guillaume Boué wrote:

If the caller needs to force a different local repository than the one
in the Maven session, they can already call
"repositoryManager.setLocalRepositoryBasedir" on the building request
that is passed to ProjectInstaller. This is what the plugins using
ArtifactInstaller are already doing, and it would be simpler than
creating a whole new MavenArtifactRepository and passing that. Maybe
this ArtifactRepository parameter could even be removed?

For now, its current use by the ProjectInstaller is only to get the path
to the metadata to install checksums for them, and this is only needed
because there is no "getPathForLocalMetadata" on the RepositoryManager.
How about adding this method, that would delegate to proper
implementation classes for Maven 3.1 or 3.0?


Sounds better and cleaner...


Kind regards
Karl Heinz





Le 09/10/2016 à 11:31, Karl Heinz Marbaise a écrit :

Hi,

Yes it has been introduced by me...and yes not all plugins are using
it cause I would like to have some tests before spreading it to the
"world" of plugins..

Kind regards
Karl Heinz


On 09/10/16 11:07, Robert Scholte wrote:

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it
hasn't been pushed to all plugins which should use it instead of the
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several
plugins I just hit these edge cases where the local repo is not always
the target repo.

Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué 
wrote:


Hi,

 From what I checked, I don't think those plugins should be impacted
since they use the ArtifactInstaller directly, and not the
ProjectInstaller.

But I can add an overload taking an ArtifactRepository which would
get
the path to the artifact with "artifactRepository.pathOf(artifact)".
And then go with the one using the RepositoryManager or not,
depending
on whether the ArtifactRepository is null or not.

Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create
their own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.

thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200,  wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929&view=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager

We need to rely on the RepositoryManager to get a hold of the local
repository base directory.

Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java




Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java



URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929&r1=1763928&r2=1763929&view=diff



==


---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java


(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java


Sat Oct  8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project )
) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksu

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

[Benedikt Ritter]

Hello Tibor,

I've played around a bit with the idea and I think there is a problem:

If you want to compile and run test using JUnit 4 annotations using JUnit
5, you need the vintage enigne in your dependencies. Otherwise you get
compile errors, because neither jupiter engine nor jupiter api ship the old
annotations. So I end up with a dependency declaration like this:


  
org.junit.jupiter
junit-jupiter-engine
${junit.jupiter.version}
test
  
  
  
org.junit.vintage
junit-vintage-engine
${junit.vintage.version}
test
  



This will cause JUnit 5 to execute everything on the vintage engine. If we
want to share test code across JUnit versions, I need to also add the
jupiter API annotations to the test code. But I still need the vintage
engine in order to get it to compile.
Now I have a test like:

public class MixedTest
{

  @org.junit.Test
  @org.junit.api.jupiter.Test
  public test()
  {
// do something
  }

}

Which engine will execute the test? No one knows... So I don't think it's a
good idea to share test classes.

Regards,
Benedikt

Benedikt Ritter  schrieb am So., 9. Okt. 2016 um
14:25 Uhr:

> Hello Tibor,
>
> I think I understand what you're thinking of. I'll give it a try and see
> if I can come up with something useful :-)
>
> Regards,
> Benedikt
>
>
> Tibor Digana  schrieb am Mi., 5. Okt. 2016
> um 00:18 Uhr:
>
> Instead of using  in Surefire (may affect the
> ITs), there is a better trick.
> See the POM surefire-junit47.
> You will see the section of compiler endorsed classpath but Surefire has
> different one:
>
>
>
> 
>   maven-dependency-plugin
>   
> 
>   main
>   process-sources
>   
> copy
>   
>   
>
> ${project.build.directory}/endorsed
> false
> true
> 
>   
> junit
> junit
> 4.7
> jar
>   
> 
>   
> 
> 
>   test
>   process-sources
>   
> copy
>   
>   
>
> ${project.build.directory}/endorsed-test
> false
> true
> 
>   
> junit
> junit
> 4.12
> jar
>   
> 
>   
> 
>   
> 
> 
>   maven-compiler-plugin
>   
> 
>   ${project.build.directory}/endorsed
> 
> 
>   ${project.build.directory}/endorsed-test
> 
>   
> 
>
>
>
>
>
> On Tue, Oct 4, 2016 at 7:47 PM, Benedikt Ritter 
> wrote:
>
> > Hello Tibor,
> >
> > Tibor Digana  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 
> > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Tibor
> > >
> >
>
>
>
> --
> Cheers
> Tibor
>
>

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

[britter]

GitHub user britter opened a pull request:

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

Make Junit4VersionsIT parameterized

In preparation for introducing more JUnit 5 ITs, make the Junit4VersionsIT 
parameterized.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/britter/maven-surefire junit4-versions

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/126.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #126


commit e619e7ff44990142a6b61367cebc95908a1ddf91
Author: Benedikt Ritter 
Date:   2016-10-09T13:38:44Z

Make Junit4VersionsIT a parameterized test

commit fa086e0853b9729725690694875114440ad8890a
Author: Benedikt Ritter 
Date:   2016-10-09T13:40:55Z

Add missing JUnit 4 versions to Junit4VersionsIT




---
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 opened a pull request:

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

[SUREFIRE 1293] Simplify 
org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null 
object pattern

Added null object implementations for fields used by TestSetRunListener in 
order to simplify TestSetRunListener code.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/britter/maven-surefire SUREFIRE-1293

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/127.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #127


commit fa5f480fbe02dbd401b98ca39b56a9a0db930f48
Author: Benedikt Ritter 
Date:   2016-10-09T14:41:49Z

Introduce NullConsoleReporter to simplify TesSetRunListener

commit a811fb618b4382feff6ee991d253c816f62e7d94
Author: Benedikt Ritter 
Date:   2016-10-09T14:47:31Z

Introduce NullFileReporter to simplify TesSetRunListener

commit d419b7be567546fe615bdcd770fe03229c141ca2
Author: Benedikt Ritter 
Date:   2016-10-09T14:53:34Z

Introduce NullStatisticsReporter to simplify TesSetRunListener

commit e56269cfce8b626e0e2667982891068251beedf6
Author: Benedikt Ritter 
Date:   2016-10-09T14:57:16Z

Introduce NullStatelessXmlReporter to simplify TesSetRunListener

commit 42dd834e098c3bbf8f103db52fb3edc125cd7276
Author: Benedikt Ritter 
Date:   2016-10-09T15:00:39Z

Introduce NullConsoleOutputReceiver to simplify TesSetRunListener

commit cbf8e0948a76f82e3ef7c124e21b2edb9b96f636
Author: Benedikt Ritter 
Date:   2016-10-09T15:07:38Z

Make sure all the Null object classes can be instantiated




---
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 issue #94: MNG-5889 - adding logic that looks for the file argument an...

[rpatrick00]

Github user rpatrick00 commented on the issue:

https://github.com/apache/maven/pull/94
  
OK, I found and resolved the problem with the --file arg but am not seeing 
the other problem you describe (see output below).  Maybe my fix for the --file 
arg resolved that one too?  

Here is a stupid little test project that I am using:

[maven-test.zip](https://github.com/apache/maven/files/518411/maven-test.zip)

In the root directory of the project, there is a git.diff file that shows 
the changes I made to the pull request code.  I am happy to resubmit the pull 
request with this change but would prefer to verify that it fixes the issues in 
your Windows environment first.

If you run with JDK 8, you will see the warning about ignoring 
MaxPermSize=128m, which is set in jvm.config:

D:\temp>mvn --file maven-test\pom.xml verify
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option 
MaxPermSize=128m; support was removed in 8.0
[INFO] Scanning for projects...
[INFO]
[INFO] 

[INFO] Building maven-config-test 1.0-SNAPSHOT
[INFO] 

[INFO]
[INFO] --- echo-maven-plugin:0.3.0:echo (default) @ maven-config-test ---
[INFO]
[INFO]
[INFO]
[INFO]
[INFO] myproperty = from.maven.config
[INFO]
[INFO]
[INFO]
[INFO]
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 0.587 s
[INFO] Finished at: 2016-10-09T11:20:56-05:00
[INFO] Final Memory: 17M/491M
[INFO] 





---
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_r82527079
  
--- 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. Therefor 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.
This would mean that such null-check may be embedded in the factory, e.g. 
`buildConsoleReporter()`. I would say that the caller should pass non-null 
consistent object into this class `TestSetRunListener` via constructor and the 
called class should not make any guess about it (means if == null => guess hide 
the error). If we accepted such paradigm then all such occurrences in this PR 
would have to change it.


---
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 issue #94: MNG-5889 - adding logic that looks for the file argument an...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven/pull/94
  
Don't create a new PR. Just amend the last commit `git commit --amend` and 
push it again.


---
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

[Michael Osipov]

Am 2016-10-09 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.


More than that. We have changed so much stuff in a minor (!) release -- 
too much for my taste -- that I would rather expect a release candidate 
for that.


I completely miss documentation on Gossip.

Michael


-
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]

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)
* Document how to configure Gossip
  https://issues.apache.org/jira/browse/MNG-6044
  assignee: - (reporter: Michael Osipov)
* Document Jansi's native support limitation
  https://issues.apache.org/jira/browse/MNG-6045
  assignee: - (reporter: Michael Osipov)
* after forked execution success, add an empty line
  https://issues.apache.org/jira/browse/MNG-6088
  assignee: Hervé Boutemy (reporter: Hervé Boutemy)
* Introduce maven.conf in m2.conf
  https://issues.apache.org/jira/browse/MNG-6102
  assignee: Michael Osipov (reporter: Michael Osipov)

Assignees and reporter are all Maven teammembers, so they should all be  
able to either fix it or push it to a next version.


My biggest concerns are about the changed behavior of dependency  
resolution regarding dependency management which will break backwards  
compatibility:


* Imported dependencies should be available to inheritance processing
  https://issues.apache.org/jira/browse/MNG-5971
  Based on the comment there are projects which will break due to this  
change.


* Increase the model validation level to the next minor level version.
  https://issues.apache.org/jira/browse/MNG-6075
  Jira issue is missing an explicit list of the changes and a link the the  
revision.


* Make 'optional' flag of a dependency manageable.
  https://issues.apache.org/jira/browse/MNG-5227

There are more changes done, but from what I can see those should be safe.
IMHO these changes have too much impact for a 3.4 and I think we can fix  
them with the introduction of the PDT file.


We should indeed start with release candidates and set a date until we  
expect feedback (e.g +15 days). Any negative response should be  
investigated and if it is valid it should be fixed and the release  
candidate process should starts over again asap. This way we should be  
able to push a new solid version out this year.


thanks,
Robert


On Sun, 09 Oct 2016 13:58:29 +0200, Karl Heinz Marbaise  
 wrote:



Hi to all,

I would like to know what prevents us currently from releasing Maven  
3.4.0 ?


Kind regards
Karl Heinz Marbaise

-
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 issue #94: MNG-5889 - adding logic that looks for the file argument an...

[rpatrick00]

Github user rpatrick00 commented on the issue:

https://github.com/apache/maven/pull/94
  
Pushed


---
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

[Michael Osipov]

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. Moreover, the Gossip 
configuration is actually embedded in the one JAR file of Maven. Not 
very handy when we agreed to use ${maven.conf}/logging for that.



* Document Jansi's native support limitation
  https://issues.apache.org/jira/browse/MNG-6045
  assignee: - (reporter: Michael Osipov)


Funny thing is that I have reached out to the devs of Jansi to fix some 
issues like have a default support for FreeBSD, even after several 
pings, no reaction.


I am not willing to give people support for our stuff when third party 
components we use have issues and the authors of it do not react within 
months. [1], [2]


[1] https://github.com/fusesource/jansi-native/issues/5
[2] https://github.com/fusesource/jansi/issues/56

Michael


-
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 Sunday 9 October 2016, Robert Scholte  wrote:

> 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.


> * Document how to configure Gossip
>   https://issues.apache.org/jira/browse/MNG-6044
>   assignee: - (reporter: Michael Osipov)
> * Document Jansi's native support limitation
>   https://issues.apache.org/jira/browse/MNG-6045
>   assignee: - (reporter: Michael Osipov)
> * after forked execution success, add an empty line
>   https://issues.apache.org/jira/browse/MNG-6088
>   assignee: Hervé Boutemy (reporter: Hervé Boutemy)
> * Introduce maven.conf in m2.conf
>   https://issues.apache.org/jira/browse/MNG-6102
>   assignee: Michael Osipov (reporter: Michael Osipov)
>
> Assignees and reporter are all Maven teammembers, so they should all be
> able to either fix it or push it to a next version.
>
> My biggest concerns are about the changed behavior of dependency
> resolution regarding dependency management which will break backwards
> compatibility:
>
> * Imported dependencies should be available to inheritance processing
>   https://issues.apache.org/jira/browse/MNG-5971
>   Based on the comment there are projects which will break due to this
> change.
>
> * Increase the model validation level to the next minor level version.
>   https://issues.apache.org/jira/browse/MNG-6075
>   Jira issue is missing an explicit list of the changes and a link the the
> revision.
>
> * Make 'optional' flag of a dependency manageable.
>   https://issues.apache.org/jira/browse/MNG-5227
>
> There are more changes done, but from what I can see those should be safe.
> IMHO these changes have too much impact for a 3.4 and I think we can fix
> them with the introduction of the PDT file.
>
> We should indeed start with release candidates and set a date until we
> expect feedback (e.g +15 days). Any negative response should be
> investigated and if it is valid it should be fixed and the release
> candidate process should starts over again asap. This way we should be able
> to push a new solid version out this year.
>
> thanks,
> Robert
>
>
> On Sun, 09 Oct 2016 13:58:29 +0200, Karl Heinz Marbaise 
> wrote:
>
> Hi to all,
>>
>> I would like to know what prevents us currently from releasing Maven
>> 3.4.0 ?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> 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
>
>

-- 
Sent from my phone

Re: Maven 3.4.0 Release

[Jason van Zyl]

I believe we definitely need RCs in this case. 

> On Oct 9, 2016, at 1:17 PM, Michael Osipov  wrote:
> 
> Am 2016-10-09 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.
> 
> More than that. We have changed so much stuff in a minor (!) release -- too 
> much for my taste -- that I would rather expect a release candidate for that.
> 
> I completely miss documentation on Gossip.
> 
> Michael
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



-
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 dimanche 9 octobre 2016 20:41:13 Robert Scholte a écrit :
> Open issues bound to 3.4.0
> 
> * after forked execution success, add an empty line
>https://issues.apache.org/jira/browse/MNG-6088
>assignee: Hervé Boutemy (reporter: Hervé Boutemy)
I just closed this issue, which I had already fixed


-
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 dimanche 9 octobre 2016 21:11:03 Michael Osipov a écrit :
> > * Document Jansi's native support limitation
> > 
> >   https://issues.apache.org/jira/browse/MNG-6045
> >   assignee: - (reporter: Michael Osipov)
> 
> Funny thing is that I have reached out to the devs of Jansi to fix some
> issues like have a default support for FreeBSD, even after several
> pings, no reaction.
> 
> I am not willing to give people support for our stuff when third party
> components we use have issues and the authors of it do not react within
> months. [1], [2]
> 
> [1] https://github.com/fusesource/jansi-native/issues/5
> [2] https://github.com/fusesource/jansi/issues/56
at the beginning, under FreeBSD (or any other OS without native lib, like 
Solaris or AIX), JAnsi simply made the Maven run blow up: our patch was 
integrated [3]

Now, on an Unix without native lib, not having a native lib does not make ANSI 
color failure: it just doesn't give isatty() function to try to detect stdout 
redirection, which even when available does not detect well when redirection 
are used.

Yes, from a pure logical perspective, have more native libs would be a plus. 
But this is not so critical.
Yes, JAnsi maintainers don't apply every PR immediately and it's sometime hard 
to get their attention: hey, that reminds me some recent complaints on our ML.

JAnsi works well currently for Maven and for a lot of others: if you find a 
better alternative, don't hesitate to point us to it.

Regards,

Hervé


[3] https://github.com/fusesource/jansi/pull/54


> 
> 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: Maven 3.4.0 Release

[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

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?

> Moreover, the Gossip
> configuration is actually embedded in the one JAR file of Maven. Not
> very handy when we agreed to use ${maven.conf}/logging for that.
+1 need to do something about that

Regards,

Hervé

-
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

[Michael Osipov]

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?


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.


Michael


-
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

[Christian Schulte]

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.

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

[Christian Schulte]

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.

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

[Tibor Digana]

I would add MNG-5889 to 3.4 after proper testing.

On Sun, Oct 9, 2016 at 8:41 PM, Robert Scholte  wrote:

> 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)
> * Document how to configure Gossip
>   https://issues.apache.org/jira/browse/MNG-6044
>   assignee: - (reporter: Michael Osipov)
> * Document Jansi's native support limitation
>   https://issues.apache.org/jira/browse/MNG-6045
>   assignee: - (reporter: Michael Osipov)
> * after forked execution success, add an empty line
>   https://issues.apache.org/jira/browse/MNG-6088
>   assignee: Hervé Boutemy (reporter: Hervé Boutemy)
> * Introduce maven.conf in m2.conf
>   https://issues.apache.org/jira/browse/MNG-6102
>   assignee: Michael Osipov (reporter: Michael Osipov)
>
> Assignees and reporter are all Maven teammembers, so they should all be
> able to either fix it or push it to a next version.
>
> My biggest concerns are about the changed behavior of dependency
> resolution regarding dependency management which will break backwards
> compatibility:
>
> * Imported dependencies should be available to inheritance processing
>   https://issues.apache.org/jira/browse/MNG-5971
>   Based on the comment there are projects which will break due to this
> change.
>
> * Increase the model validation level to the next minor level version.
>   https://issues.apache.org/jira/browse/MNG-6075
>   Jira issue is missing an explicit list of the changes and a link the the
> revision.
>
> * Make 'optional' flag of a dependency manageable.
>   https://issues.apache.org/jira/browse/MNG-5227
>
> There are more changes done, but from what I can see those should be safe.
> IMHO these changes have too much impact for a 3.4 and I think we can fix
> them with the introduction of the PDT file.
>
> We should indeed start with release candidates and set a date until we
> expect feedback (e.g +15 days). Any negative response should be
> investigated and if it is valid it should be fixed and the release
> candidate process should starts over again asap. This way we should be able
> to push a new solid version out this year.
>
> thanks,
> Robert
>
>
>
> On Sun, 09 Oct 2016 13:58:29 +0200, Karl Heinz Marbaise 
> wrote:
>
> Hi to all,
>>
>> I would like to know what prevents us currently from releasing Maven
>> 3.4.0 ?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> 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
>
>


-- 
Cheers
Tibor

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.

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: 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