[GitHub] [maven-integration-testing] michael-o commented on a diff in pull request #174: [MNG-7504] Don't print warning unsupported reportPlugins for m-site-p
michael-o commented on code in PR #174:
URL:
https://github.com/apache/maven-integration-testing/pull/174#discussion_r902238831
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7504NotWarnUnsupportedReportPluginsTest.java:
##
@@ -0,0 +1,61 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.it;
+
+import java.io.File;
+import java.io.IOException;
+import java.util.List;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * Test for
+ * https://issues.apache.org/jira/browse/MNG-7504";>MNG-7504
+ *
+ * Warning about unsupported reportPlugins should not be printed for m-site-p.
+ *
+ * @author Slawomir Jaranowski
+ */
+public class MavenITmng7504NotWarnUnsupportedReportPluginsTest extends
AbstractMavenIntegrationTestCase
+{
+private static final String PROJECT_PATH =
"/mng-7504-warn-unsupported-report-plugins";
+
+public MavenITmng7504NotWarnUnsupportedReportPluginsTest()
+{
+super( "[3.9.0]" );
Review Comment:
I think you can even drop the brackets.
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7504NotWarnUnsupportedReportPluginsTest.java:
##
@@ -0,0 +1,61 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.it;
+
+import java.io.File;
+import java.io.IOException;
+import java.util.List;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * Test for
+ * https://issues.apache.org/jira/browse/MNG-7504";>MNG-7504
+ *
+ * Warning about unsupported reportPlugins should not be printed for m-site-p.
+ *
+ * @author Slawomir Jaranowski
+ */
+public class MavenITmng7504NotWarnUnsupportedReportPluginsTest extends
AbstractMavenIntegrationTestCase
+{
+private static final String PROJECT_PATH =
"/mng-7504-warn-unsupported-report-plugins";
+
+public MavenITmng7504NotWarnUnsupportedReportPluginsTest()
+{
+super( "[3.9.0]" );
Review Comment:
Stupid question, why only 3.9.0? My understanding:
* 3.9.0 is suppressing this
* 4.0.0 does not even invoke
In both cases the warning should be visible, no?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-archiver] michael-o commented on a diff in pull request #22: [MSHARED-1066] - Upgrade Plexus Archiver to 4.3.0, Improve the Reproducible Builds methods
michael-o commented on code in PR #22:
URL: https://github.com/apache/maven-archiver/pull/22#discussion_r902241569
##
src/main/java/org/apache/maven/archiver/MavenArchiver.java:
##
@@ -97,6 +101,10 @@
"${artifact.groupIdPath}/${artifact.artifactId}/" +
"${artifact.baseVersion}/${artifact.artifactId}-"
+
"${artifact.baseVersion}${dashClassifier?}.${artifact.extension}";
+private static final ZonedDateTime DATE_MIN = ZonedDateTime.parse(
"1980-01-01T00:00:02Z" );
+
+private static final ZonedDateTime DATE_MAX = ZonedDateTime.parse(
"2099-12-31T23:59:59Z" );
Review Comment:
Isn't this for Zip files only?
##
src/main/java/org/apache/maven/archiver/MavenArchiver.java:
##
@@ -812,28 +820,78 @@ public void setBuildJdkSpecDefaultEntry( boolean
buildJdkSpecDefaultEntry )
* @return the parsed timestamp, may be null if
null input or input contains only 1
* character
* @since 3.5.0
- * @throws java.lang.IllegalArgumentException if the outputTimestamp is
neither ISO 8601 nor an integer
+ * @throws IllegalArgumentException if the outputTimestamp is neither ISO
8601 nor an integer
+ * @deprecated Use {@link #parseBuildOutputTimestamp(String)} instead.
*/
+@Deprecated
public Date parseOutputTimestamp( String outputTimestamp )
{
-if ( StringUtils.isNumeric( outputTimestamp ) &&
StringUtils.isNotEmpty( outputTimestamp ) )
+return parseBuildOutputTimestamp( outputTimestamp ).map( Date::from
).orElse( null );
+}
+
+/**
+ * Configure Reproducible Builds archive creation if a timestamp is
provided.
+ *
+ * @param outputTimestamp the value of {@code
${project.build.outputTimestamp}} (may be {@code null})
+ * @return the parsed timestamp as {@link java.util.Date}
+ * @since 3.5.0
+ * @see #parseOutputTimestamp
+ * @deprecated Use {@link #configureReproducibleBuild(String)} instead.
+ */
+@Deprecated
+public Date configureReproducible( String outputTimestamp )
+{
+configureReproducibleBuild( outputTimestamp );
+return parseOutputTimestamp( outputTimestamp );
+}
+
+/**
+ * Parse output timestamp configured for Reproducible Builds' archive
entries.
+ *
+ * Either as {@link
java.time.format.DateTimeFormatter#ISO_ZONED_DATE_TIME} or as a number
representing seconds
+ * since the epoch (like https://reproducible-builds.org/docs/source-date-epoch/";>SOURCE_DATE_EPOCH).
+ *
+ * @param outputTimestamp the value of {@code
${project.build.outputTimestamp}} (may be {@code null})
+ * @return the parsed timestamp as an {@code Optional}, {@code
empty} if input is {@code null} or input
+ * contains only 1 character (not a number)
+ * @since 3.6.0
+ * @throws IllegalArgumentException if the outputTimestamp is neither ISO
8601 nor an integer
+ */
+public static Optional parseBuildOutputTimestamp( String
outputTimestamp )
+{
+// Fail-fast on nulls
+if ( outputTimestamp == null )
+{
+return Optional.empty();
+}
+
+// Number representing seconds since the epoch
+if ( StringUtils.isNotEmpty( outputTimestamp ) &&
StringUtils.isNumeric( outputTimestamp ) )
{
-return new Date( Long.parseLong( outputTimestamp ) * 1000 );
+return Optional.of( Instant.ofEpochSecond( Long.parseLong(
outputTimestamp ) ) );
}
-if ( outputTimestamp == null || outputTimestamp.length() < 2 )
+// no timestamp configured (1 character configuration is useful to
override a full value during pom
+// inheritance)
+if ( outputTimestamp.length() < 2 )
{
-// no timestamp configured (1 character configuration is useful to
override a full value during pom
-// inheritance)
-return null;
+return Optional.empty();
}
-DateFormat df = new SimpleDateFormat( "-MM-dd'T'HH:mm:ssXXX" );
try
{
-return df.parse( outputTimestamp );
+// Parse the date in UTC such as '2011-12-03T10:15:30Z' or with an
offset '2019-10-05T20:37:42+06:00'.
+final ZonedDateTime date = ZonedDateTime.parse( outputTimestamp )
+.withZoneSameInstant( ZoneOffset.UTC ).truncatedTo(
ChronoUnit.SECONDS );
Review Comment:
That reads beautifully...
##
src/test/java/org/apache/maven/archiver/MavenArchiverTest.java:
##
@@ -1444,54 +1447,76 @@ public void testParseOutputTimestamp()
assertThat( archiver.parseOutputTimestamp( "*" ) ).isNull();
assertThat( archiver.parseOutputTimestamp( "1570300662" ).getTime()
).isEqualTo( 1570300662000L );
-assertThat( archiver.parseOutputTimestamp( "0" ).getTime()
).isEqualTo( 0L );
+assertThat( archiver.parseOutputTimestamp( "0" ).getTime() ).isZero();
[jira] [Commented] (MSHARED-1066) Upgrade Plexus Archiver to 4.3.0
[
https://issues.apache.org/jira/browse/MSHARED-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556694#comment-17556694
]
ASF GitHub Bot commented on MSHARED-1066:
-
michael-o commented on code in PR #22:
URL: https://github.com/apache/maven-archiver/pull/22#discussion_r902241569
##
src/main/java/org/apache/maven/archiver/MavenArchiver.java:
##
@@ -97,6 +101,10 @@
"${artifact.groupIdPath}/${artifact.artifactId}/" +
"${artifact.baseVersion}/${artifact.artifactId}-"
+
"${artifact.baseVersion}${dashClassifier?}.${artifact.extension}";
+private static final ZonedDateTime DATE_MIN = ZonedDateTime.parse(
"1980-01-01T00:00:02Z" );
+
+private static final ZonedDateTime DATE_MAX = ZonedDateTime.parse(
"2099-12-31T23:59:59Z" );
Review Comment:
Isn't this for Zip files only?
##
src/main/java/org/apache/maven/archiver/MavenArchiver.java:
##
@@ -812,28 +820,78 @@ public void setBuildJdkSpecDefaultEntry( boolean
buildJdkSpecDefaultEntry )
* @return the parsed timestamp, may be null if
null input or input contains only 1
* character
* @since 3.5.0
- * @throws java.lang.IllegalArgumentException if the outputTimestamp is
neither ISO 8601 nor an integer
+ * @throws IllegalArgumentException if the outputTimestamp is neither ISO
8601 nor an integer
+ * @deprecated Use {@link #parseBuildOutputTimestamp(String)} instead.
*/
+@Deprecated
public Date parseOutputTimestamp( String outputTimestamp )
{
-if ( StringUtils.isNumeric( outputTimestamp ) &&
StringUtils.isNotEmpty( outputTimestamp ) )
+return parseBuildOutputTimestamp( outputTimestamp ).map( Date::from
).orElse( null );
+}
+
+/**
+ * Configure Reproducible Builds archive creation if a timestamp is
provided.
+ *
+ * @param outputTimestamp the value of {@code
${project.build.outputTimestamp}} (may be {@code null})
+ * @return the parsed timestamp as {@link java.util.Date}
+ * @since 3.5.0
+ * @see #parseOutputTimestamp
+ * @deprecated Use {@link #configureReproducibleBuild(String)} instead.
+ */
+@Deprecated
+public Date configureReproducible( String outputTimestamp )
+{
+configureReproducibleBuild( outputTimestamp );
+return parseOutputTimestamp( outputTimestamp );
+}
+
+/**
+ * Parse output timestamp configured for Reproducible Builds' archive
entries.
+ *
+ * Either as {@link
java.time.format.DateTimeFormatter#ISO_ZONED_DATE_TIME} or as a number
representing seconds
+ * since the epoch (like https://reproducible-builds.org/docs/source-date-epoch/";>SOURCE_DATE_EPOCH).
+ *
+ * @param outputTimestamp the value of {@code
${project.build.outputTimestamp}} (may be {@code null})
+ * @return the parsed timestamp as an {@code Optional}, {@code
empty} if input is {@code null} or input
+ * contains only 1 character (not a number)
+ * @since 3.6.0
+ * @throws IllegalArgumentException if the outputTimestamp is neither ISO
8601 nor an integer
+ */
+public static Optional parseBuildOutputTimestamp( String
outputTimestamp )
+{
+// Fail-fast on nulls
+if ( outputTimestamp == null )
+{
+return Optional.empty();
+}
+
+// Number representing seconds since the epoch
+if ( StringUtils.isNotEmpty( outputTimestamp ) &&
StringUtils.isNumeric( outputTimestamp ) )
{
-return new Date( Long.parseLong( outputTimestamp ) * 1000 );
+return Optional.of( Instant.ofEpochSecond( Long.parseLong(
outputTimestamp ) ) );
}
-if ( outputTimestamp == null || outputTimestamp.length() < 2 )
+// no timestamp configured (1 character configuration is useful to
override a full value during pom
+// inheritance)
+if ( outputTimestamp.length() < 2 )
{
-// no timestamp configured (1 character configuration is useful to
override a full value during pom
-// inheritance)
-return null;
+return Optional.empty();
}
-DateFormat df = new SimpleDateFormat( "-MM-dd'T'HH:mm:ssXXX" );
try
{
-return df.parse( outputTimestamp );
+// Parse the date in UTC such as '2011-12-03T10:15:30Z' or with an
offset '2019-10-05T20:37:42+06:00'.
+final ZonedDateTime date = ZonedDateTime.parse( outputTimestamp )
+.withZoneSameInstant( ZoneOffset.UTC ).truncatedTo(
ChronoUnit.SECONDS );
Review Comment:
That reads beautifully...
##
src/test/java/org/apache/maven/archiver/MavenArchiverTest.java:
##
@@ -1444,54 +1447,76 @@ public void testParseOutputTimestamp()
assertThat( archiver.parseOutputTimestamp( "*" ) ).isNull();
assertThat( arch
[GitHub] [maven-filtering] fbricon commented on pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
fbricon commented on PR #38: URL: https://github.com/apache/maven-filtering/pull/38#issuecomment-1161365275 Sorry for the late response (I'm not super active on the m2e front), but yeah the buildcontext API is very much used by m2e: https://github.com/eclipse-m2e/m2e-core/search?q=BuildContext Basically `mvn resources:resources` is called on each file change, as part of Eclipse's incremental build. So if filtering where to be invoked on all resources instead of what's defined in the build context, we'd see severe performance degradation in Eclipse -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-deploy-plugin] michael-o commented on a diff in pull request #25: [MDEPLOY-295] Drop MAT
michael-o commented on code in PR #25:
URL: https://github.com/apache/maven-deploy-plugin/pull/25#discussion_r902258110
##
src/main/java/org/apache/maven/plugins/deploy/DeployMojo.java:
##
@@ -137,12 +135,6 @@
@Parameter( property = "maven.deploy.skip", defaultValue = "false" )
private String skip = Boolean.FALSE.toString();
Review Comment:
Wow, why is that a string :-D
##
src/main/java/org/apache/maven/plugins/deploy/AbstractDeployMojo.java:
##
@@ -116,4 +120,88 @@ protected void warnIfAffectedPackagingAndMaven( final
String packaging )
}
}
}
+
+private RemoteRepository getRemoteRepository( ArtifactRepository
remoteRepository )
+{
+RemoteRepository aetherRepo = RepositoryUtils.toRepo( remoteRepository
);
+
+if ( aetherRepo.getAuthentication() == null || aetherRepo.getProxy()
== null )
+{
+RemoteRepository.Builder builder = new RemoteRepository.Builder(
aetherRepo );
+
+if ( aetherRepo.getAuthentication() == null )
+{
+builder.setAuthentication(
session.getRepositorySession().getAuthenticationSelector()
+.getAuthentication( aetherRepo ) );
+}
+
+if ( aetherRepo.getProxy() == null )
+{
+builder.setProxy(
session.getRepositorySession().getProxySelector().getProxy( aetherRepo ) );
+}
+
+aetherRepo = builder.build();
+}
+
+return aetherRepo;
+}
+
+protected DeployRequest deployRequest( ArtifactRepository repository,
List artifacts )
+{
+DeployRequest deployRequest = new DeployRequest();
+deployRequest.setRepository( getRemoteRepository( repository ) );
+for ( Artifact artifact : artifacts )
+{
+org.eclipse.aether.artifact.Artifact aetherArtifact =
RepositoryUtils.toArtifact( artifact );
+deployRequest.addArtifact( aetherArtifact );
+
+for ( ArtifactMetadata metadata : artifact.getMetadataList() )
+{
+if ( metadata instanceof ProjectArtifactMetadata )
+{
+org.eclipse.aether.artifact.Artifact pomArtifact = new
SubArtifact( aetherArtifact, "", "pom" );
+pomArtifact = pomArtifact.setFile( (
(ProjectArtifactMetadata) metadata ).getFile() );
+deployRequest.addArtifact( pomArtifact );
+}
+}
+}
+return deployRequest;
+}
+
+protected void deploy( DeployRequest deployRequest ) throws
MojoExecutionException
+{
+int retryFailedDeploymentCounter = Math.max( 1, Math.min( 10,
retryFailedDeploymentCount ) );
+DeploymentException exception = null;
+for ( int count = 0; count < retryFailedDeploymentCounter; count++ )
+{
+try
+{
+if ( count > 0 )
+{
+getLog().info( "Retrying deployment attempt " + ( count +
1 ) + " of "
++ retryFailedDeploymentCounter );
+}
+
+repositorySystem.deploy( session.getRepositorySession(),
deployRequest );
+exception = null;
+break;
+}
+catch ( DeploymentException e )
+{
+if ( count + 1 < retryFailedDeploymentCounter )
+{
+getLog().warn( "Encountered issue during deployment: " +
e.getLocalizedMessage() );
+getLog().debug( e.getMessage() );
Review Comment:
Honestly, just use warn with `e` and that's it. No brain magic.
##
src/main/java/org/apache/maven/plugins/deploy/AbstractDeployMojo.java:
##
@@ -116,4 +120,88 @@ protected void warnIfAffectedPackagingAndMaven( final
String packaging )
}
}
}
+
+private RemoteRepository getRemoteRepository( ArtifactRepository
remoteRepository )
+{
+RemoteRepository aetherRepo = RepositoryUtils.toRepo( remoteRepository
);
Review Comment:
Should we still use the old term `aether`?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[ https://issues.apache.org/jira/browse/MNG-7468 ]
Herve Boutemy deleted comment on MNG-7468:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #31
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/31/
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[ https://issues.apache.org/jira/browse/MNG-7468 ]
Herve Boutemy deleted comment on MNG-7468:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #42
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/42/
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[ https://issues.apache.org/jira/browse/MNG-7468 ]
Herve Boutemy deleted comment on MNG-7468:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #32
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/32/
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[ https://issues.apache.org/jira/browse/MNG-7468 ]
Herve Boutemy deleted comment on MNG-7468:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-7451 #5
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7451/5/
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[ https://issues.apache.org/jira/browse/MNG-7468 ]
Herve Boutemy deleted comment on MNG-7468:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #60
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/60/
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556704#comment-17556704
]
Herve Boutemy commented on MNG-7468:
[~sjaranowski] IIUC, the parameters existence check is currently not done at
plugin level but at goal level
what happens if there is a parameter that is defined at plugin level (because
it's simpler) but that only exists for some goals but not others?
I fear we'll have unwanted warning
maven-dependency-plugin is for example a typical plugin, where each goal has
quite specific parameters
I did not check yet, then I did not yet open a separate Jira issue related to
this one, but I suppose we'll need it...
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556708#comment-17556708
]
Slawomir Jaranowski commented on MNG-7468:
--
[~hboutemy] - Valid parameters are checked for current goal and also for all
other goal on plugin level.
Thee is IT test for it:
[https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7468UnsupportedPluginsParametersTest.java]
- testValidParameterForOtherGoal
But of course you can check by other hand.
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-archiver] jorsol commented on a diff in pull request #22: [MSHARED-1066] - Upgrade Plexus Archiver to 4.3.0, Improve the Reproducible Builds methods
jorsol commented on code in PR #22:
URL: https://github.com/apache/maven-archiver/pull/22#discussion_r902285916
##
src/test/java/org/apache/maven/archiver/MavenArchiverTest.java:
##
@@ -1444,54 +1447,76 @@ public void testParseOutputTimestamp()
assertThat( archiver.parseOutputTimestamp( "*" ) ).isNull();
assertThat( archiver.parseOutputTimestamp( "1570300662" ).getTime()
).isEqualTo( 1570300662000L );
-assertThat( archiver.parseOutputTimestamp( "0" ).getTime()
).isEqualTo( 0L );
+assertThat( archiver.parseOutputTimestamp( "0" ).getTime() ).isZero();
assertThat( archiver.parseOutputTimestamp( "1" ).getTime()
).isEqualTo( 1000L );
-assertThat( archiver.parseOutputTimestamp( "2019-10-05T18:37:42Z"
).getTime() ).isEqualTo( 1570300662000L );
-assertThat( archiver.parseOutputTimestamp( "2019-10-05T20:37:42+02:00"
).getTime() ).isEqualTo(
-1570300662000L );
-assertThat( archiver.parseOutputTimestamp( "2019-10-05T16:37:42-02:00"
).getTime() ).isEqualTo(
-1570300662000L );
+assertThat( archiver.parseOutputTimestamp( "2019-10-05T18:37:42Z"
).getTime() )
+.isEqualTo( 1570300662000L );
+assertThat( archiver.parseOutputTimestamp( "2019-10-05T20:37:42+02:00"
).getTime() )
+.isEqualTo( 1570300662000L );
+assertThat( archiver.parseOutputTimestamp( "2019-10-05T16:37:42-02:00"
).getTime() )
+.isEqualTo( 1570300662000L );
// These must result in IAE because we expect extended ISO format only
(ie with - separator for date and
// : separator for timezone), hence the XXX SimpleDateFormat for tz
offset
// X SimpleDateFormat accepts timezone without separator while date
has separator, which is a mix between
// basic (no separators, both for date and timezone) and extended
(separator for both)
-try
-{
-archiver.parseOutputTimestamp( "2019-10-05T20:37:42+0200" );
-fail();
-}
-catch ( IllegalArgumentException ignored )
-{
-}
-try
-{
-archiver.parseOutputTimestamp( "2019-10-05T20:37:42-0200" );
-fail();
-}
-catch ( IllegalArgumentException ignored )
-{
-}
+assertThatExceptionOfType( IllegalArgumentException.class )
+.isThrownBy( () -> archiver.parseOutputTimestamp(
"2019-10-05T20:37:42+0200" ) );
+assertThatExceptionOfType( IllegalArgumentException.class )
+.isThrownBy( () -> archiver.parseOutputTimestamp(
"2019-10-05T20:37:42-0200" ) );
+}
-// These unfortunately fail although the input is valid according to
ISO 8601
-// SDF does not allow strict telescoping parsing w/o permitting
invalid input as depicted above.
-// One has to use the new Java Time API for this.
-try
-{
-archiver.parseOutputTimestamp( "2019-10-05T20:37:42+02" );
-fail();
-}
-catch ( IllegalArgumentException ignored )
-{
-}
-try
-{
-archiver.parseOutputTimestamp( "2019-10-05T20:37:42-02" );
-fail();
-}
-catch ( IllegalArgumentException ignored )
-{
-}
+@ParameterizedTest
+@NullAndEmptySource
+@ValueSource( strings = { ".", " ", "_", "-", "T", "/", "!", "!", "*", "ñ"
} )
+public void testEmptyParseOutputTimestampInstant( String value )
+{
+// Empty optional if null or 1 char
+assertThat( MavenArchiver.parseBuildOutputTimestamp( value )
).isEmpty();
+}
+
+@ParameterizedTest
+@CsvSource( { "0,0", "1,1", "9,9", "1570300662,1570300662",
"2147483648,2147483648",
+"2019-10-05T18:37:42Z,1570300662",
"2019-10-05T20:37:42+02:00,1570300662",
+"2019-10-05T16:37:42-02:00,1570300662",
"1988-02-22T15:23:47.76598Z,572541827",
+"2011-12-03T10:15:30+01:00[Europe/Paris],1322903730",
Review Comment:
Sure, changed to OffsetDateTime to not accept the Zone.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1066) Upgrade Plexus Archiver to 4.3.0
[
https://issues.apache.org/jira/browse/MSHARED-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556713#comment-17556713
]
ASF GitHub Bot commented on MSHARED-1066:
-
jorsol commented on code in PR #22:
URL: https://github.com/apache/maven-archiver/pull/22#discussion_r902285916
##
src/test/java/org/apache/maven/archiver/MavenArchiverTest.java:
##
@@ -1444,54 +1447,76 @@ public void testParseOutputTimestamp()
assertThat( archiver.parseOutputTimestamp( "*" ) ).isNull();
assertThat( archiver.parseOutputTimestamp( "1570300662" ).getTime()
).isEqualTo( 1570300662000L );
-assertThat( archiver.parseOutputTimestamp( "0" ).getTime()
).isEqualTo( 0L );
+assertThat( archiver.parseOutputTimestamp( "0" ).getTime() ).isZero();
assertThat( archiver.parseOutputTimestamp( "1" ).getTime()
).isEqualTo( 1000L );
-assertThat( archiver.parseOutputTimestamp( "2019-10-05T18:37:42Z"
).getTime() ).isEqualTo( 1570300662000L );
-assertThat( archiver.parseOutputTimestamp( "2019-10-05T20:37:42+02:00"
).getTime() ).isEqualTo(
-1570300662000L );
-assertThat( archiver.parseOutputTimestamp( "2019-10-05T16:37:42-02:00"
).getTime() ).isEqualTo(
-1570300662000L );
+assertThat( archiver.parseOutputTimestamp( "2019-10-05T18:37:42Z"
).getTime() )
+.isEqualTo( 1570300662000L );
+assertThat( archiver.parseOutputTimestamp( "2019-10-05T20:37:42+02:00"
).getTime() )
+.isEqualTo( 1570300662000L );
+assertThat( archiver.parseOutputTimestamp( "2019-10-05T16:37:42-02:00"
).getTime() )
+.isEqualTo( 1570300662000L );
// These must result in IAE because we expect extended ISO format only
(ie with - separator for date and
// : separator for timezone), hence the XXX SimpleDateFormat for tz
offset
// X SimpleDateFormat accepts timezone without separator while date
has separator, which is a mix between
// basic (no separators, both for date and timezone) and extended
(separator for both)
-try
-{
-archiver.parseOutputTimestamp( "2019-10-05T20:37:42+0200" );
-fail();
-}
-catch ( IllegalArgumentException ignored )
-{
-}
-try
-{
-archiver.parseOutputTimestamp( "2019-10-05T20:37:42-0200" );
-fail();
-}
-catch ( IllegalArgumentException ignored )
-{
-}
+assertThatExceptionOfType( IllegalArgumentException.class )
+.isThrownBy( () -> archiver.parseOutputTimestamp(
"2019-10-05T20:37:42+0200" ) );
+assertThatExceptionOfType( IllegalArgumentException.class )
+.isThrownBy( () -> archiver.parseOutputTimestamp(
"2019-10-05T20:37:42-0200" ) );
+}
-// These unfortunately fail although the input is valid according to
ISO 8601
-// SDF does not allow strict telescoping parsing w/o permitting
invalid input as depicted above.
-// One has to use the new Java Time API for this.
-try
-{
-archiver.parseOutputTimestamp( "2019-10-05T20:37:42+02" );
-fail();
-}
-catch ( IllegalArgumentException ignored )
-{
-}
-try
-{
-archiver.parseOutputTimestamp( "2019-10-05T20:37:42-02" );
-fail();
-}
-catch ( IllegalArgumentException ignored )
-{
-}
+@ParameterizedTest
+@NullAndEmptySource
+@ValueSource( strings = { ".", " ", "_", "-", "T", "/", "!", "!", "*", "ñ"
} )
+public void testEmptyParseOutputTimestampInstant( String value )
+{
+// Empty optional if null or 1 char
+assertThat( MavenArchiver.parseBuildOutputTimestamp( value )
).isEmpty();
+}
+
+@ParameterizedTest
+@CsvSource( { "0,0", "1,1", "9,9", "1570300662,1570300662",
"2147483648,2147483648",
+"2019-10-05T18:37:42Z,1570300662",
"2019-10-05T20:37:42+02:00,1570300662",
+"2019-10-05T16:37:42-02:00,1570300662",
"1988-02-22T15:23:47.76598Z,572541827",
+"2011-12-03T10:15:30+01:00[Europe/Paris],1322903730",
Review Comment:
Sure, changed to OffsetDateTime to not accept the Zone.
> Upgrade Plexus Archiver to 4.3.0
>
>
> Key: MSHARED-1066
> URL: https://issues.apache.org/jira/browse/MSHARED-1066
> Project: Maven Shared Components
> Issue Type: Dependency upgrade
> Components: maven-archiver
>Affects Versions: maven-archiver-3.5.2
>Reporter: Jorge Solórzano
>Priority: Major
> Fix For: maven-archiver-3.6.0
>
>
> Maven Archiver 3.6.0 should update to Plexus Archiver 4.3.0 (once it's
> released), it contains fixes to reproducible modular jars and also target
[jira] [Commented] (MSHARED-1066) Upgrade Plexus Archiver to 4.3.0
[
https://issues.apache.org/jira/browse/MSHARED-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556715#comment-17556715
]
ASF GitHub Bot commented on MSHARED-1066:
-
jorsol commented on code in PR #22:
URL: https://github.com/apache/maven-archiver/pull/22#discussion_r902292422
##
src/main/java/org/apache/maven/archiver/MavenArchiver.java:
##
@@ -97,6 +101,10 @@
"${artifact.groupIdPath}/${artifact.artifactId}/" +
"${artifact.baseVersion}/${artifact.artifactId}-"
+
"${artifact.baseVersion}${dashClassifier?}.${artifact.extension}";
+private static final ZonedDateTime DATE_MIN = ZonedDateTime.parse(
"1980-01-01T00:00:02Z" );
+
+private static final ZonedDateTime DATE_MAX = ZonedDateTime.parse(
"2099-12-31T23:59:59Z" );
Review Comment:
Yes, it should be for Zip/Jar files. If I'm not wrong, Maven Archiver only
handles JarArchiver so this should not be an issue:
https://github.com/apache/maven-archiver/blob/6f74e5e363191337b7984988d861efb0a3c4b304/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L557-L565
FTR this is also validated by the JDK jar tool:
https://github.com/openjdk/jdk/blob/701ea3beaaef1acda2d2e041cfdb7d75549cf95c/src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java#L48-L50
> Upgrade Plexus Archiver to 4.3.0
>
>
> Key: MSHARED-1066
> URL: https://issues.apache.org/jira/browse/MSHARED-1066
> Project: Maven Shared Components
> Issue Type: Dependency upgrade
> Components: maven-archiver
>Affects Versions: maven-archiver-3.5.2
>Reporter: Jorge Solórzano
>Priority: Major
> Fix For: maven-archiver-3.6.0
>
>
> Maven Archiver 3.6.0 should update to Plexus Archiver 4.3.0 (once it's
> released), it contains fixes to reproducible modular jars and also target
> Java 8.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-archiver] jorsol commented on a diff in pull request #22: [MSHARED-1066] - Upgrade Plexus Archiver to 4.3.0, Improve the Reproducible Builds methods
jorsol commented on code in PR #22:
URL: https://github.com/apache/maven-archiver/pull/22#discussion_r902292422
##
src/main/java/org/apache/maven/archiver/MavenArchiver.java:
##
@@ -97,6 +101,10 @@
"${artifact.groupIdPath}/${artifact.artifactId}/" +
"${artifact.baseVersion}/${artifact.artifactId}-"
+
"${artifact.baseVersion}${dashClassifier?}.${artifact.extension}";
+private static final ZonedDateTime DATE_MIN = ZonedDateTime.parse(
"1980-01-01T00:00:02Z" );
+
+private static final ZonedDateTime DATE_MAX = ZonedDateTime.parse(
"2099-12-31T23:59:59Z" );
Review Comment:
Yes, it should be for Zip/Jar files. If I'm not wrong, Maven Archiver only
handles JarArchiver so this should not be an issue:
https://github.com/apache/maven-archiver/blob/6f74e5e363191337b7984988d861efb0a3c4b304/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L557-L565
FTR this is also validated by the JDK jar tool:
https://github.com/openjdk/jdk/blob/701ea3beaaef1acda2d2e041cfdb7d75549cf95c/src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java#L48-L50
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-integration-testing] slawekjaranowski commented on a diff in pull request #174: [MNG-7504] Don't print warning unsupported reportPlugins for m-site-p
slawekjaranowski commented on code in PR #174:
URL:
https://github.com/apache/maven-integration-testing/pull/174#discussion_r902293849
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7504NotWarnUnsupportedReportPluginsTest.java:
##
@@ -0,0 +1,61 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.it;
+
+import java.io.File;
+import java.io.IOException;
+import java.util.List;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * Test for
+ * https://issues.apache.org/jira/browse/MNG-7504";>MNG-7504
+ *
+ * Warning about unsupported reportPlugins should not be printed for m-site-p.
+ *
+ * @author Slawomir Jaranowski
+ */
+public class MavenITmng7504NotWarnUnsupportedReportPluginsTest extends
AbstractMavenIntegrationTestCase
+{
+private static final String PROJECT_PATH =
"/mng-7504-warn-unsupported-report-plugins";
+
+public MavenITmng7504NotWarnUnsupportedReportPluginsTest()
+{
+super( "[3.9.0]" );
Review Comment:
currently only 3.9.0 has a fix - https://github.com/apache/maven/pull/759
4.0.0 - still print warning MNG-7505
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-archiver] jorsol commented on a diff in pull request #22: [MSHARED-1066] - Upgrade Plexus Archiver to 4.3.0, Improve the Reproducible Builds methods
jorsol commented on code in PR #22:
URL: https://github.com/apache/maven-archiver/pull/22#discussion_r902294775
##
src/main/java/org/apache/maven/archiver/MavenArchiver.java:
##
@@ -812,28 +820,78 @@ public void setBuildJdkSpecDefaultEntry( boolean
buildJdkSpecDefaultEntry )
* @return the parsed timestamp, may be null if
null input or input contains only 1
* character
* @since 3.5.0
- * @throws java.lang.IllegalArgumentException if the outputTimestamp is
neither ISO 8601 nor an integer
+ * @throws IllegalArgumentException if the outputTimestamp is neither ISO
8601 nor an integer
+ * @deprecated Use {@link #parseBuildOutputTimestamp(String)} instead.
*/
+@Deprecated
public Date parseOutputTimestamp( String outputTimestamp )
{
-if ( StringUtils.isNumeric( outputTimestamp ) &&
StringUtils.isNotEmpty( outputTimestamp ) )
+return parseBuildOutputTimestamp( outputTimestamp ).map( Date::from
).orElse( null );
+}
+
+/**
+ * Configure Reproducible Builds archive creation if a timestamp is
provided.
+ *
+ * @param outputTimestamp the value of {@code
${project.build.outputTimestamp}} (may be {@code null})
+ * @return the parsed timestamp as {@link java.util.Date}
+ * @since 3.5.0
+ * @see #parseOutputTimestamp
+ * @deprecated Use {@link #configureReproducibleBuild(String)} instead.
+ */
+@Deprecated
+public Date configureReproducible( String outputTimestamp )
+{
+configureReproducibleBuild( outputTimestamp );
+return parseOutputTimestamp( outputTimestamp );
+}
+
+/**
+ * Parse output timestamp configured for Reproducible Builds' archive
entries.
+ *
+ * Either as {@link
java.time.format.DateTimeFormatter#ISO_ZONED_DATE_TIME} or as a number
representing seconds
+ * since the epoch (like https://reproducible-builds.org/docs/source-date-epoch/";>SOURCE_DATE_EPOCH).
+ *
+ * @param outputTimestamp the value of {@code
${project.build.outputTimestamp}} (may be {@code null})
+ * @return the parsed timestamp as an {@code Optional}, {@code
empty} if input is {@code null} or input
+ * contains only 1 character (not a number)
+ * @since 3.6.0
+ * @throws IllegalArgumentException if the outputTimestamp is neither ISO
8601 nor an integer
+ */
+public static Optional parseBuildOutputTimestamp( String
outputTimestamp )
+{
Review Comment:
I'm not sure what this means, are you referring to moving this out of Maven
Archiver?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1066) Upgrade Plexus Archiver to 4.3.0
[
https://issues.apache.org/jira/browse/MSHARED-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556716#comment-17556716
]
ASF GitHub Bot commented on MSHARED-1066:
-
jorsol commented on code in PR #22:
URL: https://github.com/apache/maven-archiver/pull/22#discussion_r902294775
##
src/main/java/org/apache/maven/archiver/MavenArchiver.java:
##
@@ -812,28 +820,78 @@ public void setBuildJdkSpecDefaultEntry( boolean
buildJdkSpecDefaultEntry )
* @return the parsed timestamp, may be null if
null input or input contains only 1
* character
* @since 3.5.0
- * @throws java.lang.IllegalArgumentException if the outputTimestamp is
neither ISO 8601 nor an integer
+ * @throws IllegalArgumentException if the outputTimestamp is neither ISO
8601 nor an integer
+ * @deprecated Use {@link #parseBuildOutputTimestamp(String)} instead.
*/
+@Deprecated
public Date parseOutputTimestamp( String outputTimestamp )
{
-if ( StringUtils.isNumeric( outputTimestamp ) &&
StringUtils.isNotEmpty( outputTimestamp ) )
+return parseBuildOutputTimestamp( outputTimestamp ).map( Date::from
).orElse( null );
+}
+
+/**
+ * Configure Reproducible Builds archive creation if a timestamp is
provided.
+ *
+ * @param outputTimestamp the value of {@code
${project.build.outputTimestamp}} (may be {@code null})
+ * @return the parsed timestamp as {@link java.util.Date}
+ * @since 3.5.0
+ * @see #parseOutputTimestamp
+ * @deprecated Use {@link #configureReproducibleBuild(String)} instead.
+ */
+@Deprecated
+public Date configureReproducible( String outputTimestamp )
+{
+configureReproducibleBuild( outputTimestamp );
+return parseOutputTimestamp( outputTimestamp );
+}
+
+/**
+ * Parse output timestamp configured for Reproducible Builds' archive
entries.
+ *
+ * Either as {@link
java.time.format.DateTimeFormatter#ISO_ZONED_DATE_TIME} or as a number
representing seconds
+ * since the epoch (like https://reproducible-builds.org/docs/source-date-epoch/";>SOURCE_DATE_EPOCH).
+ *
+ * @param outputTimestamp the value of {@code
${project.build.outputTimestamp}} (may be {@code null})
+ * @return the parsed timestamp as an {@code Optional}, {@code
empty} if input is {@code null} or input
+ * contains only 1 character (not a number)
+ * @since 3.6.0
+ * @throws IllegalArgumentException if the outputTimestamp is neither ISO
8601 nor an integer
+ */
+public static Optional parseBuildOutputTimestamp( String
outputTimestamp )
+{
Review Comment:
I'm not sure what this means, are you referring to moving this out of Maven
Archiver?
> Upgrade Plexus Archiver to 4.3.0
>
>
> Key: MSHARED-1066
> URL: https://issues.apache.org/jira/browse/MSHARED-1066
> Project: Maven Shared Components
> Issue Type: Dependency upgrade
> Components: maven-archiver
>Affects Versions: maven-archiver-3.5.2
>Reporter: Jorge Solórzano
>Priority: Major
> Fix For: maven-archiver-3.6.0
>
>
> Maven Archiver 3.6.0 should update to Plexus Archiver 4.3.0 (once it's
> released), it contains fixes to reproducible modular jars and also target
> Java 8.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-deploy-plugin] olamy commented on a diff in pull request #25: [MDEPLOY-295] Drop MAT
olamy commented on code in PR #25: URL: https://github.com/apache/maven-deploy-plugin/pull/25#discussion_r902357071 ## src/main/java/org/apache/maven/plugins/deploy/AbstractDeployMojo.java: ## @@ -19,16 +19,28 @@ * under the License. */ +import java.util.List; + +import org.apache.maven.RepositoryUtils; +import org.apache.maven.artifact.Artifact; +import org.apache.maven.artifact.metadata.ArtifactMetadata; import org.apache.maven.artifact.repository.ArtifactRepository; import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.MavenArtifactRepository; import org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout; import org.apache.maven.execution.MavenSession; import org.apache.maven.plugin.AbstractMojo; +import org.apache.maven.plugin.MojoExecutionException; import org.apache.maven.plugin.MojoFailureException; import org.apache.maven.plugins.annotations.Component; import org.apache.maven.plugins.annotations.Parameter; +import org.apache.maven.project.artifact.ProjectArtifactMetadata; import org.apache.maven.rtinfo.RuntimeInformation; +import org.eclipse.aether.RepositorySystem; Review Comment: and soon we will change to org.apache.maven package... ? maybe think in the other way… why we have not yet change package from maven-resolver? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #15
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/15/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #41
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/41/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6909 #8
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6909/8/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #45
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/45/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6548 #22
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6548/22/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #38
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/38/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/44/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #37
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/37/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-94 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-94/3/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build succeeded in Jenkins: Maven TLP » maven » master #436
See https://builds.apache.org/job/maven-box/job/maven/job/master/436/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26
See
https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #44
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/44/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6553 #38
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/38/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6889 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6889/3/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » Bananeweizen-MNG-6907 #3
See
https://builds.apache.org/job/maven-box/job/maven/job/Bananeweizen-MNG-6907/3/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » checkstyle-3.1 #2
See https://builds.apache.org/job/maven-box/job/maven/job/checkstyle-3.1/2/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » mng-5668-poc #24
See https://builds.apache.org/job/maven-box/job/maven/job/mng-5668-poc/24/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » REMOVE_DEPRECATED #16
See https://builds.apache.org/job/maven-box/job/maven/job/REMOVE_DEPRECATED/16/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6553 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/14/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-5567 #55
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5567/55/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6888 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6888/3/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6012-Missing-Profile-At-End
#57
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/57/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven » MNG-6829 #24
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6829/24/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build failed in Jenkins: Maven » Maven TLP » maven » master #137
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/137/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6555 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/14/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven » Maven TLP » maven » master #135
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/135/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build failed in Jenkins: Maven TLP » maven » MPOM-215 #33
See https://builds.apache.org/job/maven-box/job/maven/job/MPOM-215/33/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build failed in Jenkins: Maven TLP » maven » slf4j-1.8-modules #34
See https://builds.apache.org/job/maven-box/job/maven/job/slf4j-1.8-modules/34/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven TLP » maven-studies » maven-metrics #20
See
https://builds.apache.org/job/maven-box/job/maven-studies/job/maven-metrics/20/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build unstable in Jenkins: Maven » Maven TLP » maven » master #134
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/134/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build failed in Jenkins: Maven » Maven TLP » maven » master #202
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/202/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7338) Reduce carbon footprint in CI
[
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556756#comment-17556756
]
Jörg Hohwiller commented on MNG-7338:
-
[~michael-o] Thanks for your excellent hint about {{-ntp}} option. I manually
tested my build with both options ({{-B -ntp}}) and now the CI log looks
perfect to me,
So to summarize; An easy fix would be possible by honoring {{CI}} environment
variable in {{mvn}} launch skript (both bash and CMD) and if {{CI=true}} then
auotmatically enabling {{-B -ntp}}.
BTW: The only edge case I found additionally is when the build is calling maven
inside maven (e.g. via exec-plugin) but this is IMHO really and edge-case that
can still be solved within the build POM or if someone feels invited to push
the perfect solution he could still file an issue in exec-maven-plugin.
> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
> Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Maarten Mulders
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis,
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not
> even by defaults from the makers of build templates) and hence 80% of the log
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 246/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 250/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 254/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 258/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 262/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 266/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 270/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 274/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 279/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 283/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 287/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 291/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 295/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 299/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 303/5
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #138
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/138/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (MNG-6656) Introduce base for build/consumer process
[ https://issues.apache.org/jira/browse/MNG-6656 ]
Herve Boutemy deleted comment on MNG-6656:
was (Author: hudson):
Build succeeded in Jenkins: Maven » Maven TLP » maven » checkstyle-next #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/checkstyle-next/12/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142363#comment-17142363
]
Herve Boutemy edited comment on MNG-6656 at 6/21/22 9:38 AM:
-
done in
[bdec668de9c600165bb69c95b6ea0625d9f74fb0|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=bdec668de9c600165bb69c95b6ea0625d9f74fb0]
then maven-xml renamed to maven-model-transform in
[22954a04ffb631fefbf0e75cd056840d1248954a](https://github.com/apache/maven/commit/22954a04ffb631fefbf0e75cd056840d1248954a)
/
[e25cf17d3be614b52eff677ff075bbb620f07160](https://github.com/apache/maven/commit/e25cf17d3be614b52eff677ff075bbb620f07160)
/
[1b6caed1ea9bf1bbb46e90a23090433af0627a4f](https://github.com/apache/maven/commit/1b6caed1ea9bf1bbb46e90a23090433af0627a4f)
was (Author: rfscholte):
Fixed in
[bdec668de9c600165bb69c95b6ea0625d9f74fb0|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=bdec668de9c600165bb69c95b6ea0625d9f74fb0]
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142363#comment-17142363
]
Herve Boutemy edited comment on MNG-6656 at 6/21/22 9:39 AM:
-
done in
[bdec668de9c600165bb69c95b6ea0625d9f74fb0|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=bdec668de9c600165bb69c95b6ea0625d9f74fb0]
then maven-xml renamed to maven-model-transform in
[22954a04ffb631fefbf0e75cd056840d1248954a|https://github.com/apache/maven/commit/22954a04ffb631fefbf0e75cd056840d1248954a]
/
[e25cf17d3be614b52eff677ff075bbb620f07160/https://github.com/apache/maven/commit/e25cf17d3be614b52eff677ff075bbb620f07160]
/
[1b6caed1ea9bf1bbb46e90a23090433af0627a4f/https://github.com/apache/maven/commit/1b6caed1ea9bf1bbb46e90a23090433af0627a4f]
was (Author: rfscholte):
done in
[bdec668de9c600165bb69c95b6ea0625d9f74fb0|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=bdec668de9c600165bb69c95b6ea0625d9f74fb0]
then maven-xml renamed to maven-model-transform in
[22954a04ffb631fefbf0e75cd056840d1248954a](https://github.com/apache/maven/commit/22954a04ffb631fefbf0e75cd056840d1248954a)
/
[e25cf17d3be614b52eff677ff075bbb620f07160](https://github.com/apache/maven/commit/e25cf17d3be614b52eff677ff075bbb620f07160)
/
[1b6caed1ea9bf1bbb46e90a23090433af0627a4f](https://github.com/apache/maven/commit/1b6caed1ea9bf1bbb46e90a23090433af0627a4f)
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142363#comment-17142363
]
Herve Boutemy edited comment on MNG-6656 at 6/21/22 9:48 AM:
-
done in
[bdec668de9c600165bb69c95b6ea0625d9f74fb0|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=bdec668de9c600165bb69c95b6ea0625d9f74fb0],
with core IT added in
[79ed965031c27e8715c25ede79c7eb977ee26ed1|https://github.com/apache/maven-integration-testing/commit/79ed965031c27e8715c25ede79c7eb977ee26ed1]
then maven-xml renamed to maven-model-transform in
[22954a04ffb631fefbf0e75cd056840d1248954a|https://github.com/apache/maven/commit/22954a04ffb631fefbf0e75cd056840d1248954a]
/
[e25cf17d3be614b52eff677ff075bbb620f07160/https://github.com/apache/maven/commit/e25cf17d3be614b52eff677ff075bbb620f07160]
/
[1b6caed1ea9bf1bbb46e90a23090433af0627a4f/https://github.com/apache/maven/commit/1b6caed1ea9bf1bbb46e90a23090433af0627a4f]
was (Author: rfscholte):
done in
[bdec668de9c600165bb69c95b6ea0625d9f74fb0|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=bdec668de9c600165bb69c95b6ea0625d9f74fb0]
then maven-xml renamed to maven-model-transform in
[22954a04ffb631fefbf0e75cd056840d1248954a|https://github.com/apache/maven/commit/22954a04ffb631fefbf0e75cd056840d1248954a]
/
[e25cf17d3be614b52eff677ff075bbb620f07160/https://github.com/apache/maven/commit/e25cf17d3be614b52eff677ff075bbb620f07160]
/
[1b6caed1ea9bf1bbb46e90a23090433af0627a4f/https://github.com/apache/maven/commit/1b6caed1ea9bf1bbb46e90a23090433af0627a4f]
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142363#comment-17142363
]
Herve Boutemy edited comment on MNG-6656 at 6/21/22 9:58 AM:
-
done in
[bdec668de9c600165bb69c95b6ea0625d9f74fb0|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=bdec668de9c600165bb69c95b6ea0625d9f74fb0],
with core IT added in
[79ed965031c27e8715c25ede79c7eb977ee26ed1|https://github.com/apache/maven-integration-testing/commit/79ed965031c27e8715c25ede79c7eb977ee26ed1]
and documentation published
https://maven.apache.org/ref/4-LATEST/maven-model-transform/index.html
then maven-xml renamed to maven-model-transform in
[22954a04ffb631fefbf0e75cd056840d1248954a|https://github.com/apache/maven/commit/22954a04ffb631fefbf0e75cd056840d1248954a]
/
[e25cf17d3be614b52eff677ff075bbb620f07160|https://github.com/apache/maven/commit/e25cf17d3be614b52eff677ff075bbb620f07160]
/
[1b6caed1ea9bf1bbb46e90a23090433af0627a4f|https://github.com/apache/maven/commit/1b6caed1ea9bf1bbb46e90a23090433af0627a4f]
was (Author: rfscholte):
done in
[bdec668de9c600165bb69c95b6ea0625d9f74fb0|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=bdec668de9c600165bb69c95b6ea0625d9f74fb0],
with core IT added in
[79ed965031c27e8715c25ede79c7eb977ee26ed1|https://github.com/apache/maven-integration-testing/commit/79ed965031c27e8715c25ede79c7eb977ee26ed1]
then maven-xml renamed to maven-model-transform in
[22954a04ffb631fefbf0e75cd056840d1248954a|https://github.com/apache/maven/commit/22954a04ffb631fefbf0e75cd056840d1248954a]
/
[e25cf17d3be614b52eff677ff075bbb620f07160/https://github.com/apache/maven/commit/e25cf17d3be614b52eff677ff075bbb620f07160]
/
[1b6caed1ea9bf1bbb46e90a23090433af0627a4f/https://github.com/apache/maven/commit/1b6caed1ea9bf1bbb46e90a23090433af0627a4f]
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1, 4.0.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRELEASE-282) Replace the current 'arguments' parameter with specialized version for each mojo (eg. 'argumentsRelease')
[
https://issues.apache.org/jira/browse/MRELEASE-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556782#comment-17556782
]
Pablo Caraballo Llorente commented on MRELEASE-282:
---
In theory it should. However, since the {{release:prepare}} generates a
{{release.properties}} file, which contains the {{arguments}} of this goal and
overrides any declared for the {{release:perform}}, it makes impossible
declaring different args for each goal.
> Replace the current 'arguments' parameter with specialized version for each
> mojo (eg. 'argumentsRelease')
> -
>
> Key: MRELEASE-282
> URL: https://issues.apache.org/jira/browse/MRELEASE-282
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: prepare
>Affects Versions: 2.0-beta-6
> Environment: mvn 2.0.7
> WinXP
>Reporter: Marcel Schutte
>Priority: Major
>
> There is currently no way to configure the release:prepare and
> release:perform mojos with different values for the 'arguments' parameter.
> Brett said the solution should be to use unique names for the parameters [1]
> [2].
> I am aware that it is possible to use profiles for this. However, I want to
> declare the default behavior in my pom, not leave it to the user to provide
> the correct profile.
> There is a workaround available [3], however, this means you have to
> duplicate the default values for and plugin configuration.
> Some context for this improvement request is [4]
> [1] http://jira.codehaus.org/browse/MNG-1446
> [2] http://jira.codehaus.org/browse/MCOMPILER-15
> [3] http://jira.codehaus.org/browse/MRELEASE-59
> [4] http://www.nabble.com/release-plugin-configuration-tf4377660s177.html
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (MJAR-289) Support toolchain
b. ohnsorg created MJAR-289: --- Summary: Support toolchain Key: MJAR-289 URL: https://issues.apache.org/jira/browse/MJAR-289 Project: Maven JAR Plugin Issue Type: Improvement Reporter: b. ohnsorg # Configure a toolchain to use a more recent JDK, e.g. 17 # run mvn clean install with a different (older) JDK, e.g. 11 # maven-jar-plugin bails out with exit code other than 0 from jar command It seems very likely (see MJAR-62) that this plugin doesn't support toolchains at all. Since packaging as JAR is a basic operation this has to work out of the box, when using toolchains. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-install-plugin] olamy commented on pull request #31: [MINSTALL-175] Drop MAT
olamy commented on PR #31: URL: https://github.com/apache/maven-install-plugin/pull/31#issuecomment-1161552566 -0 we reached some consensus few years back saying we will use only `org.apache,maven` namespace to hide everything happened. And now we’re back on this? And then to change again back to `org.apache,maven` namespace -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-deploy-plugin] olamy commented on pull request #25: [MDEPLOY-295] Drop MAT
olamy commented on PR #25: URL: https://github.com/apache/maven-deploy-plugin/pull/25#issuecomment-1161553386 -0 same comment as here https://github.com/apache/maven-install-plugin/pull/31#issuecomment-1161552566 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-289) Support toolchain
[ https://issues.apache.org/jira/browse/MJAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556869#comment-17556869 ] Michael Osipov commented on MJAR-289: - What exactly you expect to see with this plugin? I don't understand. > Support toolchain > - > > Key: MJAR-289 > URL: https://issues.apache.org/jira/browse/MJAR-289 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: b. ohnsorg >Priority: Major > > # Configure a toolchain to use a more recent JDK, e.g. 17 > # run mvn clean install with a different (older) JDK, e.g. 11 > # maven-jar-plugin bails out with exit code other than 0 from jar command > > It seems very likely (see MJAR-62) that this plugin doesn't support > toolchains at all. Since packaging as JAR is a basic operation this has to > work out of the box, when using toolchains. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-install-plugin] slachiewicz commented on pull request #31: [MINSTALL-175] Drop MAT
slachiewicz commented on PR #31: URL: https://github.com/apache/maven-install-plugin/pull/31#issuecomment-1161691911 Let's imagine that we change package to o.a.m for resolver. It's like change like jakarta from javax. How this will look like? If we just change it, all old plugins will be broken. If we use our shared component - yes we can use reflections and our plugins may work. But what about everything else from community? +1 here to PR - this simplify code and remove access to API via reflections and maybe let's start discussion how to rename package on mailing list. This will tak years -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-install-plugin] cstamas commented on pull request #31: [MINSTALL-175] Drop MAT
cstamas commented on PR #31: URL: https://github.com/apache/maven-install-plugin/pull/31#issuecomment-1161697457 > -0 we reached some consensus few years back saying we will use only `org.apache,maven` namespace to hide everything happened. And now we’re back on this? And then to change again back to `org.apache,maven` namespace So I really don't understand your stance: MAT is needed to bridge between sonatype/eclipse package, but as prerequisite for plugin is raised to Maven 3.2.5, there is NO sonatype package in play anymore, hence, no need for MAT and it's non-trivial transitive dependencies (it pulls in bothj sonatype and eclipse resolver, plexus container default etc). Where are we about to change to, is WIP currently, the new Maven 4 API, but obviously, it does not exists yet in Maven 3.2.5+ :confused: -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-deploy-plugin] cstamas commented on a diff in pull request #25: [MDEPLOY-295] Drop MAT
cstamas commented on code in PR #25: URL: https://github.com/apache/maven-deploy-plugin/pull/25#discussion_r902575017 ## src/main/java/org/apache/maven/plugins/deploy/AbstractDeployMojo.java: ## @@ -19,16 +19,28 @@ * under the License. */ +import java.util.List; + +import org.apache.maven.RepositoryUtils; +import org.apache.maven.artifact.Artifact; +import org.apache.maven.artifact.metadata.ArtifactMetadata; import org.apache.maven.artifact.repository.ArtifactRepository; import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.MavenArtifactRepository; import org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout; import org.apache.maven.execution.MavenSession; import org.apache.maven.plugin.AbstractMojo; +import org.apache.maven.plugin.MojoExecutionException; import org.apache.maven.plugin.MojoFailureException; import org.apache.maven.plugins.annotations.Component; import org.apache.maven.plugins.annotations.Parameter; +import org.apache.maven.project.artifact.ProjectArtifactMetadata; import org.apache.maven.rtinfo.RuntimeInformation; +import org.eclipse.aether.RepositorySystem; Review Comment: Unsure what you talk about: * if about package change for resolver, yes, it will happen, somewhere around Maven 5, but that will not affect you as * Maven 4 introduces new API and _seals Maven internals off_ from plugins, hence from 4.1 or so, plugin will not "tamper" with resolver and other internal things of Maven anymore, will have to go for Maven API * in short, resolver package change, if that's you refer to will NOT affect you, and if the "soon we will change to" refers to Maven API 4.x, is still WIP and of course non existent in Maven 3.x 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-deploy-plugin] cstamas commented on a diff in pull request #25: [MDEPLOY-295] Drop MAT
cstamas commented on code in PR #25: URL: https://github.com/apache/maven-deploy-plugin/pull/25#discussion_r902575017 ## src/main/java/org/apache/maven/plugins/deploy/AbstractDeployMojo.java: ## @@ -19,16 +19,28 @@ * under the License. */ +import java.util.List; + +import org.apache.maven.RepositoryUtils; +import org.apache.maven.artifact.Artifact; +import org.apache.maven.artifact.metadata.ArtifactMetadata; import org.apache.maven.artifact.repository.ArtifactRepository; import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.MavenArtifactRepository; import org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout; import org.apache.maven.execution.MavenSession; import org.apache.maven.plugin.AbstractMojo; +import org.apache.maven.plugin.MojoExecutionException; import org.apache.maven.plugin.MojoFailureException; import org.apache.maven.plugins.annotations.Component; import org.apache.maven.plugins.annotations.Parameter; +import org.apache.maven.project.artifact.ProjectArtifactMetadata; import org.apache.maven.rtinfo.RuntimeInformation; +import org.eclipse.aether.RepositorySystem; Review Comment: Unsure what you talk about: * if you refer to package change for resolver, yes, it will happen, somewhere around Maven 5, but that will not affect you, as * Maven 4 introduces new API and _seals Maven internals off_ from plugins, hence from 4.1 or so, plugin will not "tamper" with resolver and other internal things of Maven anymore, will have to go for Maven API * in short, resolver package change, if that's you refer to will NOT affect you, and if the "soon we will change to" refers to Maven API 4.x, is still WIP and of course non existent in Maven 3.x 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7427) Intermittend failure on Java 17 LTS on Windows x64
[
https://issues.apache.org/jira/browse/MNG-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556897#comment-17556897
]
Michael Osipov commented on MNG-7427:
-
Can you provide more input?
> Intermittend failure on Java 17 LTS on Windows x64
> --
>
> Key: MNG-7427
> URL: https://issues.apache.org/jira/browse/MNG-7427
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.4
> Environment: I'm running Windows 2012 R2 Standard x64. Oracle JDK
> 17.0.1+12 SE. Maven 3.8.4.
>Reporter: Ben Middleton
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I'm experiencing random failures building a Java 17 project on our Windows
> x64 build agents:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.
[jira] [Closed] (MNG-7281) Announce new Maven releases via SDKMAN!
[ https://issues.apache.org/jira/browse/MNG-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7281. --- Fix Version/s: (was: wontfix-candidate) Resolution: Won't Fix Will not happen with us. Too much of a burden. > Announce new Maven releases via SDKMAN! > --- > > Key: MNG-7281 > URL: https://issues.apache.org/jira/browse/MNG-7281 > Project: Maven > Issue Type: Improvement >Reporter: Oliver Weiler >Priority: Major > > While new Maven releases are currently added by community contributions, it > would be even better if new releases would be announced by Maven itself. > For that, SDKMAN! offers a Vendor API where Vendors can request a token to > announce new releases via API. > https://sdkman.io/vendors > This would probably only require a small addition to the already existing > build pipeline. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7050) Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
[
https://issues.apache.org/jira/browse/MNG-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556899#comment-17556899
]
Michael Osipov commented on MNG-7050:
-
Waiting for an answer.
> Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
>
>
> Key: MNG-7050
> URL: https://issues.apache.org/jira/browse/MNG-7050
> Project: Maven
> Issue Type: Improvement
> Components: Core, Maven Wrapper, Settings
>Affects Versions: 3.6.3
>Reporter: Manuel Jordan
>Priority: Minor
> Labels: features
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I need do mention about Gradle to understand and find the same solution or
> approach for Maven.
> In Gradle exists the {{GRADLE_HOME}} and {{GRADLE_USER_HOME}} (repository)
> _environment variables_, for Maven the former through {{M2_HOME}} and about
> the _repository_ I use the {{settings.xml}} file to define the
> {{}} location
> For both Maven and Gradle I can define in peace the place about where is
> installed the software, for example other location than {{.m2}} and
> {{.gradle}} to a secondary disk and even with customized directory names.
> Same goal about the repository location, both for a secondary disk (remember
> for Maven through the {{settings.xml}} file)
> *Note*: therefore {{.gradle}} and {{.m2}} are empty and not used.
> In Gradle about the wrapper created, the {{gradle-wrapper.properties}} file
> has:
>
> {code:java}
> distributionBase=GRADLE_USER_HOME
> distributionPath=wrapper/dists
> distributionUrl=https\://services.gradle.org/distributions/gradle-#.#.#-bin.zip
> zipStoreBase=GRADLE_USER_HOME
> zipStorePath=wrapper/dists
> {code}
> Then the final path is: {{GRADLE_USER_HOME/wrapper/dists}}
> Therefore observe how {{GRADLE_USER_HOME}} (custom location - otherwise
> {{.gradle}} by default) is used to define the:
> * Local repository
> * Base path to install the downloaded Gradle through the wrapper
> *New Improvement*: Add for Maven an environment variable named M2_REPOSITORY
> for the _Local Repository_ and _Wrapper Installation_ locations that Maven
> should recognize automatically (*not* using the {{settings.xml}} file).
> It with the purpose to have any Maven wrapper(s) installed according to that
> _environment variable_ value (custom location - otherwise {{.m2}} by default)
> and of course applied for the Local Repository location too.
> *Observation*: If the {{settings.xml}} file exists it should override the
> M2_REPOSITORY value.
> *Therefore*: I need the {{maven-wrapper.properties}} using something like
> {{M2_REPOSITORY}} (custom location - otherwise {{.m2}} by default) according
> the developer/user in its machine.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (MNG-7126) Maven option -nsu --no-snapshot-updates not working
[ https://issues.apache.org/jira/browse/MNG-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7126. --- Fix Version/s: (was: waiting-for-feedback) (was: wontfix-candidate) Resolution: Incomplete Did receive requested information. > Maven option -nsu --no-snapshot-updates not working > --- > > Key: MNG-7126 > URL: https://issues.apache.org/jira/browse/MNG-7126 > Project: Maven > Issue Type: Bug > Components: Command Line >Affects Versions: 3.5.0 > Environment: Windows/Linux. Doesn't seem to matter. >Reporter: Bill >Priority: Major > Attachments: compass-next-X-output.txt.tar.gz > > > Essentially the option seems to just not work. > I found that the same issue outlines in the this Jira for Maven 3.0.3 still > applies to Maven 3.5.0: https://issues.apache.org/jira/browse/MNG-5064 > https://issues.apache.org/jira/browse/MNG-5064 > Here someone is mentioning still having the issue Maven 3.2.5: > [https://issues.maven.apache.narkive.com/gF3CQyTF/jira-commented-mng-5064-mvn-nsu-no-snapshot-updates-should-not-download-snapshots-and-break-local] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-filtering] cstamas commented on pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
cstamas commented on PR #38: URL: https://github.com/apache/maven-filtering/pull/38#issuecomment-1161742351 @fbricon but m2e uses this, very this implementation? Or it depends, as AFAIK when takari-lifecycle used, then this implementation is totally swapped out and unused by it. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] gnodet opened a new pull request, #175: Relax test for wider terminals
gnodet opened a new pull request, #175: URL: https://github.com/apache/maven-integration-testing/pull/175 Maven 4.0.x has some code new code which takes care of the terminal width to adjust the output. The number of dots can thus vary when running the tests locally. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7427) Intermittend failure on Java 17 LTS on Windows x64
[
https://issues.apache.org/jira/browse/MNG-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556913#comment-17556913
]
Ben Middleton commented on MNG-7427:
Sadly not. It would fail frequently, but not every time, so was difficult to
debug. It continued to be a problem on all our Windows Build Agents running
Java 17. We ended up switching to earlier Java on our Windows Build agents, as
we don't build any Java code on them, we're just running Maven modules. I
suspect it's linked to either Maven or one of the Maven modules misbehaving
with Java 17 on Windows.
> Intermittend failure on Java 17 LTS on Windows x64
> --
>
> Key: MNG-7427
> URL: https://issues.apache.org/jira/browse/MNG-7427
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.4
> Environment: I'm running Windows 2012 R2 Standard x64. Oracle JDK
> 17.0.1+12 SE. Maven 3.8.4.
>Reporter: Ben Middleton
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I'm experiencing random failures building a Java 17 project on our Windows
> x64 build agents:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launc
[jira] [Comment Edited] (MNG-7427) Intermittend failure on Java 17 LTS on Windows x64
[
https://issues.apache.org/jira/browse/MNG-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556913#comment-17556913
]
Ben Middleton edited comment on MNG-7427 at 6/21/22 1:34 PM:
-
Sadly not. We updated to the latest MDEP. It would fail frequently, but not
every time, so was difficult to debug. It continued to be a problem on all our
Windows Build Agents running Java 17. We ended up switching to earlier Java on
our Windows Build agents, as we don't build any Java code on them, we're just
running Maven modules. I suspect it's linked to either Maven or one of the
Maven modules misbehaving with Java 17 on Windows.
was (Author: bengineer):
Sadly not. It would fail frequently, but not every time, so was difficult to
debug. It continued to be a problem on all our Windows Build Agents running
Java 17. We ended up switching to earlier Java on our Windows Build agents, as
we don't build any Java code on them, we're just running Maven modules. I
suspect it's linked to either Maven or one of the Maven modules misbehaving
with Java 17 on Windows.
> Intermittend failure on Java 17 LTS on Windows x64
> --
>
> Key: MNG-7427
> URL: https://issues.apache.org/jira/browse/MNG-7427
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.4
> Environment: I'm running Windows 2012 R2 Standard x64. Oracle JDK
> 17.0.1+12 SE. Maven 3.8.4.
>Reporter: Ben Middleton
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I'm experiencing random failures building a Java 17 project on our Windows
> x64 build agents:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorIm
[GitHub] [maven-filtering] fbricon commented on pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
fbricon commented on PR #38: URL: https://github.com/apache/maven-filtering/pull/38#issuecomment-1161794101 m2e only uses org.sonatype.plexus.build.incremental.BuildContext. Looks like the eclipse-takari integration uses its own thing ([io.takari.incrementalbuild.BuildContext](https://github.com/takari/io.takari.m2e.lifecycle/search?q=buildcontext)). @ifedorenko or @jvanzyl would know better. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7427) Intermittend failure on Java 17 LTS on Windows x64
[
https://issues.apache.org/jira/browse/MNG-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556964#comment-17556964
]
Michael Osipov commented on MNG-7427:
-
Have you retried with Maven 3.8.6, if not retry and report please.
> Intermittend failure on Java 17 LTS on Windows x64
> --
>
> Key: MNG-7427
> URL: https://issues.apache.org/jira/browse/MNG-7427
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.4
> Environment: I'm running Windows 2012 R2 Standard x64. Oracle JDK
> 17.0.1+12 SE. Maven 3.8.4.
>Reporter: Ben Middleton
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I'm experiencing random failures building a Java 17 project on our Windows
> x64 build agents:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following a
[jira] [Commented] (MJAR-289) Support toolchain
[
https://issues.apache.org/jira/browse/MJAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556987#comment-17556987
]
b. ohnsorg commented on MJAR-289:
-
Amended the description. I was of the opinion those who are concerned know
about the state of MJAR-62 or what Maven toolchains means to maven-jar-plugin –
my bad.
> Support toolchain
> -
>
> Key: MJAR-289
> URL: https://issues.apache.org/jira/browse/MJAR-289
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: b. ohnsorg
>Priority: Major
>
> # Configure a toolchain to use a more recent JDK, e.g. 17
> # run mvn clean install with a different (older) JDK, e.g. 11
> # maven-jar-plugin bails out with exit code other than 0 from jar command
>
> It seems very likely (see MJAR-62) that this plugin doesn't support
> toolchains at all. Since packaging as JAR is a basic operation this has to
> work out of the box, when using toolchains.
>
> Instead current version of maven-jar-plugin runs a jar command that does not
> create a JAR. Since compilation takes place based on toolchain class files
> are of format version 61. This is incompatible with the jar command from a
> JDK 11.
>
> {code:java}
> […]
> [INFO] --- maven-compiler-plugin:3.9.0:testCompile (default-testCompile) @
> jpianotrain-core ---
> [INFO] Toolchain in maven-compiler-plugin: JDK[/opt/jdk-17.0.2/]
> […]
> [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @
> jpianotrain-core ---
> [INFO] Toolchain in maven-surefire-plugin: JDK[/opt/jdk-17.0.2/]
> […]
> [INFO] --- maven-jar-plugin:3.2.0:jar (default-jar) @ jpianotrain-core ---
> [INFO] Building jar:
> /home/onkobu/svn/jpianotrain/trunk/jpianotrain-core/target/jpianotrain-core-0.0.4-SNAPSHOT.jar
> java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor
> version 61.0
> at
> java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1091)
> at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:195)
> at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:147)
> at
> java.base/java.lang.module.ModuleDescriptor.read(ModuleDescriptor.java:2553)
> at
> jdk.jartool/sun.tools.jar.Main.addExtendedModuleAttributes(Main.java:2084)
> at jdk.jartool/sun.tools.jar.Main.update(Main.java:1018)
> at jdk.jartool/sun.tools.jar.Main.run(Main.java:366)
> at jdk.jartool/sun.tools.jar.JarToolProvider.run(JarToolProvider.java:37)
> at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.archiver.jar.JarToolModularJarArchiver.postCreateArchive(JarToolModularJarArchiver.java:114)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:1066)
> at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:676)
> at
> org.apache.maven.plugins.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:276)
> at
> org.apache.maven.plugins.jar.AbstractJarMojo.execute(AbstractJarMojo.java:307)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137){code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7427) Intermittend failure on Java 17 LTS on Windows x64
[
https://issues.apache.org/jira/browse/MNG-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556989#comment-17556989
]
Ben Middleton commented on MNG-7427:
Hi - have upgraded to Maven 3.8.6 and switched back to Java 17. We're sadly
still seeing the same error:
{code}
17:01:08 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:3.2.0:copy-resources
(copy-resources) on project udp-common-net-core: Execution copy-resources of
goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:copy-resources
failed: Plugin org.apache.maven.plugins:maven-resources-plugin:3.2.0 or one of
its dependencies could not be resolved: Could not find artifact
org.eclipse.sisu:org.eclipse.sisu.inject:jar:${project.version} in
releases-nexus (https://nexus.sdl.com/repository/releases) -> [Help 1]
{code}
Let me know if I can provide a sample pom for testing. It appears to affect
random maven modules.
> Intermittend failure on Java 17 LTS on Windows x64
> --
>
> Key: MNG-7427
> URL: https://issues.apache.org/jira/browse/MNG-7427
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.4
> Environment: I'm running Windows 2012 R2 Standard x64. Oracle JDK
> 17.0.1+12 SE. Maven 3.8.4.
>Reporter: Ben Middleton
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I'm experiencing random failures building a Java 17 project on our Windows
> x64 build agents:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack
> (unpack-msbuild-tasks) on project udp-net-interop: Execution
> unpack-msbuild-tasks of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:unpack failed: Plugin
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2 or one of its
> dependencies could not be resolved: The following artifacts could not be
> resolved: org.apache.maven.doxia:doxia-logging-api:jar:${project.version},
> org.apache.maven.doxia:doxia-skin-model:jar:${project.version}:
> org.apache.maven.doxia:doxia-logging-api:jar:${project.version} was not found
> in https://nexus.sdl.com/repository/releases during a previous attempt. This
> failure was cached in the local repository and resolution is not reattempted
> until the update interval of releases-nexus has elapsed or updates are forced
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke
[GitHub] [maven] hboutemy commented on pull request #756: MNG-7501 display relative path to pom.xml
hboutemy commented on PR #756: URL: https://github.com/apache/maven/pull/756#issuecomment-1161978062 - drop pom.xml: are we so constrained that we start complexifying? - mono-module: ok, we can do it, but does it deserve special case? - debug mode: it defeats the intent = have useful info on normal run (if we run debug mode, we're already lost in details) - "Generally speaking module name should be sufficient if dev did it right.": no, definitely no, if you have 5 levels of directories and you put them in the module name, you're lost -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7501) display relative path to pom.xml
[
https://issues.apache.org/jira/browse/MNG-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556999#comment-17556999
]
ASF GitHub Bot commented on MNG-7501:
-
hboutemy commented on PR #756:
URL: https://github.com/apache/maven/pull/756#issuecomment-1161978062
- drop pom.xml: are we so constrained that we start complexifying?
- mono-module: ok, we can do it, but does it deserve special case?
- debug mode: it defeats the intent = have useful info on normal run (if we
run debug mode, we're already lost in details)
- "Generally speaking module name should be sufficient if dev did it
right.": no, definitely no, if you have 5 levels of directories and you put
them in the module name, you're lost
> display relative path to pom.xml
>
>
> Key: MNG-7501
> URL: https://issues.apache.org/jira/browse/MNG-7501
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.6
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> when building large multi-module project, when a failure happens in the
> middle of the build, it's not easy to even identify where the module is
> located in the source tree: Maven displays the module name, but not the path
> to pom.xml. Then often we have to read output log of goals that have run
> hoping to find a hint
> it would be nice to have by default the path to the pom.xml displayed during
> Maven run.
> I see 2 options:
> 1. either in the module build header:
> {noformat}
> [INFO] --< org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution
> >--
> [INFO] Building Maven IT Plugin :: Dependency Resolution 2.1-SNAPSHOT
> [31/78]
> [INFO]
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> [INFO] [ maven-plugin
> ]
> {noformat}
> 2. or in each goal execution line during the module build:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @
> maven-it-plugin-dependency-resolution
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> ---
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] rmannibucau commented on pull request #756: MNG-7501 display relative path to pom.xml
rmannibucau commented on PR #756: URL: https://github.com/apache/maven/pull/756#issuecomment-1161988690 > drop pom.xml: are we so constrained that we start complexifying? Guess that to be fair it should be asked both ways, is current verbosity worth it and holding any information? Less is printed better it is IMHO and complexity is quite relative so think so personally. > mono-module: ok, we can do it, but does it deserve special case? Don't think so since the same issue hits big multimodule projects. > debug mode: it defeats the intent = have useful info on normal run (if we run debug mode, we're already lost in details) it is no more true since we get logger configuration on the CLI so we have built-in toggles now :) > "Generally speaking module name should be sufficient if dev did it right.": no, definitely no, if you have 5 levels of directories and you put them in the module name, you're lost Hmm, do you have some examples? Took tomee, activemq, cxf, camel and it is not the case and it is already complex enough projects IMHO. The side note there can be that all this implementation assumes using a single thread so can not even solve the original use case (this is where I mentionned putting it per line in compressed form). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7501) display relative path to pom.xml
[
https://issues.apache.org/jira/browse/MNG-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557004#comment-17557004
]
ASF GitHub Bot commented on MNG-7501:
-
rmannibucau commented on PR #756:
URL: https://github.com/apache/maven/pull/756#issuecomment-1161988690
> drop pom.xml: are we so constrained that we start complexifying?
Guess that to be fair it should be asked both ways, is current verbosity
worth it and holding any information? Less is printed better it is IMHO and
complexity is quite relative so think so personally.
> mono-module: ok, we can do it, but does it deserve special case?
Don't think so since the same issue hits big multimodule projects.
> debug mode: it defeats the intent = have useful info on normal run (if we
run debug mode, we're already lost in details)
it is no more true since we get logger configuration on the CLI so we have
built-in toggles now :)
> "Generally speaking module name should be sufficient if dev did it
right.": no, definitely no, if you have 5 levels of directories and you put
them in the module name, you're lost
Hmm, do you have some examples? Took tomee, activemq, cxf, camel and it is
not the case and it is already complex enough projects IMHO.
The side note there can be that all this implementation assumes using a
single thread so can not even solve the original use case (this is where I
mentionned putting it per line in compressed form).
> display relative path to pom.xml
>
>
> Key: MNG-7501
> URL: https://issues.apache.org/jira/browse/MNG-7501
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.6
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> when building large multi-module project, when a failure happens in the
> middle of the build, it's not easy to even identify where the module is
> located in the source tree: Maven displays the module name, but not the path
> to pom.xml. Then often we have to read output log of goals that have run
> hoping to find a hint
> it would be nice to have by default the path to the pom.xml displayed during
> Maven run.
> I see 2 options:
> 1. either in the module build header:
> {noformat}
> [INFO] --< org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution
> >--
> [INFO] Building Maven IT Plugin :: Dependency Resolution 2.1-SNAPSHOT
> [31/78]
> [INFO]
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> [INFO] [ maven-plugin
> ]
> {noformat}
> 2. or in each goal execution line during the module build:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @
> maven-it-plugin-dependency-resolution
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> ---
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (MJAR-289) Support toolchain
[
https://issues.apache.org/jira/browse/MJAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAR-289.
---
Resolution: Duplicate
> Support toolchain
> -
>
> Key: MJAR-289
> URL: https://issues.apache.org/jira/browse/MJAR-289
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: b. ohnsorg
>Priority: Major
>
> # Configure a toolchain to use a more recent JDK, e.g. 17
> # run mvn clean install with a different (older) JDK, e.g. 11
> # maven-jar-plugin bails out with exit code other than 0 from jar command
>
> It seems very likely (see MJAR-62) that this plugin doesn't support
> toolchains at all. Since packaging as JAR is a basic operation this has to
> work out of the box, when using toolchains.
>
> Instead current version of maven-jar-plugin runs a jar command that does not
> create a JAR. Since compilation takes place based on toolchain class files
> are of format version 61. This is incompatible with the jar command from a
> JDK 11.
>
> {code:java}
> […]
> [INFO] --- maven-compiler-plugin:3.9.0:testCompile (default-testCompile) @
> jpianotrain-core ---
> [INFO] Toolchain in maven-compiler-plugin: JDK[/opt/jdk-17.0.2/]
> […]
> [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @
> jpianotrain-core ---
> [INFO] Toolchain in maven-surefire-plugin: JDK[/opt/jdk-17.0.2/]
> […]
> [INFO] --- maven-jar-plugin:3.2.0:jar (default-jar) @ jpianotrain-core ---
> [INFO] Building jar:
> /home/onkobu/svn/jpianotrain/trunk/jpianotrain-core/target/jpianotrain-core-0.0.4-SNAPSHOT.jar
> java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor
> version 61.0
> at
> java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1091)
> at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:195)
> at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:147)
> at
> java.base/java.lang.module.ModuleDescriptor.read(ModuleDescriptor.java:2553)
> at
> jdk.jartool/sun.tools.jar.Main.addExtendedModuleAttributes(Main.java:2084)
> at jdk.jartool/sun.tools.jar.Main.update(Main.java:1018)
> at jdk.jartool/sun.tools.jar.Main.run(Main.java:366)
> at jdk.jartool/sun.tools.jar.JarToolProvider.run(JarToolProvider.java:37)
> at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.archiver.jar.JarToolModularJarArchiver.postCreateArchive(JarToolModularJarArchiver.java:114)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:1066)
> at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:676)
> at
> org.apache.maven.plugins.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:276)
> at
> org.apache.maven.plugins.jar.AbstractJarMojo.execute(AbstractJarMojo.java:307)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137){code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] hboutemy commented on pull request #756: MNG-7501 display relative path to pom.xml
hboutemy commented on PR #756: URL: https://github.com/apache/maven/pull/756#issuecomment-1162031946 > it is no more true since we get logger configuration on the CLI so we have built-in toggles now :) I don't understand > Hmm, do you have some examples? yes, see the description of the PR > The side note there can be that all this implementation assumes using a single thread so can not even solve the original use case it seems your original use case is not mine -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7501) display relative path to pom.xml
[
https://issues.apache.org/jira/browse/MNG-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557016#comment-17557016
]
ASF GitHub Bot commented on MNG-7501:
-
hboutemy commented on PR #756:
URL: https://github.com/apache/maven/pull/756#issuecomment-1162031946
> it is no more true since we get logger configuration on the CLI so we have
built-in toggles now :)
I don't understand
> Hmm, do you have some examples?
yes, see the description of the PR
> The side note there can be that all this implementation assumes using a
single thread so can not even solve the original use case
it seems your original use case is not mine
> display relative path to pom.xml
>
>
> Key: MNG-7501
> URL: https://issues.apache.org/jira/browse/MNG-7501
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.6
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> when building large multi-module project, when a failure happens in the
> middle of the build, it's not easy to even identify where the module is
> located in the source tree: Maven displays the module name, but not the path
> to pom.xml. Then often we have to read output log of goals that have run
> hoping to find a hint
> it would be nice to have by default the path to the pom.xml displayed during
> Maven run.
> I see 2 options:
> 1. either in the module build header:
> {noformat}
> [INFO] --< org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution
> >--
> [INFO] Building Maven IT Plugin :: Dependency Resolution 2.1-SNAPSHOT
> [31/78]
> [INFO]
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> [INFO] [ maven-plugin
> ]
> {noformat}
> 2. or in each goal execution line during the module build:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @
> maven-it-plugin-dependency-resolution
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> ---
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7498) Cannot use Maven to install a project on a NetApp volume
[ https://issues.apache.org/jira/browse/MNG-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557028#comment-17557028 ] Michael Bauer commented on MNG-7498: The justification is largely paranoia. We install software in nonstandard locations (see that /usr/sup directory), including libraries more recent than the system libraries, which we would like to see used instead of the system ones. We've seen entirely too many packages make assumptions about /usr/local or /opt, or come with baked-in directory paths that do not allow for our odd paths, so we generally build everything from source to make sure that our paths get at least considered in, if not baked into, the resulting binaries. > Cannot use Maven to install a project on a NetApp volume > > > Key: MNG-7498 > URL: https://issues.apache.org/jira/browse/MNG-7498 > Project: Maven > Issue Type: Bug > Components: Deployment >Affects Versions: 3.8.6 > Environment: RHEL 7 with a NetApp file server. >Reporter: Michael Bauer >Assignee: Michael Osipov >Priority: Minor > Fix For: waiting-for-feedback > > > By default, every directory in a volume that is exported from a Network > Appliance contains a directory named '.snapshot'. That directory is created > and maintained by the NetApp. It is read-only; it cannot be deleted or > altered. > > Maven appears to refuse to install into a directory that is not cleaned out, > and because of the nature of the subdirectory .snapshot it cannot delete that > subdirectory. Ergo, I get errors like: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-clean-plugin:3.1.0:clean (clean-target-dir) on > project apache-maven: Failed to clean project: Failed to delete > /usr/sup/apache-maven-3.8.6/.snapshot -> [Help 1] > > /usr/sup is on a NetApp volume. I did not ask for 'clean' on this install: > > % mvn -DdistributionTargetDir='/usr/sup/apache-maven-3.8.6' install > > I am a sysadmin, not a developer. My ideal is repeatable builds, so I would > prefer to have a way to do this that uses released software. End goal: a > professor wants Hadoop, and Hadoop wants to be installed with a newer version > of Maven than RHEL 7 provides. If I can't install Maven with Maven, I don't > expect that installing Hadoop with Maven will work either. > > Is there a way to tell Maven to ignore the .snapshot subdirectory in an > otherwise empty target directory? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven] rmannibucau commented on pull request #756: MNG-7501 display relative path to pom.xml
rmannibucau commented on PR #756: URL: https://github.com/apache/maven/pull/756#issuecomment-1162093910 > I don't understand Using one logger per concern we get the needed info at will and we dont have the over-verbose output issue anymore so it enables more data injection user could activate at need. > it seems your original use case is not mine Can be but the fact this pr can be seen as bothering and does not generally works with maven remains so not sure it is good to get it onboard as this, no? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7501) display relative path to pom.xml
[
https://issues.apache.org/jira/browse/MNG-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557030#comment-17557030
]
ASF GitHub Bot commented on MNG-7501:
-
rmannibucau commented on PR #756:
URL: https://github.com/apache/maven/pull/756#issuecomment-1162093910
> I don't understand
Using one logger per concern we get the needed info at will and we dont have
the over-verbose output issue anymore so it enables more data injection user
could activate at need.
> it seems your original use case is not mine
Can be but the fact this pr can be seen as bothering and does not generally
works with maven remains so not sure it is good to get it onboard as this, no?
> display relative path to pom.xml
>
>
> Key: MNG-7501
> URL: https://issues.apache.org/jira/browse/MNG-7501
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.6
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> when building large multi-module project, when a failure happens in the
> middle of the build, it's not easy to even identify where the module is
> located in the source tree: Maven displays the module name, but not the path
> to pom.xml. Then often we have to read output log of goals that have run
> hoping to find a hint
> it would be nice to have by default the path to the pom.xml displayed during
> Maven run.
> I see 2 options:
> 1. either in the module build header:
> {noformat}
> [INFO] --< org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution
> >--
> [INFO] Building Maven IT Plugin :: Dependency Resolution 2.1-SNAPSHOT
> [31/78]
> [INFO]
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> [INFO] [ maven-plugin
> ]
> {noformat}
> 2. or in each goal execution line during the module build:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @
> maven-it-plugin-dependency-resolution
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> ---
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] cstamas commented on pull request #756: MNG-7501 display relative path to pom.xml
cstamas commented on PR #756: URL: https://github.com/apache/maven/pull/756#issuecomment-1162170761 > Generally speaking module name should be sufficient if dev did it right. Please do not be overly smart. Out users has really wildly complex builds, the fact that you tested with tomee and some handful of ASF (OSS, will become important later) project obviously does not mean you tested all out there :smile: For resolver users were testing on some (closed) projects that were _reported as faster_ with BF than with DF collector, something we with @michael-o were **never able to reproduce** (given the project in question is closed source). All I want to say: keep it simple instead "smart" and rely on some assumptions. You can always find someone who will outsmart you (in a good or a bad way). And you can always find crazy builds as well. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7501) display relative path to pom.xml
[
https://issues.apache.org/jira/browse/MNG-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557054#comment-17557054
]
ASF GitHub Bot commented on MNG-7501:
-
cstamas commented on PR #756:
URL: https://github.com/apache/maven/pull/756#issuecomment-1162170761
> Generally speaking module name should be sufficient if dev did it right.
Please do not be overly smart. Out users has really wildly complex builds,
the fact that you tested with tomee and some handful of ASF (OSS, will become
important later) project obviously does not mean you tested all out there
:smile:
For resolver users were testing on some (closed) projects that were
_reported as faster_ with BF than with DF collector, something we with
@michael-o were **never able to reproduce** (given the project in question is
closed source).
All I want to say: keep it simple instead "smart" and rely on some
assumptions. You can always find someone who will outsmart you (in a good or a
bad way). And you can always find crazy builds as well.
> display relative path to pom.xml
>
>
> Key: MNG-7501
> URL: https://issues.apache.org/jira/browse/MNG-7501
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.6
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> when building large multi-module project, when a failure happens in the
> middle of the build, it's not easy to even identify where the module is
> located in the source tree: Maven displays the module name, but not the path
> to pom.xml. Then often we have to read output log of goals that have run
> hoping to find a hint
> it would be nice to have by default the path to the pom.xml displayed during
> Maven run.
> I see 2 options:
> 1. either in the module build header:
> {noformat}
> [INFO] --< org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution
> >--
> [INFO] Building Maven IT Plugin :: Dependency Resolution 2.1-SNAPSHOT
> [31/78]
> [INFO]
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> [INFO] [ maven-plugin
> ]
> {noformat}
> 2. or in each goal execution line during the module build:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @
> maven-it-plugin-dependency-resolution
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> ---
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (MSITE-904) Unable to generate zh_TW locale of site document
Will created MSITE-904:
--
Summary: Unable to generate zh_TW locale of site document
Key: MSITE-904
URL: https://issues.apache.org/jira/browse/MSITE-904
Project: Maven Site Plugin
Issue Type: Bug
Components: doxia integration
Affects Versions: 3.11.0
Environment: Microsoft Windows [Version 10.0.19043.1766]
Reporter: Will
Attachments: image-2022-06-22-02-31-55-966.png
Here is my code: [https://github.com/doggy8088/mybatis-3/tree/patch-1]
I tried to run *mvn clean site* on my project. I expected to generate
*{{zh_TW}}* and *{{zh_CN}}* site in the *target/site* folder. But it didn't
generate it. Only *target/site/zh* been generated which means the *Apache Maven
Site Plugin* unable to distinguish between *{{zh_TW}}* and *{{zh_CN}}* locale.
I checked the source code in the
*src\main\java\org\apache\maven\plugins\site\render\AbstractSiteRenderingMojo.java*
file. This only read *locale.getLanguage()* and it just ignored the *Country*
or *Region* part of the locale totally.
!image-2022-06-22-02-31-55-966.png!
I think it's bug.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MSITE-904) Unable to generate zh_TW locale of site document
[
https://issues.apache.org/jira/browse/MSITE-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will updated MSITE-904:
---
Attachment: image-2022-06-22-02-42-48-237.png
image-2022-06-22-02-42-27-184.png
image-2022-06-22-02-42-09-288.png
image-2022-06-22-02-41-41-253.png
image-2022-06-22-02-41-22-889.png
image-2022-06-22-02-41-02-772.png
image-2022-06-22-02-40-32-419.png
Description:
Here is my code: [https://github.com/doggy8088/mybatis-3/tree/patch-1]
I tried to run *mvn clean site* on my project. I expected to generate
*{{zh_TW}}* and *{{zh_CN}}* site in the *target/site* folder. But it didn't
generate it. Only *target/site/zh* been generated which means the *Apache Maven
Site Plugin* unable to distinguish between *{{zh_TW}}* and *{{zh_CN}}* locale.
I checked the source code in the
*src\main\java\org\apache\maven\plugins\site\render\AbstractSiteRenderingMojo.java*
file. This only read *locale.getLanguage()* and it just ignored the *Country*
or *Region* part of the locale totally.
!image-2022-06-22-02-31-55-966.png!
!image-2022-06-22-02-40-32-419.png!
!image-2022-06-22-02-41-02-772.png!
!image-2022-06-22-02-41-22-889.png!
!image-2022-06-22-02-41-41-253.png!
!image-2022-06-22-02-42-09-288.png!
!image-2022-06-22-02-42-27-184.png!
!image-2022-06-22-02-42-48-237.png!
I think it's bug.
was:
Here is my code: [https://github.com/doggy8088/mybatis-3/tree/patch-1]
I tried to run *mvn clean site* on my project. I expected to generate
*{{zh_TW}}* and *{{zh_CN}}* site in the *target/site* folder. But it didn't
generate it. Only *target/site/zh* been generated which means the *Apache Maven
Site Plugin* unable to distinguish between *{{zh_TW}}* and *{{zh_CN}}* locale.
I checked the source code in the
*src\main\java\org\apache\maven\plugins\site\render\AbstractSiteRenderingMojo.java*
file. This only read *locale.getLanguage()* and it just ignored the *Country*
or *Region* part of the locale totally.
!image-2022-06-22-02-31-55-966.png!
I think it's bug.
> Unable to generate zh_TW locale of site document
>
>
> Key: MSITE-904
> URL: https://issues.apache.org/jira/browse/MSITE-904
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: doxia integration
>Affects Versions: 3.11.0
> Environment: Microsoft Windows [Version 10.0.19043.1766]
>Reporter: Will
>Priority: Critical
> Attachments: image-2022-06-22-02-31-55-966.png,
> image-2022-06-22-02-40-32-419.png, image-2022-06-22-02-41-02-772.png,
> image-2022-06-22-02-41-22-889.png, image-2022-06-22-02-41-41-253.png,
> image-2022-06-22-02-42-09-288.png, image-2022-06-22-02-42-27-184.png,
> image-2022-06-22-02-42-48-237.png
>
>
> Here is my code: [https://github.com/doggy8088/mybatis-3/tree/patch-1]
> I tried to run *mvn clean site* on my project. I expected to generate
> *{{zh_TW}}* and *{{zh_CN}}* site in the *target/site* folder. But it didn't
> generate it. Only *target/site/zh* been generated which means the *Apache
> Maven Site Plugin* unable to distinguish between *{{zh_TW}}* and *{{zh_CN}}*
> locale.
> I checked the source code in the
> *src\main\java\org\apache\maven\plugins\site\render\AbstractSiteRenderingMojo.java*
> file. This only read *locale.getLanguage()* and it just ignored the
> *Country* or *Region* part of the locale totally.
> !image-2022-06-22-02-31-55-966.png!
> !image-2022-06-22-02-40-32-419.png!
> !image-2022-06-22-02-41-02-772.png!
> !image-2022-06-22-02-41-22-889.png!
> !image-2022-06-22-02-41-41-253.png!
> !image-2022-06-22-02-42-09-288.png!
> !image-2022-06-22-02-42-27-184.png!
> !image-2022-06-22-02-42-48-237.png!
> I think it's bug.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] rmannibucau commented on pull request #756: MNG-7501 display relative path to pom.xml
rmannibucau commented on PR #756: URL: https://github.com/apache/maven/pull/756#issuecomment-1162178246 @cstamas exactly, using easy to get and very convention friendly builds we already hit issues, was the only point. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7501) display relative path to pom.xml
[
https://issues.apache.org/jira/browse/MNG-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557057#comment-17557057
]
ASF GitHub Bot commented on MNG-7501:
-
rmannibucau commented on PR #756:
URL: https://github.com/apache/maven/pull/756#issuecomment-1162178246
@cstamas exactly, using easy to get and very convention friendly builds we
already hit issues, was the only point.
> display relative path to pom.xml
>
>
> Key: MNG-7501
> URL: https://issues.apache.org/jira/browse/MNG-7501
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.6
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> when building large multi-module project, when a failure happens in the
> middle of the build, it's not easy to even identify where the module is
> located in the source tree: Maven displays the module name, but not the path
> to pom.xml. Then often we have to read output log of goals that have run
> hoping to find a hint
> it would be nice to have by default the path to the pom.xml displayed during
> Maven run.
> I see 2 options:
> 1. either in the module build header:
> {noformat}
> [INFO] --< org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution
> >--
> [INFO] Building Maven IT Plugin :: Dependency Resolution 2.1-SNAPSHOT
> [31/78]
> [INFO]
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> [INFO] [ maven-plugin
> ]
> {noformat}
> 2. or in each goal execution line during the module build:
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @
> maven-it-plugin-dependency-resolution
> core-it-support/core-it-plugins/maven-it-plugin-dependency-resolution/pom.xml
> ---
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] michael-o commented on pull request #755: [MNG-6965] Extensions suddenly have org.codehaus.plexus:plexus-utils:…
michael-o commented on PR #755: URL: https://github.com/apache/maven/pull/755#issuecomment-1162269472 @cstamas @hboutemy Any objections? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557086#comment-17557086
]
ASF GitHub Bot commented on MNG-6965:
-
michael-o commented on PR #755:
URL: https://github.com/apache/maven/pull/755#issuecomment-1162269472
@cstamas @hboutemy Any objections?
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.9.0-candidate, 4.0.0-alpha-1, 4.0.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> 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
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MSITE-904) Unable to generate zh_TW locale of site document
[
https://issues.apache.org/jira/browse/MSITE-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557108#comment-17557108
]
Michael Osipov commented on MSITE-904:
--
That's not a bug, but a feature. Long standing limitation that only the
language mattered. That will likely only change with the next major version.
> Unable to generate zh_TW locale of site document
>
>
> Key: MSITE-904
> URL: https://issues.apache.org/jira/browse/MSITE-904
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: doxia integration
>Affects Versions: 3.11.0
> Environment: Microsoft Windows [Version 10.0.19043.1766]
>Reporter: Will
>Priority: Critical
> Attachments: image-2022-06-22-02-31-55-966.png,
> image-2022-06-22-02-40-32-419.png, image-2022-06-22-02-41-02-772.png,
> image-2022-06-22-02-41-22-889.png, image-2022-06-22-02-41-41-253.png,
> image-2022-06-22-02-42-09-288.png, image-2022-06-22-02-42-27-184.png,
> image-2022-06-22-02-42-48-237.png
>
>
> Here is my code: [https://github.com/doggy8088/mybatis-3/tree/patch-1]
> I tried to run *mvn clean site* on my project. I expected to generate
> *{{zh_TW}}* and *{{zh_CN}}* site in the *target/site* folder. But it didn't
> generate it. Only *target/site/zh* been generated which means the *Apache
> Maven Site Plugin* unable to distinguish between *{{zh_TW}}* and *{{zh_CN}}*
> locale.
> I checked the source code in the
> *src\main\java\org\apache\maven\plugins\site\render\AbstractSiteRenderingMojo.java*
> file. This only read *locale.getLanguage()* and it just ignored the
> *Country* or *Region* part of the locale totally.
> !image-2022-06-22-02-31-55-966.png!
> !image-2022-06-22-02-40-32-419.png!
> !image-2022-06-22-02-41-02-772.png!
> !image-2022-06-22-02-41-22-889.png!
> !image-2022-06-22-02-41-41-253.png!
> !image-2022-06-22-02-42-09-288.png!
> !image-2022-06-22-02-42-27-184.png!
> !image-2022-06-22-02-42-48-237.png!
> I think it's bug.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
