[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314284534
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   There's also `server.getURI().getPort()` as a valid option here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314284936
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java
 ##
 @@ -86,18 +93,13 @@ protected void setUp()
 handlerList.addHandler( repoHandler );
 handlerList.addHandler( new DefaultHandler() );
 
-server = new Server( 0 );
 server.setHandler( handlerList );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 
 Review comment:
   Server could have successfully started up, and then be successfully stopped, 
before this line hits.
   In this scenario, the server LifeCycle state is STOPPED, not FAILED.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314288543
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2305MultipleProxiesTest.java
 ##
 @@ -71,20 +78,16 @@ public void testit()
 String keyPwd = "key-passwd";
 
 Server server = new Server( 0 );
-server.addConnector( newHttpsConnector( storePath, storePwd, keyPwd ) 
);
+addHttpsConnector( server, storePath, storePwd, keyPwd );
 server.setHandler( new RepoHandler() );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-int httpPort = server.getConnectors()[0].getLocalPort();
+int httpPort = ( (NetworkConnector) server.getConnectors()[0] 
).getLocalPort();
 System.out.println( "Bound server socket to HTTP port " + httpPort );
-int httpsPort = server.getConnectors()[1].getLocalPort();
+int httpsPort = ( (NetworkConnector) server.getConnectors()[1] 
).getLocalPort();
 
 Review comment:
   The `HttpConfiguration` belonging to Connector[0] needs to have its 
`HttpConfiguration.setSecurePort(int)` set for the port that this HTTPS 
connector.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] wilkinsona commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
wilkinsona commented on issue #243: [SUREFIRE-1679] Prevent classpath caching 
from causing pollution
URL: https://github.com/apache/maven-surefire/pull/243#issuecomment-521577398
 
 
   My pleasure. Thanks for the review and merge. I'd like to work on an 
