[GitHub] [maven-release] cstamas commented on a diff in pull request #118: [MRELEASE-1087] Catch up
cstamas commented on code in PR #118: URL: https://github.com/apache/maven-release/pull/118#discussion_r865604908 ## maven-release-manager/pom.xml: ## @@ -98,14 +116,25 @@ commons-cli commons-cli - 1.2 + 1.5.0 Review Comment: Yup, look into org.apache.maven.shared.release.exec.InvokerMavenExecutor -- 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-release] cstamas commented on a diff in pull request #118: [MRELEASE-1087] Catch up
cstamas commented on code in PR #118: URL: https://github.com/apache/maven-release/pull/118#discussion_r865623124 ## maven-release-manager/pom.xml: ## @@ -98,14 +116,25 @@ commons-cli commons-cli - 1.2 + 1.5.0 Review Comment: See 820e774bbe892d2f1f0d77b8355216ad87d264ec -- 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-release] cstamas commented on a diff in pull request #118: [MRELEASE-1087] Catch up
cstamas commented on code in PR #118:
URL: https://github.com/apache/maven-release/pull/118#discussion_r865630699
##
maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/AbstractReleaseTestCase.java:
##
@@ -213,7 +213,13 @@ public FileVisitResult visitFile( Path file,
BasicFileAttributes attrs )
for ( MavenProject project : reactorProjects )
{
MavenProject resolvedProject = projectBuilder.build(
project.getFile(), buildingRequest ).getProject();
-
+
+// FIXME ... setDependencyArtifacts - set direct dependencies ...
+// but in
org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.createReleaseDependencies
+// getArtifacts is used ...
+
+// so we probably also need call setResolvedArtifacts
+
Review Comment:
For example, I have hard time to understand why release needs to resolve
anything at all...
--
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-release] cstamas commented on pull request #118: [MRELEASE-1087] Catch up
cstamas commented on PR #118: URL: https://github.com/apache/maven-release/pull/118#issuecomment-1118261446 I updated/fixed things reported so far, @slawekjaranowski did re-enable the failing UT GenerateReleasePomsPhaseTest (while he did disable several tests in it's parent class), but also there is that DefaultVersionInfoTest as well... So, I'd like to see some consensus about these changes and finally make this PR merged. But please note, that if there are some other pending PRs for upcoming release, better would be to merge those and update this PR, as am pretty sure this PR will render all existing PRs as "conflicted". -- 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] [Comment Edited] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532123#comment-17532123 ] Michael Osipov edited comment on MPDF-104 at 5/5/22 7:50 AM: - Please provide the PDF and steps to reproduce also. was (Author: michael-o): Please provide the PDF also. > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MRELEASE-1087) drop Plexus container APIs, move to JSR 330 + slf4j-api
[ https://issues.apache.org/jira/browse/MRELEASE-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MRELEASE-1087: -- Description: Mass changes to plugin: * update maven 3.0 -> 3.2.5 * update resolver from org.sonatype to org.eclipse package * off plexus XML, move fully to JSR330 * off plexus APIs like LogEnabled, Contextualize, etc * use slf4j API for logging instead of Plexus Logger * tests: off from Junit3 PlexusTestCase w/ XMLs to modern(er) Junit 4 * tests: off from PlexusTestCase XMLs (one exception remains) * reformat was:https://github.com/apache/maven-release/pull/118 > drop Plexus container APIs, move to JSR 330 + slf4j-api > --- > > Key: MRELEASE-1087 > URL: https://issues.apache.org/jira/browse/MRELEASE-1087 > Project: Maven Release Plugin > Issue Type: Task >Affects Versions: 3.0.0-M5 >Reporter: Herve Boutemy >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.0.0-M6 > > > Mass changes to plugin: > * update maven 3.0 -> 3.2.5 > * update resolver from org.sonatype to org.eclipse package > * off plexus XML, move fully to JSR330 > * off plexus APIs like LogEnabled, Contextualize, etc > * use slf4j API for logging instead of Plexus Logger > * tests: off from Junit3 PlexusTestCase w/ XMLs to modern(er) Junit 4 > * tests: off from PlexusTestCase XMLs (one exception remains) > * reformat -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532123#comment-17532123 ] Michael Osipov commented on MPDF-104: - Please provide the PDF also. > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] weibo1995 opened a new pull request, #172: Fix the problem that the dependency tree is different when DF and BF …
weibo1995 opened a new pull request, #172: URL: https://github.com/apache/maven-resolver/pull/172 Fix the problem that the dependency tree is different when DF and BF strategies are adopted when a dependency package has no children dependency. When BF is adopted, when a dependent package has no children dependency, it will not continue to call the doRecurse() method, that is, it will not call the CacheManager.cachewinner() to put this dependency package into the winnerGAs object, which affects the analysis results of dependency packages of the same GA. The current fix is to call the CacheManager.cachewinner() method when a dependent package has no children dependency, so that the dependent package can be found in winnerGAs. We take the dependency in the following figure as an example to illustrate the generation process of the problem.  At org eclipse. aether. internal. impl. Bfdependencycollector #collectdependencies() mainly has two stages: processdependency() and transformer.transformGraph( node, context )。 In the first stage of process dependency: 1. When parsing to D1, descriptorResult.getDependencies().isEmpty(), so doRecurse() will not be executed Therefore, args.skipper.cache() will not be executed. The D1 will not exist in winnerGAs in the end. 2. When parsing D2 of the same layer, because there is no same GA in winnerGAs, D2 and its children dependencies （ G1 and H1） will be parsed. 3. When resolving to G2 on the same layer as G1, because winnerGAs already has G1, the resolution of the children dependencies of G2 will be skipped, that is, H2 will not be resolved. Then, to the second stage, transformgraph: 4. Because D1 has the same depth as D2, D1 wins, that is, D2 and its children are eliminated, including G1 5. Because G1 was eliminated, G2 won. Finally, the final dependency tree obtained by BF strategy is as follows:  But the dependency tree obtained by DF is as follows:  That is, in the final generated dependency tree, BF has less children dependency of G2 than DF. Signed-off-by: hongbo.weihb -- 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-resolver] cstamas commented on pull request #172: Fix the problem that the dependency tree is different when DF and BF …
cstamas commented on PR #172: URL: https://github.com/apache/maven-resolver/pull/172#issuecomment-1118313118 @weibo1995 could you craft a project that produces different trees on current master? As we could add it as UT... -- 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-release] cstamas commented on pull request #106: [MRELEASE-1084] Upgrade Maven to 3.2.5
cstamas commented on PR #106: URL: https://github.com/apache/maven-release/pull/106#issuecomment-1118314843 Isn't this superseded by https://github.com/apache/maven-release/pull/118 ? -- 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] [Updated] (MRELEASE-1087) Upgrade Maven to 3.2.5 (and de-plexus)
[ https://issues.apache.org/jira/browse/MRELEASE-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MRELEASE-1087: -- Summary: Upgrade Maven to 3.2.5 (and de-plexus) (was: drop Plexus container APIs, move to JSR 330 + slf4j-api) > Upgrade Maven to 3.2.5 (and de-plexus) > -- > > Key: MRELEASE-1087 > URL: https://issues.apache.org/jira/browse/MRELEASE-1087 > Project: Maven Release Plugin > Issue Type: Task >Affects Versions: 3.0.0-M5 >Reporter: Herve Boutemy >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.0.0-M6 > > > Mass changes to plugin: > * update maven 3.0 -> 3.2.5 > * update resolver from org.sonatype to org.eclipse package > * off plexus XML, move fully to JSR330 > * off plexus APIs like LogEnabled, Contextualize, etc > * use slf4j API for logging instead of Plexus Logger > * tests: off from Junit3 PlexusTestCase w/ XMLs to modern(er) Junit 4 > * tests: off from PlexusTestCase XMLs (one exception remains) > * reformat -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MRELEASE-1084) Upgrade Maven to 3.2.5
[ https://issues.apache.org/jira/browse/MRELEASE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MRELEASE-1084. - Resolution: Duplicate > Upgrade Maven to 3.2.5 > -- > > Key: MRELEASE-1084 > URL: https://issues.apache.org/jira/browse/MRELEASE-1084 > Project: Maven Release Plugin > Issue Type: Task >Reporter: Michael Osipov >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-release] cstamas commented on pull request #106: [MRELEASE-1084] Upgrade Maven to 3.2.5
cstamas commented on PR #106: URL: https://github.com/apache/maven-release/pull/106#issuecomment-1118316855 Am closing this out, please reopen if needed -- 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-release] cstamas closed pull request #106: [MRELEASE-1084] Upgrade Maven to 3.2.5
cstamas closed pull request #106: [MRELEASE-1084] Upgrade Maven to 3.2.5 URL: https://github.com/apache/maven-release/pull/106 -- 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-release] slawekjaranowski commented on a diff in pull request #118: [MRELEASE-1087] Catch up
slawekjaranowski commented on code in PR #118:
URL: https://github.com/apache/maven-release/pull/118#discussion_r865711326
##
maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/AbstractReleaseTestCase.java:
##
@@ -213,7 +213,13 @@ public FileVisitResult visitFile( Path file,
BasicFileAttributes attrs )
for ( MavenProject project : reactorProjects )
{
MavenProject resolvedProject = projectBuilder.build(
project.getFile(), buildingRequest ).getProject();
-
+
+// FIXME ... setDependencyArtifacts - set direct dependencies ...
+// but in
org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.createReleaseDependencies
+// getArtifacts is used ...
+
+// so we probably also need call setResolvedArtifacts
+
Review Comment:
And why we need use `setDependencyArtifacts` directly ...
code is also strange for me we check:
```
if ( project.getDependencyArtifacts() == null )
```
and next on different object
```
resolvedProject.setDependencyArtifacts()
```
I will check what happens if I call
```
resolvedProject.setResolvedArtifacts(
resolvedProject.getDependencyArtifacts() )
```
of course I don't understand it very 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
[GitHub] [maven-resolver] weibo1995 commented on pull request #172: Fix the problem that the dependency tree is different when DF and BF …
weibo1995 commented on PR #172: URL: https://github.com/apache/maven-resolver/pull/172#issuecomment-1118351584 > @weibo1995 could you craft a project that produces different trees on current master? As we could add it as UT... OK, let me add UT, thanks. -- 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-resolver] michael-o commented on pull request #172: Fix the problem that the dependency tree is different when DF and BF …
michael-o commented on PR #172: URL: https://github.com/apache/maven-resolver/pull/172#issuecomment-1118382980 @weibo1995 Very interesting, thank you! -- 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-resolver] weibo1995 commented on pull request #172: Fix the problem that the dependency tree is different when DF and BF …
weibo1995 commented on PR #172: URL: https://github.com/apache/maven-resolver/pull/172#issuecomment-1118452685 > @weibo1995 could you craft a project that produces different trees on current master? As we could add it as UT... https://github.com/apache/maven-resolver/pull/172/commits/586eaadf358dba607dd2be10ff3756b064aed20f thanks. -- 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-resolver] cstamas commented on pull request #172: Fix the problem that the dependency tree is different when DF and BF …
cstamas commented on PR #172: URL: https://github.com/apache/maven-resolver/pull/172#issuecomment-1118493360 Note to myself: after this PR is merged, we should pull up the "common" tests from DfDependencyCollectorTest and BfDependencyCollectorTest as they should cover pretty much same stuff, leave in UT classes only the specific tests. For example, this new test should be pulled up, as both should produce "same result"! -- 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] [Closed] (MBUILDCACHE-15) maven.build.cache.enabled parameter is broken
[ https://issues.apache.org/jira/browse/MBUILDCACHE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MBUILDCACHE-15. -- Resolution: Fixed > maven.build.cache.enabled parameter is broken > - > > Key: MBUILDCACHE-15 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-15 > Project: Maven Build Cache Extension > Issue Type: Bug >Reporter: Maximilian Novikov >Priority: Major > Labels: pull-request-available > > $ mvn install -DskipTests -P versionlessMavenDist > -Dmaven.build.cache.enabled=false > [INFO] Cache disabled by command line flag, project will be built fully and > not cached > [ERROR] Internal error: com.google.inject.ProvisionException: Unable to > provision, see the following errors: > [ERROR] > [ERROR] 1) Error injecting constructor, java.lang.IllegalStateException: > Cache is not initialized. Actual state: DISABLED > [ERROR] at > org.apache.maven.buildcache.RemoteCacheRepositoryProvider.(Unknown > Source) > [ERROR] at > ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.0.0-SNAPSHOT, > parent: ClassRealm[plexus.core, parent: null]] (via modules: > org.eclipse.sisu.wire.WireModule -> > org.eclipse.sisu.plexus.PlexusBindingModule) > [ERROR] while locating > org.apache.maven.buildcache.RemoteCacheRepositoryProvider > [ERROR] at > ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.0.0-SNAPSHOT, > parent: ClassRealm[plexus.core, parent: null]] (via modules: > org.eclipse.sisu.wire.WireModule -> > org.eclipse.sisu.plexus.PlexusBindingModule) > [ERROR] while locating org.apache.maven.buildcache.RemoteCacheRepository > annotated with @com.google.inject.name.Named(value="#factory#") > [ERROR] at org.eclipse.sisu.wire.LocatorWiring > [ERROR] while locating org.apache.maven.buildcache.RemoteCacheRepository > [ERROR] for the 1st parameter of > org.apache.maven.buildcache.LocalCacheRepositoryImpl.(Unknown Source) > [ERROR] at > ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.0.0-SNAPSHOT, > parent: ClassRealm[plexus.core, parent: null]] (via modules: > org.eclipse.sisu.wire.WireModule -> > org.eclipse.sisu.plexus.PlexusBindingModule) > [ERROR] while locating org.apache.maven.buildcache.LocalCacheRepositoryImpl > [ERROR] while locating java.lang.Object annotated with * > [ERROR] at org.eclipse.sisu.wire.LocatorWiring > [ERROR] while locating org.apache.maven.buildcache.LocalCacheRepository > [ERROR] for the 5th parameter of > org.apache.maven.buildcache.CacheControllerImpl.(Unknown Source) > [ERROR] at > ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.0.0-SNAPSHOT, > parent: ClassRealm[plexus.core, parent: null]] (via modules: > org.eclipse.sisu.wire.WireModule -> > org.eclipse.sisu.plexus.PlexusBindingModule) > [ERROR] while locating org.apache.maven.buildcache.CacheControllerImpl > [ERROR] while locating java.lang.Object annotated with * > [ERROR] at org.eclipse.sisu.wire.LocatorWiring > [ERROR] while locating org.apache.maven.buildcache.CacheController > [ERROR] for the 2nd parameter of > org.apache.maven.buildcache.CacheLifecycleParticipant.(Unknown Source) > [ERROR] at > ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.0.0-SNAPSHOT, > parent: ClassRealm[plexus.core, parent: null]] (via modules: > org.eclipse.sisu.wire.WireModule -> > org.eclipse.sisu.plexus.PlexusBindingModule) > [ERROR] while locating org.apache.maven.buildcache.CacheLifecycleParticipant > [ERROR] while locating java.lang.Object annotated with * > [ERROR] > [ERROR] 1 error > [ERROR] -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: > com.google.inject.ProvisionException: Unable to provision, see the following > errors: > 1) Error injecting constructor, java.lang.IllegalStateException: Cache is not > initialized. Actual state: DISABLED > at org.apache.maven.buildcache.RemoteCacheRepositoryProvider.(Unknown > Source) > at > ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.0.0-SNAPSHOT, > parent: ClassRealm[plexus.core, parent: null]] (via modules: > org.eclipse.sisu.wire.WireModule -> > org.eclipse.sisu.plexus.PlexusBindingModule) > while locating org.apache.maven.buildcache.RemoteCacheRepositoryProvider > at > ClassRealm[coreExtension>org.apache.maven.extensions:maven-build-cache-extension:1.0.0-SNAPSHOT, > parent: ClassRealm[plexus.core, parent: null]] (via modules: > org.eclipse.sisu.wire.WireModule -> > org.eclipse.sisu.plexus.PlexusBindingModule) > while locating org.apache.maven.buildcache.RemoteCacheRepository annotated > with @com.google.inject.name.Named(value="#factory#") > a
[jira] [Created] (MBUILDCACHE-17) IllegalStateException: Cache is not initialized. Actual state: null
Guillaume Nodet created MBUILDCACHE-17:
--
Summary: IllegalStateException: Cache is not initialized. Actual
state: null
Key: MBUILDCACHE-17
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-17
Project: Maven Build Cache Extension
Issue Type: Bug
Reporter: Guillaume Nodet
Building a clean version of https://github.com/apache/camel.git produces the
following exception:
{code}
[ERROR] Camel :: Maven Plugins :: Enhanced Bundle Plugin: Failed to calculate
checksums for camel-bundle-plugin: Cache is not initialized. Actual state: null
java.lang.RuntimeException: Camel :: Maven Plugins :: Enhanced Bundle Plugin:
Failed to calculate checksums for camel-bundle-plugin
at
org.mvndaemon.mvnd.builder.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:183)
at
org.mvndaemon.mvnd.builder.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:198)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.RuntimeException: Failed to calculate checksums for
camel-bundle-plugin
at
org.apache.maven.buildcache.DefaultProjectInputCalculator.calculateInputInternal(DefaultProjectInputCalculator.java:120)
at
org.apache.maven.buildcache.DefaultProjectInputCalculator.calculateInput(DefaultProjectInputCalculator.java:88)
at
org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild(CacheControllerImpl.java:166)
at
org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute(BuildCacheMojosExecutionStrategy.java:109)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:173)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
at
org.mvndaemon.mvnd.builder.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:178)
... 6 common frames omitted
Caused by: java.lang.IllegalStateException: Cache is not initialized. Actual
state: null
at
org.apache.maven.buildcache.xml.CacheConfigImpl.checkInitializedState(CacheConfigImpl.java:644)
at
org.apache.maven.buildcache.xml.CacheConfigImpl.getDefaultGlob(CacheConfigImpl.java:402)
at
org.apache.maven.buildcache.checksum.MavenProjectInput.(MavenProjectInput.java:163)
at
org.apache.maven.buildcache.DefaultProjectInputCalculator.calculateInputInternal(DefaultProjectInputCalculator.java:107)
... 12 common frames omitted
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-assembly-plugin] cstamas commented on pull request #55: [MASSEMBLY-956] Resolve only what is needed for final assembly
cstamas commented on PR #55: URL: https://github.com/apache/maven-assembly-plugin/pull/55#issuecomment-1118572926 anyone else has anything to add here? Maybe some idea to improve added test? (as it is fragile, in a sense that if any other IT would use "banned" dependency AND it would execute before this IT, it would produce false positive -- 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] [Created] (MDEP-805) artifactItem documentation
Ewa Śliwińska created MDEP-805:
--
Summary: artifactItem documentation
Key: MDEP-805
URL: https://issues.apache.org/jira/browse/MDEP-805
Project: Maven Dependency Plugin
Issue Type: Improvement
Reporter: Ewa Śliwińska
I'm trying to find information about {_}type{_}, _overWrite_ and
_outputDirectory_ tags in _artifactItem_ in _unpack_ goal (if they are
mandatory and what should be their content).
When googling, I'm finding those two sites:
* [Apache Maven Dependency Plugin –
dependency:unpack|https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html]
* [Apache Maven Dependency Plugin –
Usage|https://maven.apache.org/plugins/maven-dependency-plugin/usage.html]
The former roughly mentions what the _artifactItem_ contains, but without
detailed explanation.
The latter shows an example, but also does not specify the possible contents in
details. Also it says
{quote}A default outputDirectory is specified
{quote}
but doesn't mention what is the default.
Could you please add more comprehensive description of those tags?
Thank you in advance.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MDEP-805) artifactItem documentation
[
https://issues.apache.org/jira/browse/MDEP-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532289#comment-17532289
]
Slawomir Jaranowski commented on MDEP-805:
--
https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html#outputdirectory
{quote}
Default: ${project.build.directory}/dependency
{quote}
There is example and description of {{artifactItem}}
https://maven.apache.org/plugins/maven-dependency-plugin/usage.html#dependency-unpack
second box ... pleas scroll page .. or search word {{artifactItem}} on this
page.
> artifactItem documentation
> --
>
> Key: MDEP-805
> URL: https://issues.apache.org/jira/browse/MDEP-805
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Reporter: Ewa Śliwińska
>Priority: Minor
>
> I'm trying to find information about {_}type{_}, _overWrite_ and
> _outputDirectory_ tags in _artifactItem_ in _unpack_ goal (if they are
> mandatory and what should be their content).
> When googling, I'm finding those two sites:
> * [Apache Maven Dependency Plugin –
> dependency:unpack|https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html]
> * [Apache Maven Dependency Plugin –
> Usage|https://maven.apache.org/plugins/maven-dependency-plugin/usage.html]
> The former roughly mentions what the _artifactItem_ contains, but without
> detailed explanation.
> The latter shows an example, but also does not specify the possible contents
> in details. Also it says
> {quote}A default outputDirectory is specified
> {quote}
> but doesn't mention what is the default.
> Could you please add more comprehensive description of those tags?
> Thank you in advance.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-assembly-plugin] gnodet commented on a diff in pull request #55: [MASSEMBLY-956] Resolve only what is needed for final assembly
gnodet commented on code in PR #55:
URL:
https://github.com/apache/maven-assembly-plugin/pull/55#discussion_r866052752
##
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java:
##
@@ -183,7 +185,12 @@ void addDependencySet( final DependencySet dependencySet,
final Archiver archive
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+MavenSession mavenSession = configSource.getMavenSession();
+return new DefaultProjectBuildingRequest()
+.setRepositorySession( mavenSession.getRepositorySession() )
+.setSystemProperties( mavenSession.getSystemProperties() )
+.setUserProperties( mavenSession.getUserProperties() )
+.setProcessPlugins( false );
}
Review Comment:
Why not reusing the existing `ProjectBuildingRequest` ? What does that
actually change ?
Shouldn't that be something like:
```
return new DefaultProjectBuildingRequest(
configSource.getMavenSession().getProjectBuildingRequest() )
.setProcessPlugins( false );
```
I fear not reusing the existing will loose remote repositories and other
settings, not sure though.
--
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-assembly-plugin] cstamas commented on a diff in pull request #55: [MASSEMBLY-956] Resolve only what is needed for final assembly
cstamas commented on code in PR #55:
URL:
https://github.com/apache/maven-assembly-plugin/pull/55#discussion_r866097262
##
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java:
##
@@ -183,7 +185,12 @@ void addDependencySet( final DependencySet dependencySet,
final Archiver archive
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+MavenSession mavenSession = configSource.getMavenSession();
+return new DefaultProjectBuildingRequest()
+.setRepositorySession( mavenSession.getRepositorySession() )
+.setSystemProperties( mavenSession.getSystemProperties() )
+.setUserProperties( mavenSession.getUserProperties() )
+.setProcessPlugins( false );
}
Review Comment:
Reusing it with copy-ctor, as setter of processPlugins modifies the existing
instance.
--
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-resolver] cstamas commented on pull request #172: Fix the problem that the dependency tree is different when DF and BF …
cstamas commented on PR #172: URL: https://github.com/apache/maven-resolver/pull/172#issuecomment-1118784209 Locally verified: took test doe and test resources from this PR (but NOT the FIX), and copied it to BF and DF UT. I expected BF to fail and DF to pass. And that exactly happened: ``` [INFO] Results: [INFO] [ERROR] Failures: [ERROR] BfDependencyCollectorUseSkipTest>BfDependencyCollectorTest.testDescriptorDependenciesEmpty:601->BfDependencyCollectorTest.assertEqualSubtree:133->BfDependencyCollectorTest.assertEqualSubtree:163->BfDependencyCollectorTest.assertEqualSubtree:163->BfDependencyCollectorTest.assertEqualSubtree:163->BfDependencyCollectorTest.assertEqualSubtree:155 path: [gid:a:jar:ver (), gid:e:jar:ver (compile), gid:f:jar:ver (compile), gid:g:jar:2 (compile)], expected: [gid:h:jar:2 (compile)], actual: [] expected:<1> but was:<0> [INFO] [ERROR] Tests run: 299, Failures: 1, Errors: 0, Skipped: 0 ``` -- 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-resources-plugin] pzygielo opened a new pull request, #26: (doc) Fix XML formatting
pzygielo opened a new pull request, #26: URL: https://github.com/apache/maven-resources-plugin/pull/26 Similar to - #15 -- 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-resolver] michael-o commented on pull request #172: Fix the problem that the dependency tree is different when DF and BF …
michael-o commented on PR #172: URL: https://github.com/apache/maven-resolver/pull/172#issuecomment-1118837058 JIRA issue please -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resources-plugin] slawekjaranowski merged pull request #26: (doc) Fix XML formatting
slawekjaranowski merged PR #26: URL: https://github.com/apache/maven-resources-plugin/pull/26 -- 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-resources-plugin] slawekjaranowski commented on pull request #26: (doc) Fix XML formatting
slawekjaranowski commented on PR #26: URL: https://github.com/apache/maven-resources-plugin/pull/26#issuecomment-1118876919 Thanks. -- 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] (MRESOLVER-62) Resolver can skip cyclic dependencies underneath removed nodes
[
https://issues.apache.org/jira/browse/MRESOLVER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532455#comment-17532455
]
Michael Osipov commented on MRESOLVER-62:
-
[~thammett], 1.8.0 is out. Can you verify?
> Resolver can skip cyclic dependencies underneath removed nodes
> --
>
> Key: MRESOLVER-62
> URL: https://issues.apache.org/jira/browse/MRESOLVER-62
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Toby Hammett
>Priority: Critical
> Labels: intern
> Attachments: maven-resolver-cycle-underneath-removed-node.patch
>
>
> While updating dependencies in one of my company's Maven projects, I got a
> StackOverflowError involving infinite recursion at
> {{org.apache.maven.RepositoryUtils#toArtifacts}}. After some investigation, I
> believe I have traced the issue to a bug in ConflictResolver which can occur
> when encountering multiple dependency cycles. Specifically, I think the
> criteria for failure are:
> * One cycle appears nearer to the root than the other cycle as a child of a
> node that will be removed.
> * That cycle is also a child of the other cycle elsewhere in the dependency
> graph.
> For example, here is a dependency graph analogous to the one I was working
> with when I encountered the StackOverflowError:
> {noformat}
> (null)
> +- gid:a:1
> | \- gid:x:1 (x)
> | \- gid:y:1
> |\- ^x
> +- gid:a:2
> +- gid:b:1
> | +- gid:c:1
> | \- gid:d:1 (d)
> |\- ^x
> \- gid:m:1
>\- gid:n:1
> +- gid:p:1
> | \- gid:q:1
> \- gid:q:2
> \- gid:p:2
> \- ^d
> {noformat}
> This graph has a cycle ({{x}} and {{y}}) underneath a node that is removed
> from the tree ({{a:1}}). This cycle also appears as a child of another cycle.
> Specifically, {{q}} and {{p}} depends on {{d}}, which depends on {{x}}.
> After conflicts are resolved in this graph, the node for {{gid:y:1}} still
> has a reference to {{gid:x:1}}, although I believe it should have been
> removed. This cycle in the graph led to the StackOverflowError I observed.
> Another example, derived from the first, shows a slightly different problem:
> {noformat}
> (null)
> +- gid:a:1
> | \- gid:x:1 (x)
> | \- gid:y:1
> |\- ^x
> +- gid:a:2
> \- gid:m:1
>\- gid:n:1
> +- gid:p:1
> | \- gid:q:1
> \- gid:q:2
> |- gid:p:2
> \- ^x
> {noformat}
> In this case, as with the first, there is a cycle underneath a node that will
> be removed. That cycle ({{x}} and {{y}}) is also a dependency of node
> {{gid:q:2}}, which is itself a member of a cycle with {{p}}. When conflicts
> are resolved in this case, the resulting graph does not contain {{gid:x:1}}
> at all!
>
> A potential workaround for this issue is to declare a direct dependency on
> one of the artifacts in the cycle that is not handled correctly.
>
> I have attached a patch for maven-resolver-util which adds both of the
> preceding examples as unit tests. Please let me know if there's any other
> information I can provide.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-fluido-skin] kwin commented on a diff in pull request #23: [MSKINS-169] Image height not effective
kwin commented on code in PR #23: URL: https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866167000 ## src/main/resources/META-INF/maven/site-macros.vm: ## @@ -110,21 +110,21 @@ #**##set ( $imgAlt = ' alt=""' ) #* *##end #* *##if( $border ) -#**##set ( $imgBorder = ' border="' + $border + '"' ) +#**##set ( $imgBorder = 'border: ' + $border + ';' ) #* *##else #**##set ( $imgBorder = "" ) #* *##end #* *##if( $width ) -#**##set ( $imgWidth = ' width="' + $width + '"' ) +#**##set ( $imgWidth = 'width: ' + $width + ';' ) #* *##else #**##set ( $imgWidth = "" ) #* *##end #* *##if( $height ) -#**##set ( $imgHeight = ' height="' + $height + '"' ) +#**##set ( $imgHeight = 'height: ' + $height + ';' ) #* *##else #**##set ( $imgHeight = "" ) #* *##end -## +## Review Comment: This will add two superfluous spaces in case both `$imgBorder` and `$imgWidth` are both empty. I would recommend doing the concatenation without spaces and make each variable be either the empty string or end with a space. That way you only have at most one superfluous space at the end. ## src/main/resources/META-INF/maven/site-macros.vm: ## @@ -110,21 +110,21 @@ #**##set ( $imgAlt = ' alt=""' ) #* *##end #* *##if( $border ) -#**##set ( $imgBorder = ' border="' + $border + '"' ) +#**##set ( $imgBorder = 'border: ' + $border + ';' ) Review Comment: This should be rather `border-width` (https://developer.mozilla.org/en-US/docs/Web/CSS/border-width) as the css attribute `border` may also set other styles and may lead to some ambiguity and `border-width` is the equivalent of the `border` html attribute. The spec is not really clear in this regard though: https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft -- 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] [Created] (MRESOLVER-256) Dependency tree is different between DF and BF strategies when a dependency package has no indirect dependencies
Michael Osipov created MRESOLVER-256: Summary: Dependency tree is different between DF and BF strategies when a dependency package has no indirect dependencies Key: MRESOLVER-256 URL: https://issues.apache.org/jira/browse/MRESOLVER-256 Project: Maven Resolver Issue Type: Bug Components: Resolver Affects Versions: 1.8.0 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 1.8.1 >From GitHub: Fix the problem that the dependency tree is different when DF and BF strategies are adopted when a dependency package has no children dependency. When BF is adopted, when a dependent package has no children dependency, it will not continue to call the doRecurse() method, that is, it will not call the CacheManager.cachewinner() to put this dependency package into the winnerGAs object, which affects the analysis results of dependency packages of the same GA. The current fix is to call the CacheManager.cachewinner() method when a dependent package has no children dependency and it is not skip resolution, so that the dependent package can be found in winnerGAs. We take the dependency in the following figure as an example to illustrate the generation process of the problem. https://user-images.githubusercontent.com/104960983/166911972-6d721f62-ea17-46fc-af60-181aa5fdb041.png";> At org eclipse. aether. internal. impl. Bfdependencycollector #collectdependencies() mainly has two stages: processdependency() and transformer.transformGraph( node, context )。 In the first stage of process dependency: 1. When parsing to D1, descriptorResult.getDependencies().isEmpty(), so doRecurse() will not be executed. Therefore, args.skipper.cache() will not be executed. The D1 will not exist in winnerGAs in the end.  2. When parsing D2 of the same layer, because there is no same GA in winnerGAs, D2 and its children dependencies （ G1 and H1） will be parsed. 3. When resolving to G2 on the same layer as G1, because winnerGAs already has G1, the resolution of the children dependencies of G2 will be skipped, that is, H2 will not be resolved. Then, to the second stage, transformgraph: 4. Because D1 has the same depth as D2, D1 wins, that is, D2 and its children are eliminated, including G1 5. Because G1 was eliminated, G2 won. Finally, the final dependency tree obtained by BF strategy is as follows: https://user-images.githubusercontent.com/104960983/166912027-21d7fcd4-79bd-43cc-80c8-0088091a91ef.png";> But the dependency tree obtained by DF is as follows: https://user-images.githubusercontent.com/104960983/166912045-2cff5bd6-f54d-4faa-a955-6c985923058a.png";> That is, in the final generated dependency tree, BF has less children dependency of G2 than DF. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] asfgit closed pull request #172: Fix the problem that the dependency tree is different when DF and BF …
asfgit closed pull request #172: Fix the problem that the dependency tree is different when DF and BF … URL: https://github.com/apache/maven-resolver/pull/172 -- 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] [Closed] (MRESOLVER-256) Dependency tree is different between DF and BF strategies when a dependency package has no indirect dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-256. Resolution: Fixed Fixed with [2ea36519a72079b9efa59c6278b15bfb01a53fb4|https://gitbox.apache.org/repos/asf?p=maven-resolver.git&a=commit&h=2ea36519a72079b9efa59c6278b15bfb01a53fb4]. > Dependency tree is different between DF and BF strategies when a dependency > package has no indirect dependencies > > > Key: MRESOLVER-256 > URL: https://issues.apache.org/jira/browse/MRESOLVER-256 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.8.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.1 > > > From GitHub: > Fix the problem that the dependency tree is different when DF and BF > strategies are adopted when a dependency package has no children dependency. > When BF is adopted, when a dependent package has no children dependency, it > will not continue to call the doRecurse() method, that is, it will not call > the CacheManager.cachewinner() to put this dependency package into the > winnerGAs object, which affects the analysis results of dependency packages > of the same GA. The current fix is to call the CacheManager.cachewinner() > method when a dependent package has no children dependency and it is not skip > resolution, so that the dependent package can be found in winnerGAs. > We take the dependency in the following figure as an example to illustrate > the generation process of the problem. > src="https://user-images.githubusercontent.com/104960983/166911972-6d721f62-ea17-46fc-af60-181aa5fdb041.png";> > At org eclipse. aether. internal. impl. Bfdependencycollector > #collectdependencies() mainly has two stages: processdependency() and > transformer.transformGraph( node, context )。 > In the first stage of process dependency: > 1. When parsing to D1, descriptorResult.getDependencies().isEmpty(), so > doRecurse() will not be executed. Therefore, args.skipper.cache() will not be > executed. The D1 will not exist in winnerGAs in the end. >  > 2. When parsing D2 of the same layer, because there is no same GA in > winnerGAs, D2 and its children dependencies （ G1 and H1） will be parsed. > 3. When resolving to G2 on the same layer as G1, because winnerGAs already > has G1, the resolution of the children dependencies of G2 will be skipped, > that is, H2 will not be resolved. > Then, to the second stage, transformgraph: > 4. Because D1 has the same depth as D2, D1 wins, that is, D2 and its children > are eliminated, including G1 > 5. Because G1 was eliminated, G2 won. > Finally, the final dependency tree obtained by BF strategy is as follows: > src="https://user-images.githubusercontent.com/104960983/166912027-21d7fcd4-79bd-43cc-80c8-0088091a91ef.png";> > But the dependency tree obtained by DF is as follows: > src="https://user-images.githubusercontent.com/104960983/166912045-2cff5bd6-f54d-4faa-a955-6c985923058a.png";> > That is, in the final generated dependency tree, BF has less children > dependency of G2 than DF. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSKINS-170) Allow to show name as headline in addition to bannerLeft
[ https://issues.apache.org/jira/browse/MSKINS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532470#comment-17532470 ] Konrad Windszus commented on MSKINS-170: The h2 is actually coming from macro `banner` with a banner object not containing a `src` property: https://github.com/apache/maven-fluido-skin/blob/7e92f9bb3c6efffb99c3708444957e153c55dd37/src/main/resources/META-INF/maven/site-macros.vm#L182 So it seems there are two different fallbacks here: a) for a site definition not containing a `bannerLeft` (https://github.com/apache/maven-fluido-skin/blob/7e92f9bb3c6efffb99c3708444957e153c55dd37/src/main/resources/META-INF/maven/site.vm#L189) b) for a site definition containing a `bannerLeft` without `src` (https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft) In the case of https://sling.apache.org/components/scriptingbundle-maven-plugin-archives/scriptingbundle-maven-plugin-0.3.0/ the site.xml looks like https://github.com/apache/sling-scriptingbundle-maven-plugin/blob/scriptingbundle-maven-plugin-0.3.0/src/site/site.xml (and inherits from ASF Parent 23 through https://github.com/apache/sling-parent/blob/sling-parent-reactor-41/sling-parent/pom.xml which doesn't contain any site.xml), so it is unclear to me why we run into fallback b) instead of a). [~hboutemy] Any idea since you implemented both fallbacks? > Allow to show name as headline in addition to bannerLeft > > > Key: MSKINS-170 > URL: https://issues.apache.org/jira/browse/MSKINS-170 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.9 >Reporter: Konrad Windszus >Priority: Major > > Currently there is a fallback with text in case no bannerLeft is configured: > https://github.com/apache/maven-fluido-skin/blob/f966972c504c8a01a5d7a203de6438464877a8bd/src/main/resources/META-INF/maven/site.vm#L188. > It would be nice to optionally show that next to the banner. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MSKINS-170) Allow to show name as headline in addition to bannerLeft
[ https://issues.apache.org/jira/browse/MSKINS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532470#comment-17532470 ] Konrad Windszus edited comment on MSKINS-170 at 5/5/22 6:18 PM: The h2 is actually coming from macro `banner` with a banner object not containing a `src` property: https://github.com/apache/maven-fluido-skin/blob/7e92f9bb3c6efffb99c3708444957e153c55dd37/src/main/resources/META-INF/maven/site-macros.vm#L182 So it seems there are two different fallbacks here: a) for a site definition not containing a `bannerLeft` (https://github.com/apache/maven-fluido-skin/blob/7e92f9bb3c6efffb99c3708444957e153c55dd37/src/main/resources/META-INF/maven/site.vm#L191) b) for a site definition containing a `bannerLeft` without `src` ( (https://github.com/apache/maven-fluido-skin/blob/7e92f9bb3c6efffb99c3708444957e153c55dd37/src/main/resources/META-INF/maven/site.vm#L189 and https://github.com/apache/maven-fluido-skin/blob/7e92f9bb3c6efffb99c3708444957e153c55dd37/src/main/resources/META-INF/maven/site-macros.vm#L182 (https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft) In the case of https://sling.apache.org/components/scriptingbundle-maven-plugin-archives/scriptingbundle-maven-plugin-0.3.0/ the site.xml looks like https://github.com/apache/sling-scriptingbundle-maven-plugin/blob/scriptingbundle-maven-plugin-0.3.0/src/site/site.xml (and inherits from ASF Parent 23 through https://github.com/apache/sling-parent/blob/sling-parent-reactor-41/sling-parent/pom.xml which doesn't contain any site.xml), so it is unclear to me why we run into fallback b) instead of a). [~hboutemy] Any idea since you implemented both fallbacks? was (Author: kwin): The h2 is actually coming from macro `banner` with a banner object not containing a `src` property: https://github.com/apache/maven-fluido-skin/blob/7e92f9bb3c6efffb99c3708444957e153c55dd37/src/main/resources/META-INF/maven/site-macros.vm#L182 So it seems there are two different fallbacks here: a) for a site definition not containing a `bannerLeft` (https://github.com/apache/maven-fluido-skin/blob/7e92f9bb3c6efffb99c3708444957e153c55dd37/src/main/resources/META-INF/maven/site.vm#L189) b) for a site definition containing a `bannerLeft` without `src` (https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft) In the case of https://sling.apache.org/components/scriptingbundle-maven-plugin-archives/scriptingbundle-maven-plugin-0.3.0/ the site.xml looks like https://github.com/apache/sling-scriptingbundle-maven-plugin/blob/scriptingbundle-maven-plugin-0.3.0/src/site/site.xml (and inherits from ASF Parent 23 through https://github.com/apache/sling-parent/blob/sling-parent-reactor-41/sling-parent/pom.xml which doesn't contain any site.xml), so it is unclear to me why we run into fallback b) instead of a). [~hboutemy] Any idea since you implemented both fallbacks? > Allow to show name as headline in addition to bannerLeft > > > Key: MSKINS-170 > URL: https://issues.apache.org/jira/browse/MSKINS-170 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.9 >Reporter: Konrad Windszus >Priority: Major > > Currently there is a fallback with text in case no bannerLeft is configured: > https://github.com/apache/maven-fluido-skin/blob/f966972c504c8a01a5d7a203de6438464877a8bd/src/main/resources/META-INF/maven/site.vm#L188. > It would be nice to optionally show that next to the banner. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-fluido-skin] michael-o commented on a diff in pull request #23: [MSKINS-169] Image height not effective
michael-o commented on code in PR #23: URL: https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866200329 ## src/main/resources/META-INF/maven/site-macros.vm: ## @@ -110,21 +110,21 @@ #**##set ( $imgAlt = ' alt=""' ) #* *##end #* *##if( $border ) -#**##set ( $imgBorder = ' border="' + $border + '"' ) +#**##set ( $imgBorder = 'border: ' + $border + ';' ) Review Comment: I agree this needs clarification or change, but that will happen in Doxia 2 only. -- 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-fluido-skin] michael-o commented on a diff in pull request #23: [MSKINS-169] Image height not effective
michael-o commented on code in PR #23: URL: https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866200803 ## src/main/resources/META-INF/maven/site-macros.vm: ## @@ -110,21 +110,21 @@ #**##set ( $imgAlt = ' alt=""' ) #* *##end #* *##if( $border ) -#**##set ( $imgBorder = ' border="' + $border + '"' ) +#**##set ( $imgBorder = 'border: ' + $border + ';' ) Review Comment: Raise an issue with Doxia Sitetools. -- 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-fluido-skin] michael-o commented on a diff in pull request #23: [MSKINS-169] Image height not effective
michael-o commented on code in PR #23: URL: https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866202815 ## src/main/resources/META-INF/maven/site-macros.vm: ## @@ -110,21 +110,21 @@ #**##set ( $imgAlt = ' alt=""' ) #* *##end #* *##if( $border ) -#**##set ( $imgBorder = ' border="' + $border + '"' ) +#**##set ( $imgBorder = 'border: ' + $border + ';' ) #* *##else #**##set ( $imgBorder = "" ) #* *##end #* *##if( $width ) -#**##set ( $imgWidth = ' width="' + $width + '"' ) +#**##set ( $imgWidth = 'width: ' + $width + ';' ) #* *##else #**##set ( $imgWidth = "" ) #* *##end #* *##if( $height ) -#**##set ( $imgHeight = ' height="' + $height + '"' ) +#**##set ( $imgHeight = 'height: ' + $height + ';' ) #* *##else #**##set ( $imgHeight = "" ) #* *##end -## +## Review Comment: done -- 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] (MRESOLVER-256) Dependency tree is different between DF and BF strategies when a dependency package has no indirect dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532477#comment-17532477 ] Hudson commented on MRESOLVER-256: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #29 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/29/ > Dependency tree is different between DF and BF strategies when a dependency > package has no indirect dependencies > > > Key: MRESOLVER-256 > URL: https://issues.apache.org/jira/browse/MRESOLVER-256 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.8.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.1 > > > From GitHub: > Fix the problem that the dependency tree is different when DF and BF > strategies are adopted when a dependency package has no children dependency. > When BF is adopted, when a dependent package has no children dependency, it > will not continue to call the doRecurse() method, that is, it will not call > the CacheManager.cachewinner() to put this dependency package into the > winnerGAs object, which affects the analysis results of dependency packages > of the same GA. The current fix is to call the CacheManager.cachewinner() > method when a dependent package has no children dependency and it is not skip > resolution, so that the dependent package can be found in winnerGAs. > We take the dependency in the following figure as an example to illustrate > the generation process of the problem. > src="https://user-images.githubusercontent.com/104960983/166911972-6d721f62-ea17-46fc-af60-181aa5fdb041.png";> > At org eclipse. aether. internal. impl. Bfdependencycollector > #collectdependencies() mainly has two stages: processdependency() and > transformer.transformGraph( node, context )。 > In the first stage of process dependency: > 1. When parsing to D1, descriptorResult.getDependencies().isEmpty(), so > doRecurse() will not be executed. Therefore, args.skipper.cache() will not be > executed. The D1 will not exist in winnerGAs in the end. >  > 2. When parsing D2 of the same layer, because there is no same GA in > winnerGAs, D2 and its children dependencies （ G1 and H1） will be parsed. > 3. When resolving to G2 on the same layer as G1, because winnerGAs already > has G1, the resolution of the children dependencies of G2 will be skipped, > that is, H2 will not be resolved. > Then, to the second stage, transformgraph: > 4. Because D1 has the same depth as D2, D1 wins, that is, D2 and its children > are eliminated, including G1 > 5. Because G1 was eliminated, G2 won. > Finally, the final dependency tree obtained by BF strategy is as follows: > src="https://user-images.githubusercontent.com/104960983/166912027-21d7fcd4-79bd-43cc-80c8-0088091a91ef.png";> > But the dependency tree obtained by DF is as follows: > src="https://user-images.githubusercontent.com/104960983/166912045-2cff5bd6-f54d-4faa-a955-6c985923058a.png";> > That is, in the final generated dependency tree, BF has less children > dependency of G2 than DF. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSKINS-174) Render breadcrumbs div conditionally
[ https://issues.apache.org/jira/browse/MSKINS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532479#comment-17532479 ] Michael Osipov commented on MSKINS-174: --- Is this still required? > Render breadcrumbs div conditionally > > > Key: MSKINS-174 > URL: https://issues.apache.org/jira/browse/MSKINS-174 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.9 >Reporter: Konrad Windszus >Priority: Major > Attachments: breadcrumb-div.png > > > Currently the breadcrumb div is always rendered even if it is empty > (https://github.com/apache/maven-fluido-skin/blob/dda45e9236f90dc8493fcc917a99716212825573/src/main/resources/META-INF/maven/site.vm#L202). > That leads to the issue that a grey bar is rendered in case the publish date > is not rendered at the top (left or right): !breadcrumb-div.png! > That div should be rendered only conditionally in case there is > # at least one breadcrumb item or > # the publish date is positioned "left" or "right" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSKINS-174) Render breadcrumbs div conditionally
[ https://issues.apache.org/jira/browse/MSKINS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532484#comment-17532484 ] Konrad Windszus commented on MSKINS-174: Yes, still valid and I would appreciate a fix for Jackrabbit > Render breadcrumbs div conditionally > > > Key: MSKINS-174 > URL: https://issues.apache.org/jira/browse/MSKINS-174 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.9 >Reporter: Konrad Windszus >Priority: Major > Attachments: breadcrumb-div.png > > > Currently the breadcrumb div is always rendered even if it is empty > (https://github.com/apache/maven-fluido-skin/blob/dda45e9236f90dc8493fcc917a99716212825573/src/main/resources/META-INF/maven/site.vm#L202). > That leads to the issue that a grey bar is rendered in case the publish date > is not rendered at the top (left or right): !breadcrumb-div.png! > That div should be rendered only conditionally in case there is > # at least one breadcrumb item or > # the publish date is positioned "left" or "right" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MRESOLVER-257) Make DF and BF UTs share as much tests as possible
Tamás Cservenák created MRESOLVER-257: - Summary: Make DF and BF UTs share as much tests as possible Key: MRESOLVER-257 URL: https://issues.apache.org/jira/browse/MRESOLVER-257 Project: Maven Resolver Issue Type: Task Components: Resolver Affects Versions: 1.8.0 Reporter: Tamás Cservenák Fix For: 1.8.1 As the BfDependencyCollectorTest and DfDependenctCollectorTest are copy of each other right now, where newer BF is a bit modified or extended. All in all, they should behave same (maybe "quite similar"), so it makes sense to pull up the unit tests into some abstract UT and let DF UT and BF UT share most they can. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-integration-testing] slawekjaranowski merged pull request #154: [MNG-7464] Warn about using read-only parameters for Mojo in configuration
slawekjaranowski merged PR #154: URL: https://github.com/apache/maven-integration-testing/pull/154 -- 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] slawekjaranowski merged pull request #731: [MNG-7464] Warn about using read-only parameters for Mojo in configuration
slawekjaranowski merged PR #731: URL: https://github.com/apache/maven/pull/731 -- 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-7464) Warn about using read-only parameters for Mojo in configuration
[ https://issues.apache.org/jira/browse/MNG-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532491#comment-17532491 ] ASF GitHub Bot commented on MNG-7464: - slawekjaranowski merged PR #731: URL: https://github.com/apache/maven/pull/731 > Warn about using read-only parameters for Mojo in configuration > --- > > Key: MNG-7464 > URL: https://issues.apache.org/jira/browse/MNG-7464 > Project: Maven > Issue Type: New Feature >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-release] cstamas commented on pull request #118: [MRELEASE-1087] Catch up
cstamas commented on PR #118: URL: https://github.com/apache/maven-release/pull/118#issuecomment-1118957409 Cool, thanks @slawekjaranowski ! -- 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-release] cstamas commented on pull request #118: [MRELEASE-1087] Catch up
cstamas commented on PR #118: URL: https://github.com/apache/maven-release/pull/118#issuecomment-1118960807 @rfscholte or @hboutemy would be good if any of you would bless this PR so we can merge. Again, as before, if there is any other PR scheduled, please merge it BEFORE this one, I will handle conflicts. But, this PR clearly shows severe issues with m-release-p: * why does release redo Maven CLI? (see use of commons-cli), this is obviously a duplication of logic here * why does release resolve anything at all? Several of us have hard time to understand what is happening here All in all, I still think what I said before: "this plugin does WAAY more than it should", and hence, is very fragile (the plugin but it's process as well). Anyway, let's move on, and we can tinker more about these later. -- 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-7464) Warn about using read-only parameters for Mojo in configuration
[ https://issues.apache.org/jira/browse/MNG-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532496#comment-17532496 ] Hudson commented on MNG-7464: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #41 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/41/ > Warn about using read-only parameters for Mojo in configuration > --- > > Key: MNG-7464 > URL: https://issues.apache.org/jira/browse/MNG-7464 > Project: Maven > Issue Type: New Feature >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-fluido-skin] michael-o closed pull request #23: [MSKINS-169] Image height not effective
michael-o closed pull request #23: [MSKINS-169] Image height not effective URL: https://github.com/apache/maven-fluido-skin/pull/23 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MSKINS-169) Image height not effective
[
https://issues.apache.org/jira/browse/MSKINS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSKINS-169.
-
Resolution: Fixed
Fixed with
[97b91611727e1c8cb5c0250388ef34f15c14f521|https://gitbox.apache.org/repos/asf?p=maven-fluido-skin.git;a=commit;h=97b91611727e1c8cb5c0250388ef34f15c14f521].
> Image height not effective
> --
>
> Key: MSKINS-169
> URL: https://issues.apache.org/jira/browse/MSKINS-169
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.9
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-1.11.0
>
>
> As bootstrap 2.3.2 styles all images with {{height: auto}}
> (https://github.com/apache/maven-fluido-skin/blob/f966972c504c8a01a5d7a203de6438464877a8bd/src/main/resources/css/bootstrap-2.3.2.css#L103)
> setting a height in
> https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft
> does not have any effect (although the HTML img element carries it, it is
> overwritten by the bootstrap.css)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MSKINS-117) Improve lisibility and user-friendliness in the left menu
[ https://issues.apache.org/jira/browse/MSKINS-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-117: -- Fix Version/s: (was: wontfix-candidate) > Improve lisibility and user-friendliness in the left menu > - > > Key: MSKINS-117 > URL: https://issues.apache.org/jira/browse/MSKINS-117 > Project: Maven Skins > Issue Type: Wish > Components: Fluido Skin >Affects Versions: fluido-1.4 >Reporter: Cyril JACQUENOT >Priority: Major > Attachments: actual_skin_bad_lisibility.jpg, > skin_maven_old_better_lisibility.jpg > > > In our company, we now use *Maven Fluido Skin* for our projects > online-documentation. > I like the design but the lisibility is not optimal: it is hard for me to > find the location of my current page in the menu. > Great improvements should be : > * to increase indentations > * to use fonts weight to show different levels of indentation > * to give the possibility to manage more than 2 levels in the menu > _here is the bad lisibility skin :_ > !actual_skin_bad_lisibility.jpg! > _here is an old skin, but with *better lisibility* :_ > !skin_maven_old_better_lisibility.jpg! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSKINS-174) Render breadcrumbs div conditionally
[ https://issues.apache.org/jira/browse/MSKINS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532510#comment-17532510 ] Michael Osipov commented on MSKINS-174: --- I have an idea how to solve this. It is not perfect, but I don't want to repeat/copy the conditions around the div to decide whether the this is going to be empty or not. > Render breadcrumbs div conditionally > > > Key: MSKINS-174 > URL: https://issues.apache.org/jira/browse/MSKINS-174 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.9 >Reporter: Konrad Windszus >Priority: Major > Attachments: breadcrumb-div.png > > > Currently the breadcrumb div is always rendered even if it is empty > (https://github.com/apache/maven-fluido-skin/blob/dda45e9236f90dc8493fcc917a99716212825573/src/main/resources/META-INF/maven/site.vm#L202). > That leads to the issue that a grey bar is rendered in case the publish date > is not rendered at the top (left or right): !breadcrumb-div.png! > That div should be rendered only conditionally in case there is > # at least one breadcrumb item or > # the publish date is positioned "left" or "right" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MSKINS-174) Render breadcrumbs div conditionally
[ https://issues.apache.org/jira/browse/MSKINS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-174: -- Fix Version/s: fluido-1.11.0 > Render breadcrumbs div conditionally > > > Key: MSKINS-174 > URL: https://issues.apache.org/jira/browse/MSKINS-174 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.9 >Reporter: Konrad Windszus >Assignee: Michael Osipov >Priority: Major > Fix For: fluido-1.11.0 > > Attachments: breadcrumb-div.png > > > Currently the breadcrumb div is always rendered even if it is empty > (https://github.com/apache/maven-fluido-skin/blob/dda45e9236f90dc8493fcc917a99716212825573/src/main/resources/META-INF/maven/site.vm#L202). > That leads to the issue that a grey bar is rendered in case the publish date > is not rendered at the top (left or right): !breadcrumb-div.png! > That div should be rendered only conditionally in case there is > # at least one breadcrumb item or > # the publish date is positioned "left" or "right" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (MSKINS-174) Render breadcrumbs div conditionally
[ https://issues.apache.org/jira/browse/MSKINS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MSKINS-174: - Assignee: Michael Osipov > Render breadcrumbs div conditionally > > > Key: MSKINS-174 > URL: https://issues.apache.org/jira/browse/MSKINS-174 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.9 >Reporter: Konrad Windszus >Assignee: Michael Osipov >Priority: Major > Attachments: breadcrumb-div.png > > > Currently the breadcrumb div is always rendered even if it is empty > (https://github.com/apache/maven-fluido-skin/blob/dda45e9236f90dc8493fcc917a99716212825573/src/main/resources/META-INF/maven/site.vm#L202). > That leads to the issue that a grey bar is rendered in case the publish date > is not rendered at the top (left or right): !breadcrumb-div.png! > That div should be rendered only conditionally in case there is > # at least one breadcrumb item or > # the publish date is positioned "left" or "right" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MSKINS-97) Upgrade to Bootstrap 5.x
[ https://issues.apache.org/jira/browse/MSKINS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-97: - Description: Next major of Fluido should be upgraded to Bootstrap 5.x which is *not* backwards compatible to 2.x. See http://getbootstrap.com/migration/ (was: Next major of Fluido should be upgraded to Bootstrap 4.x which is *not* backwards compatible to 2.x. See http://getbootstrap.com/migration/) > Upgrade to Bootstrap 5.x > > > Key: MSKINS-97 > URL: https://issues.apache.org/jira/browse/MSKINS-97 > Project: Maven Skins > Issue Type: Task > Components: Fluido Skin >Reporter: Michael Osipov >Priority: Major > Fix For: fluido-2.0.0 > > > Next major of Fluido should be upgraded to Bootstrap 5.x which is *not* > backwards compatible to 2.x. See http://getbootstrap.com/migration/ -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MINDEXER-154) Empty download page on documentation site
Slawomir Jaranowski created MINDEXER-154: Summary: Empty download page on documentation site Key: MINDEXER-154 URL: https://issues.apache.org/jira/browse/MINDEXER-154 Project: Maven Indexer Issue Type: Bug Reporter: Slawomir Jaranowski Page https://maven.apache.org/maven-indexer/download.html is empty. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSKINS-169) Image height not effective
[
https://issues.apache.org/jira/browse/MSKINS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532513#comment-17532513
]
Hudson commented on MSKINS-169:
---
Build succeeded in Jenkins: Maven » Maven TLP » maven-fluido-skin » master #12
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-fluido-skin/job/master/12/
> Image height not effective
> --
>
> Key: MSKINS-169
> URL: https://issues.apache.org/jira/browse/MSKINS-169
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.9
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-1.11.0
>
>
> As bootstrap 2.3.2 styles all images with {{height: auto}}
> (https://github.com/apache/maven-fluido-skin/blob/f966972c504c8a01a5d7a203de6438464877a8bd/src/main/resources/css/bootstrap-2.3.2.css#L103)
> setting a height in
> https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft
> does not have any effect (although the HTML img element carries it, it is
> overwritten by the bootstrap.css)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (MINDEXER-155) Add Maven site descriptor for all modules
Slawomir Jaranowski created MINDEXER-155: Summary: Add Maven site descriptor for all modules Key: MINDEXER-155 URL: https://issues.apache.org/jira/browse/MINDEXER-155 Project: Maven Indexer Issue Type: Improvement Reporter: Slawomir Jaranowski Each module should contains own site.xml descriptor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MINDEXER-155) Add Maven site descriptor for all modules
[ https://issues.apache.org/jira/browse/MINDEXER-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MINDEXER-155: - Labels: up-for-grabs (was: ) > Add Maven site descriptor for all modules > - > > Key: MINDEXER-155 > URL: https://issues.apache.org/jira/browse/MINDEXER-155 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Priority: Major > Labels: up-for-grabs > > Each module should contains own site.xml descriptor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MRELEASE-1088) Remove parsing of CLI arguments
Slawomir Jaranowski created MRELEASE-1088: - Summary: Remove parsing of CLI arguments Key: MRELEASE-1088 URL: https://issues.apache.org/jira/browse/MRELEASE-1088 Project: Maven Release Plugin Issue Type: Improvement Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski We can pass this job to Maven Invoker -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-release] slawekjaranowski opened a new pull request, #120: [MRELEASE-1088] Remove parsing of CLI arguments
slawekjaranowski opened a new pull request, #120: URL: https://github.com/apache/maven-release/pull/120 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJAVADOC) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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-release] slawekjaranowski commented on pull request #120: [MRELEASE-1088] Remove parsing of CLI arguments
slawekjaranowski commented on PR #120: URL: https://github.com/apache/maven-release/pull/120#issuecomment-1119076088 Yes I know ... it will conflict with #118 😄 -- 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] [Created] (MSKINS-183) Drop not working ohloh (now https://www.openhub.net/)
Sylwester Lachiewicz created MSKINS-183: --- Summary: Drop not working ohloh (now https://www.openhub.net/) Key: MSKINS-183 URL: https://issues.apache.org/jira/browse/MSKINS-183 Project: Maven Skins Issue Type: Task Reporter: Sylwester Lachiewicz -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MSKINS-183) Drop not working ohloh (now https://www.openhub.net/)
[ https://issues.apache.org/jira/browse/MSKINS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSKINS-183: Description: [https://www.openhub.net/] > Drop not working ohloh (now https://www.openhub.net/) > - > > Key: MSKINS-183 > URL: https://issues.apache.org/jira/browse/MSKINS-183 > Project: Maven Skins > Issue Type: Task >Reporter: Sylwester Lachiewicz >Priority: Minor > > [https://www.openhub.net/] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-release] olamy commented on a diff in pull request #120: [MRELEASE-1088] Remove parsing of CLI arguments
olamy commented on code in PR #120:
URL: https://github.com/apache/maven-release/pull/120#discussion_r866431757
##
maven-release-plugin/src/it/projects/prepare/MRELEASE-667/pom.xml:
##
@@ -37,7 +37,7 @@
- -Prelease,!mrelease-677 ${arguments}
Review Comment:
maybe leave to see if removal do not have side effects?
this usage pattern ` ${arguments}` is used a lot
--
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-release] olamy commented on a diff in pull request #118: [MRELEASE-1087] Catch up
olamy commented on code in PR #118:
URL: https://github.com/apache/maven-release/pull/118#discussion_r866433670
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/DefaultReleaseManager.java:
##
@@ -37,38 +42,56 @@
import org.apache.maven.shared.release.phase.ReleasePhase;
import org.apache.maven.shared.release.phase.ResourceGenerator;
import org.apache.maven.shared.release.strategy.Strategy;
-import org.codehaus.plexus.component.annotations.Component;
-import org.codehaus.plexus.component.annotations.Requirement;
-import org.codehaus.plexus.logging.AbstractLogEnabled;
import org.codehaus.plexus.util.StringUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static java.util.Objects.requireNonNull;
/**
* Implementation of the release manager.
*
* @author mailto:br...@apache.org";>Brett Porter
*/
-@Component( role = ReleaseManager.class )
+@Singleton
+@Named
public class DefaultReleaseManager
-extends AbstractLogEnabled
implements ReleaseManager
{
-@Requirement
-private Map strategies;
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultReleaseManager.class );
+
+private final Map strategies;
/**
* The available phases.
*/
-@Requirement
-private Map releasePhases;
+private final Map releasePhases;
/**
* The configuration storage.
*/
-@Requirement( hint = "properties" )
-private ReleaseDescriptorStore configStore;
+private final AtomicReference configStore;
Review Comment:
what is the need for using `AtomicReference`?
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/DefaultReleaseManager.java:
##
@@ -37,38 +42,56 @@
import org.apache.maven.shared.release.phase.ReleasePhase;
import org.apache.maven.shared.release.phase.ResourceGenerator;
import org.apache.maven.shared.release.strategy.Strategy;
-import org.codehaus.plexus.component.annotations.Component;
-import org.codehaus.plexus.component.annotations.Requirement;
-import org.codehaus.plexus.logging.AbstractLogEnabled;
import org.codehaus.plexus.util.StringUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static java.util.Objects.requireNonNull;
/**
* Implementation of the release manager.
*
* @author mailto:br...@apache.org";>Brett Porter
*/
-@Component( role = ReleaseManager.class )
+@Singleton
+@Named
public class DefaultReleaseManager
-extends AbstractLogEnabled
implements ReleaseManager
{
-@Requirement
-private Map strategies;
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultReleaseManager.class );
Review Comment:
nit. any reason to use a different pattern for this one?
another change use `private final Logger logger = LoggerFactory.getLogger(
getClass() );`
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractInputVariablesPhase.java:
##
@@ -0,0 +1,309 @@
+package org.apache.maven.shared.release.phase;
+
+/*
+ * 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.
+ */
+
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.concurrent.atomic.AtomicReference;
+
+import org.apache.maven.artifact.ArtifactUtils;
+import org.apache.maven.project.MavenProject;
+import org.apache.maven.scm.manager.NoSuchScmProviderException;
+import org.apache.maven.scm.provider.ScmProvider;
+import org.apache.maven.scm.repository.ScmRepository;
+import org.apache.maven.scm.repository.ScmRepositoryException;
+import org.apache.maven.shared.release.ReleaseExecutionException;
+import org.apache.maven.shared.release.ReleaseResult;
+import org.apache.maven.shared.release.config.ReleaseDescriptor;
+import org.apache.maven.shared.release.env.ReleaseEnvironment;
+import org.apache.maven.shared.release.policy.PolicyException;
+import org.apache.maven.shared.release.policy.naming.NamingPolicy;
+import org.apache.maven.shared.release.policy.naming.NamingPolicyRequest;
+import org.apache.maven.shared.release.scm.ReleaseScmRepositoryException;
+import org.apache.maven.shared.release.scm.ScmRepositoryConfigurator;
+import org.apache.
[GitHub] [maven-release] olamy commented on a diff in pull request #118: [MRELEASE-1087] Upgrade Maven to 3.2.5 (and de-plexus)
olamy commented on code in PR #118:
URL: https://github.com/apache/maven-release/pull/118#discussion_r866438748
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/DefaultReleaseManager.java:
##
@@ -37,38 +42,56 @@
import org.apache.maven.shared.release.phase.ReleasePhase;
import org.apache.maven.shared.release.phase.ResourceGenerator;
import org.apache.maven.shared.release.strategy.Strategy;
-import org.codehaus.plexus.component.annotations.Component;
-import org.codehaus.plexus.component.annotations.Requirement;
-import org.codehaus.plexus.logging.AbstractLogEnabled;
import org.codehaus.plexus.util.StringUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static java.util.Objects.requireNonNull;
/**
* Implementation of the release manager.
*
* @author mailto:br...@apache.org";>Brett Porter
*/
-@Component( role = ReleaseManager.class )
+@Singleton
+@Named
public class DefaultReleaseManager
-extends AbstractLogEnabled
implements ReleaseManager
{
-@Requirement
-private Map strategies;
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultReleaseManager.class );
+
+private final Map strategies;
/**
* The available phases.
*/
-@Requirement
-private Map releasePhases;
+private final Map releasePhases;
/**
* The configuration storage.
*/
-@Requirement( hint = "properties" )
-private ReleaseDescriptorStore configStore;
+private final AtomicReference configStore;
Review Comment:
oh ok I saw that too late
https://github.com/apache/maven-release/pull/118#discussion_r863535359
seems still to be over complex this AtomicRef but if it works...
--
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-resolver] weibo1995 opened a new pull request, #173: Add Test cases for the repair of BF algorithm of dependent package when children are empty
weibo1995 opened a new pull request, #173: URL: https://github.com/apache/maven-resolver/pull/173 Add Test cases for the repair of BF algorithm of dependent package when children are empty（ https://github.com/apache/maven-resolver/pull/172 ). After adding, it covers two cases. The first is that the dependent package of no children is on the left. The dependencies are as follows: https://user-images.githubusercontent.com/104960983/167059425-eea64fde-52ba-4cb7-a17a-f85d34e36b8d.png";> The expected final dependency tree after conflict resolving is as follows: https://user-images.githubusercontent.com/104960983/167059488-e5a911a2-3974-4476-b09b-05f511402fdc.png";> The second is that the dependent package of no children is on the right. The dependencies are as follows: https://user-images.githubusercontent.com/104960983/167059539-50fe3547-4299-4aed-9bca-b0a5a74b59e2.png";> The expected final dependency tree after conflict resolving is as follows: https://user-images.githubusercontent.com/104960983/167059558-bbb8a173-2898-4bb1-bf70-9c5618441571.png";> thanks. -- 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-resolver] weibo1995 closed pull request #173: Add Test cases for the repair of BF algorithm of dependent package when children are empty
weibo1995 closed pull request #173: Add Test cases for the repair of BF algorithm of dependent package when children are empty URL: https://github.com/apache/maven-resolver/pull/173 -- 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] [Updated] (MASSEMBLY-956) assembly plugin resolves too much, even plugins used to build dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MASSEMBLY-956: Summary: assembly plugin resolves too much, even plugins used to build dependencies (was: Plugin resolves even plugins used to build dependencies) > assembly plugin resolves too much, even plugins used to build dependencies > -- > > Key: MASSEMBLY-956 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-956 > Project: Maven Assembly Plugin > Issue Type: Task > Components: dependencySet >Reporter: Tamás Cservenák >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-assembly-plugin] dependabot[bot] opened a new pull request, #62: Bump maven-archiver from 3.5.1 to 3.5.2
dependabot[bot] opened a new pull request, #62: URL: https://github.com/apache/maven-assembly-plugin/pull/62 Bumps [maven-archiver](https://github.com/apache/maven-archiver) from 3.5.1 to 3.5.2. Commits https://github.com/apache/maven-archiver/commit/e17dadfafff78826de72fafe466b1bb4e1bc01fb";>e17dadf [maven-release-plugin] prepare release maven-archiver-3.5.2 https://github.com/apache/maven-archiver/commit/e44988258196b183db2da00386befc265a2e2917";>e449882 [MSHARED-1013] Upgrade Plexus Archiver to 4.2.7 https://github.com/apache/maven-archiver/commit/b50de9db5bcd7c4623ade96b1bc49d7d9e9ab839";>b50de9d update CI url https://github.com/apache/maven-archiver/commit/24dfab4dd15ec65522250766c54b88c011894aed";>24dfab4 add more values unit tests https://github.com/apache/maven-archiver/commit/b15117219111c040ec76b693fb8097e8e4416261";>b151172 Bump plexus-archiver from 4.2.3 to 4.2.4 https://github.com/apache/maven-archiver/commit/1cf2d124bf90655892a867e740e7c7cde4339daa";>1cf2d12 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-archiver/compare/maven-archiver-3.5.1...maven-archiver-3.5.2";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] [Updated] (MRELEASE-1079) scm tag is added to child module
[ https://issues.apache.org/jira/browse/MRELEASE-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MRELEASE-1079: Fix Version/s: 3.0.0-M6 > scm tag is added to child module > > > Key: MRELEASE-1079 > URL: https://issues.apache.org/jira/browse/MRELEASE-1079 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 3.0.0-M5 >Reporter: Markus Schäfer >Assignee: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.0.0-M6 > > > With Version 3.0.0-M5 child modules gets an scm tag during the prepare step > when there is more than one module level. > The Bug seems to be in RewritePomsForReleasePhase. > RewritePomsForDevelopmentPhase removes the scm tag. Only the tagged release > has these scm tags. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MRELEASE-955) Document how to work with release profile in 3.x vs 2.x
[
https://issues.apache.org/jira/browse/MRELEASE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532647#comment-17532647
]
Herve Boutemy commented on MRELEASE-955:
I improved the page, renamed it to "upgrade" and published to live site
https://maven.apache.org/maven-release-archives/maven-release-LATEST/maven-release-plugin/upgrade.html
last time for improvements before merging and releasing
> Document how to work with release profile in 3.x vs 2.x
> ---
>
> Key: MRELEASE-955
> URL: https://issues.apache.org/jira/browse/MRELEASE-955
> Project: Maven Release Plugin
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.0.0-M1, 3.0.0-M5
> Environment: n/a
>Reporter: Anders Hammar
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> In v3.0.0 of the plugin, the {{useReleaseProfile}} parameter has been
> deprecated *and default value changed to {{false}}*.
> This effectively changes from convention over configuration with a default
> release profile (the {{release-profile}} profile in the super-POM) so that
> the end user now needs:
> 1. to create a release profile (with his own naming choice)
> 2. and configure the plugin to use it (like add
> {{-Pname_of_the_release_profile ...}} or
> {{name_of_the_release_profile}}).
> We need to document this change in behavior as well as describe best-practice
> for handling this.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-release] slawekjaranowski commented on a diff in pull request #120: [MRELEASE-1088] Remove parsing of CLI arguments
slawekjaranowski commented on code in PR #120:
URL: https://github.com/apache/maven-release/pull/120#discussion_r866495051
##
maven-release-plugin/src/it/projects/prepare/MRELEASE-667/pom.xml:
##
@@ -37,7 +37,7 @@
- -Prelease,!mrelease-677 ${arguments}
Review Comment:
It is one change - now arguments is pass directly to Invoker, and here
property `${arguments}` is not resolved so is passed as is.
When we parsed CLI such not resolvable property was not used.
--
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-release] slawekjaranowski commented on a diff in pull request #110: [MRELEASE-955] first pass at release profile documentation
slawekjaranowski commented on code in PR #110: URL: https://github.com/apache/maven-release/pull/110#discussion_r866497801 ## maven-release-plugin/src/site/site.xml: ## @@ -34,6 +34,7 @@ under the License. + Review Comment: Maybe `Upgrade from 2 to 3`, `Migrate from 2 to 3` or simply `Migrate` -- 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-release] olamy commented on a diff in pull request #120: [MRELEASE-1088] Remove parsing of CLI arguments
olamy commented on code in PR #120:
URL: https://github.com/apache/maven-release/pull/120#discussion_r866499261
##
maven-release-plugin/src/it/projects/prepare/MRELEASE-667/pom.xml:
##
@@ -37,7 +37,7 @@
- -Prelease,!mrelease-677 ${arguments}
Review Comment:
do you mean leaving `-Prelease,!mrelease-677
${arguments}` is now failing the build when `${arguments}` is not
defined?
uhm this doesn't look right to me. at least should not fail.
--
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-release] slawekjaranowski commented on a diff in pull request #120: [MRELEASE-1088] Remove parsing of CLI arguments
slawekjaranowski commented on code in PR #120:
URL: https://github.com/apache/maven-release/pull/120#discussion_r866505806
##
maven-release-plugin/src/it/projects/prepare/MRELEASE-667/pom.xml:
##
@@ -37,7 +37,7 @@
- -Prelease,!mrelease-677 ${arguments}
Review Comment:
exactly ... if any property in `arguments` are not resolvable build will
fail it.
It is a cost ... parsing everything and duplicate code or pass value as is.
It worked in the same way with old forked executor.
--
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] [Assigned] (MRELEASE-955) Document how to work with release profile in 3.x vs 2.x
[
https://issues.apache.org/jira/browse/MRELEASE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MRELEASE-955:
-
Assignee: Herve Boutemy
> Document how to work with release profile in 3.x vs 2.x
> ---
>
> Key: MRELEASE-955
> URL: https://issues.apache.org/jira/browse/MRELEASE-955
> Project: Maven Release Plugin
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.0.0-M1, 3.0.0-M5
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> In v3.0.0 of the plugin, the {{useReleaseProfile}} parameter has been
> deprecated *and default value changed to {{false}}*.
> This effectively changes from convention over configuration with a default
> release profile (the {{release-profile}} profile in the super-POM) so that
> the end user now needs:
> 1. to create a release profile (with his own naming choice)
> 2. and configure the plugin to use it (like add
> {{-Pname_of_the_release_profile ...}} or
> {{name_of_the_release_profile}}).
> We need to document this change in behavior as well as describe best-practice
> for handling this.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-mvnd] gnodet commented on issue #637: Timeout waiting to connect to the Maven daemon
gnodet commented on issue #637: URL: https://github.com/apache/maven-mvnd/issues/637#issuecomment-1119287386 Please reopen if needed. -- 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-mvnd] gnodet closed issue #637: Timeout waiting to connect to the Maven daemon
gnodet closed issue #637: Timeout waiting to connect to the Maven daemon URL: https://github.com/apache/maven-mvnd/issues/637 -- 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-release] cstamas commented on a diff in pull request #118: [MRELEASE-1087] Upgrade Maven to 3.2.5 (and de-plexus)
cstamas commented on code in PR #118:
URL: https://github.com/apache/maven-release/pull/118#discussion_r866524011
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/DefaultReleaseManager.java:
##
@@ -37,38 +42,56 @@
import org.apache.maven.shared.release.phase.ReleasePhase;
import org.apache.maven.shared.release.phase.ResourceGenerator;
import org.apache.maven.shared.release.strategy.Strategy;
-import org.codehaus.plexus.component.annotations.Component;
-import org.codehaus.plexus.component.annotations.Requirement;
-import org.codehaus.plexus.logging.AbstractLogEnabled;
import org.codehaus.plexus.util.StringUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static java.util.Objects.requireNonNull;
/**
* Implementation of the release manager.
*
* @author mailto:br...@apache.org";>Brett Porter
*/
-@Component( role = ReleaseManager.class )
+@Singleton
+@Named
public class DefaultReleaseManager
-extends AbstractLogEnabled
implements ReleaseManager
{
-@Requirement
-private Map strategies;
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultReleaseManager.class );
Review Comment:
Unified all loggers, they are obtained in same way everywhere
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractInputVariablesPhase.java:
##
@@ -0,0 +1,309 @@
+package org.apache.maven.shared.release.phase;
+
+/*
+ * 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.
+ */
+
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.concurrent.atomic.AtomicReference;
+
+import org.apache.maven.artifact.ArtifactUtils;
+import org.apache.maven.project.MavenProject;
+import org.apache.maven.scm.manager.NoSuchScmProviderException;
+import org.apache.maven.scm.provider.ScmProvider;
+import org.apache.maven.scm.repository.ScmRepository;
+import org.apache.maven.scm.repository.ScmRepositoryException;
+import org.apache.maven.shared.release.ReleaseExecutionException;
+import org.apache.maven.shared.release.ReleaseResult;
+import org.apache.maven.shared.release.config.ReleaseDescriptor;
+import org.apache.maven.shared.release.env.ReleaseEnvironment;
+import org.apache.maven.shared.release.policy.PolicyException;
+import org.apache.maven.shared.release.policy.naming.NamingPolicy;
+import org.apache.maven.shared.release.policy.naming.NamingPolicyRequest;
+import org.apache.maven.shared.release.scm.ReleaseScmRepositoryException;
+import org.apache.maven.shared.release.scm.ScmRepositoryConfigurator;
+import org.apache.maven.shared.release.util.ReleaseUtil;
+import org.codehaus.plexus.components.interactivity.Prompter;
+import org.codehaus.plexus.components.interactivity.PrompterException;
+import org.codehaus.plexus.interpolation.InterpolationException;
+import org.codehaus.plexus.interpolation.Interpolator;
+import org.codehaus.plexus.interpolation.PrefixAwareRecursionInterceptor;
+import org.codehaus.plexus.interpolation.PrefixedPropertiesValueSource;
+import org.codehaus.plexus.interpolation.RecursionInterceptor;
+import org.codehaus.plexus.interpolation.StringSearchInterpolator;
+import org.codehaus.plexus.util.StringUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Input any variables that were not yet configured.
+ *
+ * @author mailto:br...@apache.org";>Brett Porter
+ */
+public abstract class AbstractInputVariablesPhase
+extends AbstractReleasePhase
+{
+/**
+ * Component used to prompt for input.
+ */
+private final AtomicReference prompter;
+
+/**
+ * Tool that gets a configured SCM repository from release configuration.
+ */
+private final ScmRepositoryConfigurator scmRepositoryConfigurator;
+
+/**
+ * Component used for custom or default naming policy
+ */
+private final Map namingPolicies;
+
+/**
+ * Whether this is a branch or a tag operation.
+ */
+private final boolean branchOperation;
+
+/**
+ * The default naming policy to apply, if any
+ */
+private final String defaultNamingPolicy;
+
+protected AbstractInputVariablesPhase( Prompter prompter,
ScmRepositoryConfigur
[GitHub] [maven-deploy-plugin] cstamas commented on pull request #22: [MDEPLOY-291] Update POM parent and Maven
cstamas commented on PR #22: URL: https://github.com/apache/maven-deploy-plugin/pull/22#issuecomment-1119301329 @michael-o let's push this along with m-install-p and make 3.0.0 release of both soon, it is really time for it :smile: -- 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] (MENFORCER-356) Please support m2e lifecycle management
[ https://issues.apache.org/jira/browse/MENFORCER-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532657#comment-17532657 ] Slawomir Jaranowski commented on MENFORCER-356: --- It is not good way to add meta-data or even worst depends plugin code on external api. If we go in this way we open possibility to adding meta-data for external tools So question - in next request we should add more meta-data for other IDE, tool ... etc? It should be resolved by m2e in some how, without changing plugins. > Please support m2e lifecycle management > --- > > Key: MENFORCER-356 > URL: https://issues.apache.org/jira/browse/MENFORCER-356 > Project: Maven Enforcer Plugin > Issue Type: Bug > Environment: Linux >Reporter: Luke Hutchison >Priority: Major > Fix For: 3.0.1 > > > The maven-enforcer-plugin does not work with m2e without configuration using > the `lifecyleManagement` tag. However, that tag causes numerous bad > interactions between m2e and commandline mvn. > Recently m2e added a new configuration mechanism for specifying the lifecycle > management configuration: > [https://www.eclipse.org/m2e/documentation/release-notes-17.html#new-syntax-for-specifying-lifecycle-mapping-metadata] > The directive that works for me to get maven-enforcer-plugin to work with m2e > is: > > However, this style of directive, , breaks numerous tools, including > Sonatype's artifact publishing framework, and the Scrutinizer CI / static > code analyzer, because they use custom XML parsers that can't yet handle this > syntax. That means I have to leave the directive in the pom.xml while > developing, so that I can use Eclipse, and then I have to remove it before > publishing or analyzing any built jar. > It would be very helpful if maven-enforcer-plugin could make use of the m2e > lifecycle management API internally to configure itself to work with m2e, so > that this directive is not needed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MENFORCER-356) Please support m2e lifecycle management
[ https://issues.apache.org/jira/browse/MENFORCER-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MENFORCER-356: -- Fix Version/s: waiting-for-feedback (was: 3.0.1) > Please support m2e lifecycle management > --- > > Key: MENFORCER-356 > URL: https://issues.apache.org/jira/browse/MENFORCER-356 > Project: Maven Enforcer Plugin > Issue Type: Bug > Environment: Linux >Reporter: Luke Hutchison >Priority: Major > Fix For: waiting-for-feedback > > > The maven-enforcer-plugin does not work with m2e without configuration using > the `lifecyleManagement` tag. However, that tag causes numerous bad > interactions between m2e and commandline mvn. > Recently m2e added a new configuration mechanism for specifying the lifecycle > management configuration: > [https://www.eclipse.org/m2e/documentation/release-notes-17.html#new-syntax-for-specifying-lifecycle-mapping-metadata] > The directive that works for me to get maven-enforcer-plugin to work with m2e > is: > > However, this style of directive, , breaks numerous tools, including > Sonatype's artifact publishing framework, and the Scrutinizer CI / static > code analyzer, because they use custom XML parsers that can't yet handle this > syntax. That means I have to leave the directive in the pom.xml while > developing, so that I can use Eclipse, and then I have to remove it before > publishing or analyzing any built jar. > It would be very helpful if maven-enforcer-plugin could make use of the m2e > lifecycle management API internally to configure itself to work with m2e, so > that this directive is not needed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MNG-7472) Extend Maven BOM to cover all things "provided" by Maven
Tamás Cservenák created MNG-7472: Summary: Extend Maven BOM to cover all things "provided" by Maven Key: MNG-7472 URL: https://issues.apache.org/jira/browse/MNG-7472 Project: Maven Issue Type: Task Reporter: Tamás Cservenák IMHO, the BOM should be aligned with extensions.xml (exportedArtifact), as clearly, plugin developer instead whatever version it declares, will instead get the artifact version that comes from core. And this is true not only for Maven artifacts (core etc), but also for important components like Resolver. Hence, whatever is "provided" by Core should be locked down by BOM. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MNG-7473) Backport Maven BOM to Maven 3.9.x
Tamás Cservenák created MNG-7473: Summary: Backport Maven BOM to Maven 3.9.x Key: MNG-7473 URL: https://issues.apache.org/jira/browse/MNG-7473 Project: Maven Issue Type: Task Reporter: Tamás Cservenák It will ease lives of plugin developers a lot. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MNG-7473) Backport Maven BOM to Maven 3.9.x
[ https://issues.apache.org/jira/browse/MNG-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MNG-7473: - Fix Version/s: 3.9.0-candidate > Backport Maven BOM to Maven 3.9.x > - > > Key: MNG-7473 > URL: https://issues.apache.org/jira/browse/MNG-7473 > Project: Maven > Issue Type: Task >Reporter: Tamás Cservenák >Priority: Major > Fix For: 3.9.0-candidate > > > It will ease lives of plugin developers a lot. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-release] michael-o commented on pull request #118: [MRELEASE-1087] Upgrade Maven to 3.2.5 (and de-plexus)
michael-o commented on PR #118: URL: https://github.com/apache/maven-release/pull/118#issuecomment-1119311196 > LGTM: a good pass at cleanup that will prepare for next ones I hope M6 will be the last milestone and we can after go to final I assume that SCM 2 will be in MRELEASE 4 only, 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