equivalent 2.22.x fix now. What branch should I use as the base for that?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314284271
 
 

 ##
 File path: core-it-suite/src/test/java/org/apache/maven/it/HttpServer.java
 ##
 @@ -66,21 +68,20 @@ public void stop()
 
 public int port()
 {
-return ( (ServerConnector) server.getConnectors()[0] ).getLocalPort();
+return ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 }
 
 private Server server( int port )
 {
-
 QueuedThreadPool threadPool = new QueuedThreadPool();
 threadPool.setMaxThreads( 500 );
 Server server = new Server( threadPool );
+server.setConnectors( new Connector[]{ new ServerConnector( server ) } 
);
 server.addBean( new ScheduledExecutorScheduler() );
 
-ServerConnector http = new ServerConnector( server );
-http.setPort( port );
-http.setIdleTimeout( 3 );
-server.addConnector( http );
+ServerConnector connector = (ServerConnector) 
server.getConnectors()[0];
+connector.setIdleTimeout( 30_000L );
+connector.setPort( port );
 
 Review comment:
   Why not just do this instead ?
   
   ``` java
   ServerConnector connector = new ServerConnector( server );
   connector.setIdleTimeout( 30_000L );
   connector.setPort( port );
   server.addConnector( connector );
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314301663
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java
 ##
 @@ -86,18 +93,13 @@ protected void setUp()
 handlerList.addHandler( repoHandler );
 handlerList.addHandler( new DefaultHandler() );
 
-server = new Server( 0 );
 server.setHandler( handlerList );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 
 Review comment:
   That is the generic `start()` for `AbstractLifeCycle`.
   `Server` is a `ContainerLifeCycle` and a special one at that.
   It's `Server.doStart()` has to do far more then this abstract base behavior 
simply because it's a combination of a Container (with child lifecycles) and 
it's the main entry point for external that care about the LifeCycle state.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314301738
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   I did not want to make the code too much different from what we had before.I 
was glad that the version 9.0.4 works. After I changed the version to 9.2.28 I 
got HTTP 405 and really did not want to get new arguments from the devs saying 
that there is something which broke new version.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314287943
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0768OfflineModeTest.java
 ##
 @@ -103,17 +103,12 @@ else if ( request.getRequestURI().endsWith( ".md5" ) || 
request.getRequestURI().
 try
 {
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 
 Review comment:
   This line is not possible to reach immediately after `server.start()` in a 
Bind failure scenario.
   
   The ServerConnector's doStart will attempt to bind
   The BindException gets thrown for failure to bind
   A IOException wraps failure to bind during ServerConnector doStart
   The Server doStart captures the IOException and adds it to the 
MultiException its tracking
   At the end of Server doStart the MultiException throws if it has any 
exceptions its tracking.
   
   This scenario should result in a IOException or MultiException from 
server.start()
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314302888
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   So I would make a new commit as an improvement of this line.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath 
caching from causing pollution
URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786
 
 
   it's okay in version 2.x since these tests must be older and different from 
3.x. The reason why there is File mock is to simplify the Captures of debug 
logger because there is no physicla path and no troubles with platform and long 
lines in code. Also it is a signal for us to fail the test if the logic in 
`AbstractSurefireMojo` would change in the future when the logic would need to 
have a real paths and real reads/writes. Till that it is just in memory.
   
   These tests in `AbstractSurefireMojoTest.java` do not have too much 
assertion statements. They have more Captures and verifications. And the reason 
is that the class `AbstractSurefireMojo` was not developed with tests. 
Basically there was no TDD in this class development. If there was, I am sure 
there could be much more assertions on returned values and less mocking of 
internal state and captures. This happens when TDD is not applied in the 
begining. Positive remark is that these tests improve the coverage and give us 
some feedback when the code is changed together with the experiences of the 
`AbstractSurefireMojo`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314287943
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0768OfflineModeTest.java
 ##
 @@ -103,17 +103,12 @@ else if ( request.getRequestURI().endsWith( ".md5" ) || 
request.getRequestURI().
 try
 {
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 
 Review comment:
   This state is not possible to reach immediately after `server.start()` in a 
Bind failure scenario.
   
   The ServerConnector's doStart will attempt to bind
   The BindException gets thrown for failure to bind
   A IOException wraps failure to bind during ServerConnector doStart
   The Server doStart captures the IOException and adds it to the 
MultiException its tracking
   At the end of Server doStart the MultiException throws if it has any 
exceptions its tracking.
   
   This scenario should result in a IOException or MultiException from 
server.start()
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314302466
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   We can improve as always but I spent 3 days with these 38 tests and for me 
it is always good to have several smaller changes than one big change. With 
small changes/commits we can always test older commits if we find some issue.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314302466
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   We can improve as always but I spent 3 days with these 38 tests and for me 
it is always good to have several smaller changes than one big change. With 
small changes/commits we can always find test older commits if we find some 
issue.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath 
caching from causing pollution
URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786
 
 
   it's okay in version 2.x since these tests must be older and different from 
3.x. The reason why there is File mock is to simplify the Captures of debug 
logger because there is no physicla path and no troubles with platform and long 
lines in code. Also it is a signal for us to fail the test if the logic in 
`AbstractSurefireMojo` would change in the future when the logic would need to 
have a real paths and real reds/writes. Till that it is just in memory.
   
   These tests in `AbstractSurefireMojoTest.java` do not have too much 
assertion statements. They have more Captures and verifications. And the reason 
is that the class `AbstractSurefireMojo` was not developed with tests. 
Basically there was no TDD in this class development. If there was I wam sure 
there could be much more assertions on returned values and less mocking of 
internal state and captures. This happens when TDD is not applied in the 
begining. Positive remark is that these tests improve the coverage and give us 
some feedback when the code is changed together with the experiences of the 
`AbstractSurefireMojo`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] Tibor17 commented on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
Tibor17 commented on issue #244: [SUREFIRE-1679] Prevent classpath caching from 
causing pollution
URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786
 
 
   it's okay in version 2.x since these tests must be older and different from 
3.x. The reason why there is File mock is to simplify the Captures of debug 
logger because there is no physicla path and no troubles with platform and long 
lines in code. Also it is a signal for us to fail the test if the logic in 
`AbstractSurefireMojo` would change in the future when the logic would need to 
have a real paths and real reds/writes. Till that it is just in memory.
   
   These tests in `AbstractSurefireMojoTest.java` do not have too much 
assertion statements. They have more Captures and verifications. And the reason 
is that the class `AbstractSurefireMojo` was not developed with tests. 
Basically there was TDD on this class development. If there was I wam sure 
there could be much more assertions on returned values and less mocking of 
internal state and captures. This happens when TDD is not applied in the 
begining. Positive remark is that these tests improve the coverage and give us 
some feedback when the code is changed together with the experiences of the 
`AbstractSurefireMojo`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314347605
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java
 ##
 @@ -86,18 +93,13 @@ protected void setUp()
 handlerList.addHandler( repoHandler );
 handlerList.addHandler( new DefaultHandler() );
 
-server = new Server( 0 );
 server.setHandler( handlerList );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 
 Review comment:
   If you have parallel processes sure.
   But your usages are sequential.
   If you decided to use something like DeploymentManager to scan for webapps 
and deploy them, then you would be interested in ThrowUnavailableOnStartup, 
which waits for initial deployment to report failures to Server.start


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314300317
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java
 ##
 @@ -86,18 +93,13 @@ protected void setUp()
 handlerList.addHandler( repoHandler );
 handlerList.addHandler( new DefaultHandler() );
 
-server = new Server( 0 );
 server.setHandler( handlerList );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 
 Review comment:
   because this has a purpose. I want to catch all errors. Not only IOException.
   ```
   @Override
   public final void start() throws Exception
   {
   synchronized (_lock)
   {
   try
   {
   if (_state == __STARTED || _state == __STARTING)
   return;
   setStarting();
   doStart();
   setStarted();
   }
   catch (Throwable e)
   {
   setFailed(e);
   throw e;
   }
   }
   }
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314307488
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java
 ##
 @@ -86,18 +93,13 @@ protected void setUp()
 handlerList.addHandler( repoHandler );
 handlerList.addHandler( new DefaultHandler() );
 
-server = new Server( 0 );
 server.setHandler( handlerList );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 
 Review comment:
   I think the purpose of this is to check server's status in a parallel 
thread. ok, we can avoid the IF statement.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath 
caching from causing pollution
URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786
 
 
   it's okay in version 2.x since these tests must be older and different from 
3.x. The reason why there is File mock is to simplify the Captures of debug 
logger because there is no physicla path and creating real Jar files, no 
troubles with platform and long lines in code. Also it is a signal for us to 
fail the test if the logic in `AbstractSurefireMojo` would change in the future 
when the logic would need to have a real paths and real reads/writes. Till that 
it is just in memory.
   
   These tests in `AbstractSurefireMojoTest.java` do not have too much 
assertion statements. They have more Captures and verifications. And the reason 
is that the class `AbstractSurefireMojo` was not initially developed with 
tests. Basically there was no TDD in this class development. If there was, I am 
sure there could be much more assertions on returned values and less mocking of 
internal state and captures. This happens when TDD is not applied in the 
begining. Positive remark is that these tests improve the coverage and give us 
some feedback when the code is changed together with the experiences of the 
`AbstractSurefireMojo`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314348659
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2305MultipleProxiesTest.java
 ##
 @@ -71,20 +78,16 @@ public void testit()
 String keyPwd = "key-passwd";
 
 Server server = new Server( 0 );
-server.addConnector( newHttpsConnector( storePath, storePwd, keyPwd ) 
);
+addHttpsConnector( server, storePath, storePwd, keyPwd );
 server.setHandler( new RepoHandler() );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-int httpPort = server.getConnectors()[0].getLocalPort();
+int httpPort = ( (NetworkConnector) server.getConnectors()[0] 
).getLocalPort();
 System.out.println( "Bound server socket to HTTP port " + httpPort );
-int httpsPort = server.getConnectors()[1].getLocalPort();
+int httpsPort = ( (NetworkConnector) server.getConnectors()[1] 
).getLocalPort();
 
 Review comment:
   Then your Requests never indicate that they are secure.
   The Requests will not contain the security details.
   The Requests will not have the javax attributes for the SSL / Certificate 
state of the connection.
   Nor will you have ability to use the "confidential" constraints.
   And usages that redirect from HTTP to HTTPS will also fail. (such as 
SecureRedirectHandler)


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
joakime commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314284534
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   There's also `server.getURI().getPort()` as a valid option here.
   (This will return the URI to the first connector's security scheme (http vs 
https) + local host + port + first handler's own context path)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314304344
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   @joakime 
   Do you see more occurences of this? Notice that we also have two connectors 
in few tests using HTTPS.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314304344
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   @joakime 
   Do you see more occurrences of this? Notice that we also have two connectors 
in few tests using HTTPS.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314301738
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
 ##
 @@ -59,15 +60,11 @@ protected void setUp()
 server = new Server( 0 );
 server.setHandler( handlers );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
 
 Review comment:
   I did not want to make the code too much different from what we had before. 
I am glad that the version 9.0.4 works. After I changed the version to 9.2.28 I 
got HTTP 405 and really did not want to get new arguments from the devs saying 
that there is something which broke new version.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty 
getLocalPort() returns -1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314309460
 
 

 ##
 File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2305MultipleProxiesTest.java
 ##
 @@ -71,20 +78,16 @@ public void testit()
 String keyPwd = "key-passwd";
 
 Server server = new Server( 0 );
-server.addConnector( newHttpsConnector( storePath, storePwd, keyPwd ) 
);
+addHttpsConnector( server, storePath, storePwd, keyPwd );
 server.setHandler( new RepoHandler() );
 server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
 {
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
 }
-int httpPort = server.getConnectors()[0].getLocalPort();
+int httpPort = ( (NetworkConnector) server.getConnectors()[0] 
).getLocalPort();
 System.out.println( "Bound server socket to HTTP port " + httpPort );
-int httpsPort = server.getConnectors()[1].getLocalPort();
+int httpsPort = ( (NetworkConnector) server.getConnectors()[1] 
).getLocalPort();
 
 Review comment:
   The thing is that we do not set the port, via 
`HttpConfiguration.setSecurePort(int)`, because we do not know it. We can only 
read both ports as local ports.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Created] (MPMD-294) Add support for setting includes/excludes via a user property

2019-08-15 Thread Roy Arnon (JIRA)
Roy Arnon created MPMD-294:
--

 Summary: Add support for setting includes/excludes via a user 
property
 Key: MPMD-294
 URL: https://issues.apache.org/jira/browse/MPMD-294
 Project: Maven PMD Plugin
  Issue Type: New Feature
  Components: CPD, PMD
Affects Versions: 3.12.0
Reporter: Roy Arnon


I have a use case were I want to execute pmd on a huge monorepo project, but 
only on the changed files.

Getting the changed java files via git is trivial, but it seems that the PMD 
plugin does not support setting the includes/excludes by user property.

Can we look into adding a property like maven surefires 
includesFile/excludesFile, which will allow us to specify includes/excludes at 
runtime?

I may try to prepare a PR for this feature if I have the time.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath 
caching from causing pollution
URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786
 
 
   it's okay in version 2.x since these tests must be older and different from 
3.x. The reason why there is File mock is to simplify the Captures of debug 
logger because there is no physicla path and no troubles with platform and long 
lines in code. Also it is a signal for us to fail the test if the logic in 
`AbstractSurefireMojo` would change in the future when the logic would need to 
have a real paths and real reds/writes. Till that it is just in memory.
   
   These tests in `AbstractSurefireMojoTest.java` do not have too much 
assertion statements. They have more Captures and verifications. And the reason 
is that the class `AbstractSurefireMojo` was not developed with tests. 
Basically there was no TDD in this class development. If there was, I am sure 
there could be much more assertions on returned values and less mocking of 
internal state and captures. This happens when TDD is not applied in the 
begining. Positive remark is that these tests improve the coverage and give us 
some feedback when the code is changed together with the experiences of the 
`AbstractSurefireMojo`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath 
caching from causing pollution
URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786
 
 
   it's okay in version 2.x since these tests must be older and different from 
3.x. The reason why there is File mock is to simplify the Captures of debug 
logger because there is no physicla path and no troubles with platform and long 
lines in code. Also it is a signal for us to fail the test if the logic in 
`AbstractSurefireMojo` would change in the future when the logic would need to 
have a real paths and real reads/writes. Till that it is just in memory.
   
   These tests in `AbstractSurefireMojoTest.java` do not have too much 
assertion statements. They have more Captures and verifications. And the reason 
is that the class `AbstractSurefireMojo` was not initially developed with 
tests. Basically there was no TDD in this class development. If there was, I am 
sure there could be much more assertions on returned values and less mocking of 
internal state and captures. This happens when TDD is not applied in the 
begining. Positive remark is that these tests improve the coverage and give us 
some feedback when the code is changed together with the experiences of the 
`AbstractSurefireMojo`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector

2019-08-15 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907957#comment-16907957
 ] 

Kent Granström commented on MDEP-579:
-

Apologies [~pmoerenhout]. I made a typo and testing it after that it seems to 
work just fine. I can now use the "get" and it passes the creds nicely. I would 
concider this as solved, at least for me :). Perhaps a few testcases ought to 
be written for this, and similar, scenarios.

Many many thanks [~pmoerenhout]

> Regression: get goal does not pass server credentials to 
> BasicRepositoryConnector
> -
>
> Key: MDEP-579
> URL: https://issues.apache.org/jira/browse/MDEP-579
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: get
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Richard W. Eggert II
>Priority: Critical
>  Labels: credentials
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The {{get}} goal does not pass the server credentials from {{settings.xml}} 
> to the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0), 
> resulting in {{NotAuthorized}} errors when resolving artifacts against 
> repositories that require authentication. It works correctly in version 2.9.
> Background: I discovered this in the course of debugging a Jenkins job in 
> which I'm using the {{get}} and {{copy}} goals from the command line (with no 
> POM) to download artifacts to deploy. After spending several hours thinking 
> that Jenkins was not properly configuring {{settings.xml}}, I noticed from 
> the Maven debug output that the credentials were being passed when resolving 
> the maven-dependency-plugin and its dependencies, but not being passed when 
> resolving the artifact I requested. On a hunch I downgraded from 
> maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything 
> magically worked.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[GitHub] [maven-surefire] sormuras commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
sormuras commented on issue #243: [SUREFIRE-1679] Prevent classpath caching 
from causing pollution
URL: https://github.com/apache/maven-surefire/pull/243#issuecomment-521581930
 
 
   iirc, it's this branch 
https://github.com/apache/maven-surefire/tree/release/2.22.2


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] wilkinsona opened a new pull request #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
wilkinsona opened a new pull request #244: [SUREFIRE-1679] Prevent classpath 
caching from causing pollution
URL: https://github.com/apache/maven-surefire/pull/244
 
 
   This pull request backports the changes made in 
https://github.com/apache/maven-surefire/pull/243 to 2.22.x. The main source 
changes are the same. The test has be modified to align with the small 
differences in the implementation. Most notably, I have introduced the use of 
`TemporaryFolder` as the use of a mocked `File` resulted in an NPE as the 
`path` field of the mocked `File` was `null`. I hope that's OK.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] wilkinsona commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
wilkinsona commented on issue #243: [SUREFIRE-1679] Prevent classpath caching 
from causing pollution
URL: https://github.com/apache/maven-surefire/pull/243#issuecomment-521604924
 
 
   Thanks, @sormuras. I've opened a PR using that branch as its base: 
https://github.com/apache/maven-surefire/pull/244.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector

2019-08-15 Thread Pim Moerenhout (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907849#comment-16907849
 ] 

Pim Moerenhout commented on MDEP-579:
-

Hi [~kentgran],

I have setup the setup you've described, using a Nexus docker image as mirror 
of public with authentication, together with a private repository. However, I 
did change the mirrorOf property of the nexus mirror to *,!internal-repo-id, as 
this property must contain the id. See [Settings 
reference|https://maven.apache.org/settings.html#Mirrors].

With the setup described, the artifact could be get, from the internal 
repository, with the correct authentication. Before the get, I delete the 
artifact from the local repository in the .m2/repo folder.

In the failure log, the message is _Could not find artifact 
com.test.note:note-docker:zip:4.1 in nexus_. It's not mentioning that the 
authentication failed.

Could you verify in the real setup how the mirrorOf is specified ?

If it still fails, I could setup the docker image to hold the 2 repositories, 
as next step.

> Regression: get goal does not pass server credentials to 
> BasicRepositoryConnector
> -
>
> Key: MDEP-579
> URL: https://issues.apache.org/jira/browse/MDEP-579
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: get
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Richard W. Eggert II
>Priority: Critical
>  Labels: credentials
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The {{get}} goal does not pass the server credentials from {{settings.xml}} 
> to the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0), 
> resulting in {{NotAuthorized}} errors when resolving artifacts against 
> repositories that require authentication. It works correctly in version 2.9.
> Background: I discovered this in the course of debugging a Jenkins job in 
> which I'm using the {{get}} and {{copy}} goals from the command line (with no 
> POM) to download artifacts to deploy. After spending several hours thinking 
> that Jenkins was not properly configuring {{settings.xml}}, I noticed from 
> the Maven debug output that the credentials were being passed when resolving 
> the maven-dependency-plugin and its dependencies, but not being passed when 
> resolving the artifact I requested. On a hunch I downgraded from 
> maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything 
> magically worked.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`

2019-08-15 Thread Abel Salgado Romero (JIRA)


 [ 
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Abel Salgado Romero updated MSITE-849:
--
Description: 
In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a 
MavenProject to obtain addition configurations from the pom.xml 
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing 
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a 
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot 
find the instance.


{code:java}
HTTP ERROR 500

Problem accessing /hello.html. Reason:

Server Error

Caused by:

com.google.inject.ProvisionException: Unable to provision, see the following 
errors:

1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot 
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]] 
outside of a scoping block
  at 
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
 (via modules: org.eclipse.sisu.wire.WireModule -> 
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
  while locating org.apache.maven.project.MavenProject

1 error
at 
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at 
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}


* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# mvn site:run
# Access {{http://localhost:8080/hello.html}}


* Env:

{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime: 
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}


  was:
In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a 
MavenProject to obtain addition configurations from the pom.xml 
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing 
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a 
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot 
find the instance.


{code:java}
HTTP ERROR 500

Problem accessing /hello.html. Reason:

Server Error

Caused by:

com.google.inject.ProvisionException: Unable to provision, see the following 
errors:

1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot 
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]] 
outside of a scoping block
  at 
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
 (via modules: org.eclipse.sisu.wire.WireModule -> 
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
  while locating org.apache.maven.project.MavenProject

1 error
at 
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at 
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}


* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# Access {{http://localhost:8080/hello.html}}


* Env:

{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime: 
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}



> Unable to inject MavenProject 

[jira] [Created] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`

2019-08-15 Thread Abel Salgado Romero (JIRA)
Abel Salgado Romero created MSITE-849:
-

 Summary: Unable to inject MavenProject when using `mvn site:run`
 Key: MSITE-849
 URL: https://issues.apache.org/jira/browse/MSITE-849
 Project: Maven Site Plugin
  Issue Type: New Feature
Affects Versions: 3.8.2, 3.7.1
Reporter: Abel Salgado Romero


In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a 
MavenProject to obtain addition configurations from the pom.xml 
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing 
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a 
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot 
find the instance.


{code:java}
HTTP ERROR 500

Problem accessing /hello.html. Reason:

Server Error

Caused by:

com.google.inject.ProvisionException: Unable to provision, see the following 
errors:

1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot 
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]] 
outside of a scoping block
  at 
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
 (via modules: org.eclipse.sisu.wire.WireModule -> 
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
  while locating org.apache.maven.project.MavenProject

1 error
at 
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at 
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}


* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# Access {{http://localhost:8080/hello.html}}


* Env:

{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime: 
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[GitHub] [maven-plugin-testing] SingingBush commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0

2019-08-15 Thread GitBox
SingingBush commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target 
JDK 7 and maven 3.6.0
URL: 
https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-521729580
 
 
   the other changes I was looking at doing will be a seperate PR linked to 
[MPLUGINTESTING-63](https://issues.apache.org/jira/browse/MPLUGINTESTING-63).
   
   Is anything else required for this PR? Can it be merged?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Created] (MNG-6734) Ability to add Java sources to plugins classpath from .mvn directory

2019-08-15 Thread Abel Salgado Romero (JIRA)
Abel Salgado Romero created MNG-6734:


 Summary: Ability to add Java sources to plugins classpath from 
.mvn directory
 Key: MNG-6734
 URL: https://issues.apache.org/jira/browse/MNG-6734
 Project: Maven
  Issue Type: New Feature
  Components: core
Reporter: Abel Salgado Romero


In plugins like 
[asciidoctor-maven-plugin|https://github.com/asciidoctor/asciidoctor-maven-plugin]
 it is possible to add Java Asciidoctor extensions and other customizations to 
the conversion process.
These need to be available to the asciidoctor-maven-plugin classpath and due to 
how maven manages plugin's dependencies, this means that users need to publish 
these extension in a maven repo or create multi-module projects like in this 
example 
https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/java-extension-example.
This is cumbersome and a bit of overkill when some users just want to add a 
single class.

So, I wonder if would make sense to be able to add Java sources in the ".mvn" 
directory that are compiled and added to the classpath so that maven plugins 
can use them.
Ideally, to avoid classpath issues, I'd like to be able to tell which plugins 
use the code, maybe with an XML descriptor or some directory convention.






--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[GitHub] [maven-integration-testing] Tibor17 edited a comment on issue #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 edited a comment on issue #46: [MNG-6731] Jetty getLocalPort() returns 
-1 resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#issuecomment-521707874
 
 
   @joakime 
   The best idea would be to have a new PR with commits for each problem 
separately.
   Would you do that please?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven] suztomo commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException

2019-08-15 Thread GitBox
suztomo commented on issue #277: [MNG-6732] - 
DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon 
ArtifactTransferException
URL: https://github.com/apache/maven/pull/277#issuecomment-521734958
 
 
   @eolivelli  Thank you for question.
   
   
   > Isn't ArtifactTransferException a temporary failure?
   
   
[ArtifactTransferException](https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html)
 does not specify that. ArtifactTransferException can be a permanent failure 
from a retired repository (such as http://repository.codehaus.org/ ) as well as 
a temporary repository failure.
   
   > Will this change add unpredictable behavior to builds?
   
   No, it does not add unpredictable behavior (as far as I know). Thinking of 
two cases:
   
   - When all Maven repositories involved are alive
 No error. No unpredictable behavior.
   
   - When a Maven repository is temporarily down
 1. `DefaultRepositorySystem.collectDependencies` builds a partial 
dependency graph, rather than failing here (new behavior).
 1. The dependency graph is transformed via Maven's dependency mediation 
(no change)
   In [my example](https://github.com/suztomo/maven-missing-artifact), 
`artifact-to-be-removed:1.0` is removed from graph in favor of 
`artifact-to-be-removed:2.0`.
 1. `DefaultRepositorySystem.resolveDependencies` tries to resolve 
dependencies. (no change)
 **Maven fails** to resolve dependencies if the graph contains an 
artifact hosted in the temporarily-down repository.
 **Maven succeeds** if the graph does not contain missing artifact, 
resulting in the same graph as the case of "When a live repository is alive"
   
   
   
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Created] (MPLUGINTESTING-64) broken links on website

2019-08-15 Thread Samael Bate (JIRA)
Samael Bate created MPLUGINTESTING-64:
-

 Summary: broken links on website
 Key: MPLUGINTESTING-64
 URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-64
 Project: Maven Plugin Testing
  Issue Type: Task
Reporter: Samael Bate


Some links on 
[https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/] are 
invalid.

 

On the 
[https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/source-repository.html]
 page the github url is 
[https://github.com/apache/maven-plugin-testing/maven-plugin-testing-harness/] 
but it should simply be [https://github.com/apache/maven-plugin-testing/]

 

Also on the 
[https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/issue-tracking.html]
 page it has a link to [http://jira.codehaus.org/browse/MPLUGINTESTING] which 
is wrong as it should point to this Jira



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[GitHub] [maven] rfscholte commented on issue #165: [MNG-6028] Include current goals in resume suggestion

2019-08-15 Thread GitBox
rfscholte commented on issue #165: [MNG-6028] Include current goals in resume 
suggestion
URL: https://github.com/apache/maven/pull/165#issuecomment-52171
 
 
   `` works for me


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-plugin-testing] SingingBush commented on issue #4: Added support for plugins without configuration.

2019-08-15 Thread GitBox
SingingBush commented on issue #4: Added support for plugins without 
configuration.
URL: 
https://github.com/apache/maven-plugin-testing/pull/4#issuecomment-521730874
 
 
   Is there a reason this isn't being merged? vadeg is right, configuration is 
optional


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-integration-testing] Tibor17 commented on issue #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread GitBox
Tibor17 commented on issue #46: [MNG-6731] Jetty getLocalPort() returns -1 
resulting in build failures
URL: 
https://github.com/apache/maven-integration-testing/pull/46#issuecomment-521707874
 
 
   @joakime 
   The best idea would to have a new PR with commits for each problem 
separately. Would you do that?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (MNG-6734) Ability to add Java sources to plugins classpath from .mvn directory

2019-08-15 Thread Robert Scholte (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908287#comment-16908287
 ] 

Robert Scholte commented on MNG-6734:
-

I think the title needs to be rephrased, because it is not about sources being 
added to the classpath, but some unrelated  classes. There are more usecases 
where one want to build extra code as part of project. 
One of the ideas I have is to allow  in {{jar}} and other packaging 
projects. These modules won't the distributed (can't install or deploy), but 
are there to help the module. It seems like this issue would fit here as well.

> Ability to add Java sources to plugins classpath from .mvn directory
> 
>
> Key: MNG-6734
> URL: https://issues.apache.org/jira/browse/MNG-6734
> Project: Maven
>  Issue Type: New Feature
>  Components: core
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> In plugins like 
> [asciidoctor-maven-plugin|https://github.com/asciidoctor/asciidoctor-maven-plugin]
>  it is possible to add Java Asciidoctor extensions and other customizations 
> to the conversion process.
> These need to be available to the asciidoctor-maven-plugin classpath and due 
> to how maven manages plugin's dependencies, this means that users need to 
> publish these extension in a maven repo or create multi-module projects like 
> in this example 
> https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/java-extension-example.
> This is cumbersome and a bit of overkill when some users just want to add a 
> single class.
> So, I wonder if would make sense to be able to add Java sources in the ".mvn" 
> directory that are compiled and added to the classpath so that maven plugins 
> can use them.
> Ideally, to avoid classpath issues, I'd like to be able to tell which plugins 
> use the code, maybe with an XML descriptor or some directory convention.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (MNG-6734) Ability to add Java sources to plugins classpath from .mvn directory

2019-08-15 Thread Abel Salgado Romero (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908402#comment-16908402
 ] 

Abel Salgado Romero commented on MNG-6734:
--

The requirement could be rephrased indeed, the main idea is to be able to 
inject classes without needing additional modules like in the example: 
https://github.com/asciidoctor/asciidoctor-maven-examples/blob/f9580a7b22d015ce3f973099091f73802e867b3f/java-extension-example/asciidoctor-with-extension-example/pom.xml#L39.

I understand you mean that a project could have something like a gradle 
"sourceSet" that is not included in the artifact but can be used by a plugin 
during it's execution, is that so? If so, it would fit perfectly the need.

> Ability to add Java sources to plugins classpath from .mvn directory
> 
>
> Key: MNG-6734
> URL: https://issues.apache.org/jira/browse/MNG-6734
> Project: Maven
>  Issue Type: New Feature
>  Components: core
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> In plugins like 
> [asciidoctor-maven-plugin|https://github.com/asciidoctor/asciidoctor-maven-plugin]
>  it is possible to add Java Asciidoctor extensions and other customizations 
> to the conversion process.
> These need to be available to the asciidoctor-maven-plugin classpath and due 
> to how maven manages plugin's dependencies, this means that users need to 
> publish these extension in a maven repo or create multi-module projects like 
> in this example 
> https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/java-extension-example.
> This is cumbersome and a bit of overkill when some users just want to add a 
> single class.
> So, I wonder if would make sense to be able to add Java sources in the ".mvn" 
> directory that are compiled and added to the classpath so that maven plugins 
> can use them.
> Ideally, to avoid classpath issues, I'd like to be able to tell which plugins 
> use the code, maybe with an XML descriptor or some directory convention.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`

2019-08-15 Thread Michael Osipov (JIRA)


[ 
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908418#comment-16908418
 ] 

Michael Osipov commented on MSITE-849:
--

That's an interesting one. I need to see whether I can have a look at this 
tomorrow or next week.

> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
>  Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a 
> MavenProject to obtain addition configurations from the pom.xml 
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing 
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using 
> a provider. That is, {{site:site}} works, {{site:run}} fails because it 
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following 
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot 
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]] 
> outside of a scoping block
>   at 
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
>  (via modules: org.eclipse.sisu.wire.WireModule -> 
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
>   while locating org.apache.maven.project.MavenProject
> 1 error
>   at 
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
>   at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
>   at 
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
>   at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime: 
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`

2019-08-15 Thread Michael Osipov (JIRA)


 [ 
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MSITE-849:


Assignee: Michael Osipov

> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
>  Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a 
> MavenProject to obtain addition configurations from the pom.xml 
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing 
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using 
> a provider. That is, {{site:site}} works, {{site:run}} fails because it 
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following 
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot 
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]] 
> outside of a scoping block
>   at 
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
>  (via modules: org.eclipse.sisu.wire.WireModule -> 
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
>   while locating org.apache.maven.project.MavenProject
> 1 error
>   at 
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
>   at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
>   at 
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
>   at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime: 
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[GitHub] [maven-shade-plugin] Tibor17 edited a comment on issue #24: [MSHADE-322] - fixing windows tests

2019-08-15 Thread GitBox
Tibor17 edited a comment on issue #24: [MSHADE-322] - fixing windows tests
URL: https://github.com/apache/maven-shade-plugin/pull/24#issuecomment-521769609
 
 
   @rmannibucau 
   @eolivelli 
   This has to be closed because the change was squashed to another commit in 
master.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-shade-plugin] Tibor17 commented on issue #24: [MSHADE-322] - fixing windows tests

2019-08-15 Thread GitBox
Tibor17 commented on issue #24: [MSHADE-322] - fixing windows tests
URL: https://github.com/apache/maven-shade-plugin/pull/24#issuecomment-521769609
 
 
   @rmannibucau 
   @eolivelli 
   This has to be closed because the change was squashed with another commit in 
master.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (MINSTALL-160) generatePom=true with 3.0.0-M1 does not generate minimal POM but copies existing one

2019-08-15 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MINSTALL-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Václav Haisman updated MINSTALL-160:

Issue Type: Bug  (was: Wish)

> generatePom=true with 3.0.0-M1 does not generate minimal POM but copies 
> existing one
> 
>
> Key: MINSTALL-160
> URL: https://issues.apache.org/jira/browse/MINSTALL-160
> Project: Maven Install Plugin
>  Issue Type: Bug
>  Components: install:install-file
>Affects Versions: 3.0.0-M1
>Reporter: Václav Haisman
>Priority: Major
>
> I am using install:install-file with generatePom=true to install JAR with 
> minimal POM file. This has stopped working with 3.0.0-M1. With 3.0.0-M1, it 
> copeis existing project pom.xml instead of generating a minimal one.
>  
> This is easily reproducible with minimal project:
> {code:java}
> 
> http://maven.apache.org/POM/4.0.0; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>   4.0.0
>   maven.install.plugin.issue
>   maven.install.plugin.issue
>   1.0-SNAPSHOT
>   jar
>   maven.install.plugin.issue
>   
> 1.6
> 1.6
>   
>   
> 
>   
> 
>   maven-install-plugin
>   
>   3.0.0-M1
>   
> 
>   
> 
> 
>   
> maven-install-plugin
> 
>   
> default-install
> none
> install
>   
>   
> custom-install
> install
> 
>   install-file
> 
> 
>   
> ${project.build.directory}/${project.artifactId}-${project.version}.${project.packaging}
>   true
> 
>   
> 
>   
> 
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[GitHub] [maven-plugin-testing] rfscholte commented on issue #4: Added support for plugins without configuration.

2019-08-15 Thread GitBox
rfscholte commented on issue #4: Added support for plugins without 
configuration.
URL: 
https://github.com/apache/maven-plugin-testing/pull/4#issuecomment-521754941
 
 
   @SingingBush the list is long... However, nobody really answered my 
question. Just a thought: the idea of providing a pom is to provide a 
configured plugin, otherwise you can do a standard lookup, which is more 
efficient. This ensures you're using only defaults. 
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-plugin-testing] rfscholte commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0

2019-08-15 Thread GitBox
rfscholte commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 
7 and maven 3.6.0
URL: 
https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-521756916
 
 
   For this PR I don't see the need for changing the Maven version, it should 
be picked up by the direct as direct dependency of the plugin you're testing. 
   Bumping `java.version` + some other dependencies is good enough. Add that 
list to jira and adjust the title, because that's what we use for the release 
notes.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-shade-plugin] rmannibucau closed pull request #23: [MSHADE-322] adding properties transformer

2019-08-15 Thread GitBox
rmannibucau closed pull request #23: [MSHADE-322] adding properties transformer
URL: https://github.com/apache/maven-shade-plugin/pull/23
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-shade-plugin] rmannibucau closed pull request #24: [MSHADE-322] - fixing windows tests

2019-08-15 Thread GitBox
rmannibucau closed pull request #24: [MSHADE-322] - fixing windows tests
URL: https://github.com/apache/maven-shade-plugin/pull/24
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [maven-surefire] Tibor17 commented on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution

2019-08-15 Thread GitBox
Tibor17 commented on issue #244: [SUREFIRE-1679] Prevent classpath caching from 
causing pollution
URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521745794
 
 
   LGTM


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread Robert Scholte (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908416#comment-16908416
 ] 

Robert Scholte commented on MNG-6731:
-

I removed the {{fix for versions}}. The release notes should reflect the 
changes to Maven (Core)

> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
>  Issue Type: Bug
>  Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method 
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open. 
> So I decided to use [2] and wait until the server is up. This was of course 
> wrong because the status of the server is set to {{STARTED}} immediatelly 
> after the method {{Server.start()}}. So therefore I was googling a little bit 
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was 
> with a bug in Jetty server which is {{race condition}}. The article has a 
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the 
> annoucements [4] from Eclipse/Jetty, the bug  "{{JETTY-748 Prevent race close 
> of socket by old acceptor threads}}" was fixed in the version 
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that 
> the class {{HashUserRealm}} was deleted and there is no support and no 
> further development of {{org.mortbay}}. Eclipse continues with the 
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API 
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata 
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central 
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1, 
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`

2019-08-15 Thread Abel Salgado Romero (JIRA)


[ 
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908427#comment-16908427
 ] 

Abel Salgado Romero commented on MSITE-849:
---

Anything I can do to help let me know.

> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
>  Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a 
> MavenProject to obtain addition configurations from the pom.xml 
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing 
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using 
> a provider. That is, {{site:site}} works, {{site:run}} fails because it 
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following 
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot 
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]] 
> outside of a scoping block
>   at 
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
>  (via modules: org.eclipse.sisu.wire.WireModule -> 
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
>   while locating org.apache.maven.project.MavenProject
> 1 error
>   at 
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
>   at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
>   at 
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
>   at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime: 
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures

2019-08-15 Thread Robert Scholte (JIRA)


 [ 
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MNG-6731:

Fix Version/s: (was: 3.6.2)
   (was: 3.6.x-candidate)

> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
>  Issue Type: Bug
>  Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method 
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open. 
> So I decided to use [2] and wait until the server is up. This was of course 
> wrong because the status of the server is set to {{STARTED}} immediatelly 
> after the method {{Server.start()}}. So therefore I was googling a little bit 
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was 
> with a bug in Jetty server which is {{race condition}}. The article has a 
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the 
> annoucements [4] from Eclipse/Jetty, the bug  "{{JETTY-748 Prevent race close 
> of socket by old acceptor threads}}" was fixed in the version 
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that 
> the class {{HashUserRealm}} was deleted and there is no support and no 
> further development of {{org.mortbay}}. Eclipse continues with the 
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API 
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata 
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central 
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1, 
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (MPLUGINTESTING-62) use maven API 3.6.0 and Plexus 2.0.0

2019-08-15 Thread Samael Bate (JIRA)


 [ 
https://issues.apache.org/jira/browse/MPLUGINTESTING-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Samael Bate updated MPLUGINTESTING-62:
--
Summary: use maven API 3.6.0 and Plexus 2.0.0  (was: target maven 3.6.0 API)

> use maven API 3.6.0 and Plexus 2.0.0
> 
>
> Key: MPLUGINTESTING-62
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-62
> Project: Maven Plugin Testing
>  Issue Type: Improvement
>Reporter: Samael Bate
>Priority: Major
>
> To get this plugin working well with more recent versions of Maven (and Java) 
> it makes sense to do this and MPLUGINTESTING-61



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (MPLUGINTESTING-62) use maven API 3.6.0 and Plexus 2.0.0

2019-08-15 Thread Samael Bate (JIRA)


 [ 
https://issues.apache.org/jira/browse/MPLUGINTESTING-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Samael Bate updated MPLUGINTESTING-62:
--
Description: 
Along with updating to use Java 7 (MPLUGINTESTING-61) the plugin should use a 
recent maven API.

As there is no 3.6.0 for maven-aether-provider it will need be set to 3.3.9

  was:To get this plugin working well with more recent versions of Maven (and 
Java) it makes sense to do this and MPLUGINTESTING-61


> use maven API 3.6.0 and Plexus 2.0.0
> 
>
> Key: MPLUGINTESTING-62
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-62
> Project: Maven Plugin Testing
>  Issue Type: Improvement
>Reporter: Samael Bate
>Priority: Major
>
> Along with updating to use Java 7 (MPLUGINTESTING-61) the plugin should use a 
> recent maven API.
> As there is no 3.6.0 for maven-aether-provider it will need be set to 3.3.9



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots

2019-08-15 Thread Laird Nelson (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908697#comment-16908697
 ] 

Laird Nelson commented on MNG-6735:
---

After some more research, I see that this may be the very problem that the 
inscrutably named {{useBaseVersion}} parameter was invented to solve.  I find 
that when I set this to {{false}}, the issues go away.  I'm not sure what "base 
version" is, and if I had to guess based on the English, I would have thought 
that given a pinned snapshot version, then I would want that version to be 
used, so intuitively I'd expect that {{useBaseVersion}} should be set to 
{{true}}.  But it appears that I have this exactly backwards!

> ArtifactUtils#toSnapshotVersion problem with pinned snapshots
> -
>
> Key: MNG-6735
> URL: https://issues.apache.org/jira/browse/MNG-6735
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.6.1
>Reporter: Laird Nelson
>Priority: Major
>
> I apologize in advance for the vagueness.
> In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
> I am using a project whose released version depends on a pinned snapshot: 
> [https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
> This works fine for things like unit tests and so on.
> For various reasons, some of which are good and some of which are bad, we 
> need to copy this pinned snapshot using the Maven dependency plugin's 
> {{copy-dependencies}} goal.  We construct a prefixed classpath entry in a jar 
> file's manifest that refers to this pinned snapshot version.
> When we do so, we discover that although this project depends on a pinned 
> snapshot, and although the Maven shared archiver constructs the manifest 
> {{Class-Path:}} entry properly, i.e. referring to the pinned version, not 
> anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to 
> infer that the pinned version is in fact a snapshot version, and so when the 
> jar file is copied it ends up with a suffix of {{-SNAPSHOT}}.  The end result 
> is that although the {{Class-Path:}} header is correct, no such pinned 
> snapshot version jar file exists.  Instead, a jar file with {{-SNAPSHOT}} as 
> a suffix is there instead, and we get classloading errors.
> I've traced the problem to {{ArtifactUtils}} where its 
> {{toSnapshotVersion(String)}} method appears to recognize this pinned version 
> string as a snapshot, and "helpfully" erases it, turning the resulting jar 
> file back into a {{-SNAPSHOT}} suffixed jar file.
> I don't see any workaround to this problem.  Is there a reason for this 
> helpful behavior?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots

2019-08-15 Thread Laird Nelson (JIRA)
Laird Nelson created MNG-6735:
-

 Summary: ArtifactUtils#toSnapshotVersion problem with pinned 
snapshots
 Key: MNG-6735
 URL: https://issues.apache.org/jira/browse/MNG-6735
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 3.6.1
Reporter: Laird Nelson


I apologize in advance for the vagueness.

In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.

I am using a project whose released version depends on a pinned snapshot: 
[https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]

This works fine for things like unit tests and so on.

For various reasons, some of which are good and some of which are bad, we need 
to copy this pinned snapshot using the Maven dependency plugin's 
{{copy-dependencies}} goal.  We construct a prefixed classpath entry in a jar 
file's manifest that refers to this pinned snapshot version.

When we do so, we discover that although this project depends on a pinned 
snapshot, and although the Maven shared archiver constructs the manifest 
{{Class-Path:}} entry properly, i.e. referring to the pinned version, not 
anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to infer 
that the pinned version is in fact a snapshot version, and so when the jar file 
is copied it ends up with a suffix of {{-SNAPSHOT}}.  The end result is that 
although the {{Class-Path:}} header is correct, no such pinned snapshot version 
jar file exists.  Instead, a jar file with {{-SNAPSHOT}} as a suffix is there 
instead, and we get classloading errors.

I've traced the problem to {{ArtifactUtils}} where its 
{{toSnapshotVersion(String)}} method appears to recognize this pinned version 
string as a snapshot, and "helpfully" erases it, turning the resulting jar file 
back into a {{-SNAPSHOT}} suffixed jar file.

I don't see any workaround to this problem.  Is there a reason for this helpful 
behavior?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots

2019-08-15 Thread Michael Osipov (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908723#comment-16908723
 ] 

Michael Osipov commented on MNG-6735:
-

First of all, why do you rely on snapshots? The general concept of snapshot 
versions are that you can replace one with each other with the same base 
version where as release cannot. Regardless of this, it maybe by design what 
you observe or just a subtile bug.

> ArtifactUtils#toSnapshotVersion problem with pinned snapshots
> -
>
> Key: MNG-6735
> URL: https://issues.apache.org/jira/browse/MNG-6735
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.6.1
>Reporter: Laird Nelson
>Priority: Major
>
> I apologize in advance for the vagueness.
> In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
> I am using a project whose released version depends on a pinned snapshot: 
> [https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
> This works fine for things like unit tests and so on.
> For various reasons, some of which are good and some of which are bad, we 
> need to copy this pinned snapshot using the Maven dependency plugin's 
> {{copy-dependencies}} goal.  We construct a prefixed classpath entry in a jar 
> file's manifest that refers to this pinned snapshot version.
> When we do so, we discover that although this project depends on a pinned 
> snapshot, and although the Maven shared archiver constructs the manifest 
> {{Class-Path:}} entry properly, i.e. referring to the pinned version, not 
> anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to 
> infer that the pinned version is in fact a snapshot version, and so when the 
> jar file is copied it ends up with a suffix of {{-SNAPSHOT}}.  The end result 
> is that although the {{Class-Path:}} header is correct, no such pinned 
> snapshot version jar file exists.  Instead, a jar file with {{-SNAPSHOT}} as 
> a suffix is there instead, and we get classloading errors.
> I've traced the problem to {{ArtifactUtils}} where its 
> {{toSnapshotVersion(String)}} method appears to recognize this pinned version 
> string as a snapshot, and "helpfully" erases it, turning the resulting jar 
> file back into a {{-SNAPSHOT}} suffixed jar file.
> I don't see any workaround to this problem.  Is there a reason for this 
> helpful behavior?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)