[jira] [Commented] (MSITE-779) add color to report generation messages
[
https://issues.apache.org/jira/browse/MSITE-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15337582#comment-15337582
]
Hudson commented on MSITE-779:
--
SUCCESS: Integrated in maven-plugins #6512 (See
[https://builds.apache.org/job/maven-plugins/6512/])
[MSITE-779] renamed highlight() to strong() (hboutemy:
[http://svn.apache.org/viewvc/?view=rev=1748912])
*
maven-site-plugin/src/main/java/org/apache/maven/plugins/site/render/ReportDocumentRenderer.java
> add color to report generation messages
> ---
>
> Key: MSITE-779
> URL: https://issues.apache.org/jira/browse/MSITE-779
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 3.6
>
>
> with ANSI color support added in MNG-3507, it would be useful to use the same
> color rendering for report generation messages:
> {noformat}[INFO] Generating "Summary" report ---
> maven-project-info-reports-plugin:2.9:summary{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5305) Deprecate relativePath
[ https://issues.apache.org/jira/browse/MNG-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MNG-5305: --- Labels: close-pending (was: ) > Deprecate relativePath > -- > > Key: MNG-5305 > URL: https://issues.apache.org/jira/browse/MNG-5305 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Reto Gmuer > Labels: close-pending > > The concept of relativePath is alien to the overall Maven design of having > project directory that only depends on entities in the repositories. With > relative-paths the build might yield to different results depending on were a > project folder is located in the local filesystem. > The parent POM resolution was changed in Maven 3. Because of this explicit > relativePaths need to be specified more often for reactor builds to be built > in the correct order. The reason for this (according to Maven 3.x > compatibility note) is to improve consistency: "In Maven 2, building the > child project in isolation could fail while the reactor build would succeed > to resolve the parent.". However this behaviour is inconsistent with the > resolution of the other dependencies, in fact the above is true for any Maven > version when a dependency that is part of the reactor is not available in a > suitable versions in the repository: in this case the build of the individual > project fails while the build of the whole reactor succeeds. > Because of this relativePath should be marked as deprecated and the parent > should be treated like a dependency when computing the build order of reactor > projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5305) Deprecate relativePath
[
https://issues.apache.org/jira/browse/MNG-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336855#comment-15336855
]
Christian Schulte commented on MNG-5305:
If you add an empty {{}} element to your {{}}
declarations, you get the behaviour you are asking for. There are use cases the
{{}} is needed for. That is checking out a multi module project
and executing some phase from the default lifecycle before {{install}}. We need
to support {{mvn compile}} or {{mvn verify}} without any of the artifacts being
available in some repository (local or remote). I see no issue with searching a
parent pom on disk. It's documented and people should just know what they do. I
think Maven is doing the right thing here. If you checkout only a single
module, it will resolve the parent(s) from the repository, if you checkout the
complete multi-module project it will resolve the parent(s) from that project
structure.
> Deprecate relativePath
> --
>
> Key: MNG-5305
> URL: https://issues.apache.org/jira/browse/MNG-5305
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Reto Gmuer
>
> The concept of relativePath is alien to the overall Maven design of having
> project directory that only depends on entities in the repositories. With
> relative-paths the build might yield to different results depending on were a
> project folder is located in the local filesystem.
> The parent POM resolution was changed in Maven 3. Because of this explicit
> relativePaths need to be specified more often for reactor builds to be built
> in the correct order. The reason for this (according to Maven 3.x
> compatibility note) is to improve consistency: "In Maven 2, building the
> child project in isolation could fail while the reactor build would succeed
> to resolve the parent.". However this behaviour is inconsistent with the
> resolution of the other dependencies, in fact the above is true for any Maven
> version when a dependency that is part of the reactor is not available in a
> suitable versions in the repository: in this case the build of the individual
> project fails while the build of the whole reactor succeeds.
> Because of this relativePath should be marked as deprecated and the parent
> should be treated like a dependency when computing the build order of reactor
> projects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-956) Release Strategy Interface
[ https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336851#comment-15336851 ] Markus Karg commented on MRELEASE-956: -- Sounds good. I will set up a PR and report here. Stay tuned. :-) > Release Strategy Interface > -- > > Key: MRELEASE-956 > URL: https://issues.apache.org/jira/browse/MRELEASE-956 > Project: Maven Release Plugin > Issue Type: New Feature > Components: perform >Reporter: Markus Karg > Labels: strategy > > The release plugin has built-in strategies for preparation and performing of > a release. For example, the strategy for preparation contains increasing > versions numbers, comitting to SCM, tagging in SCM, and so. > Not all users share the same strategies in real life. For example, some > companies might want to have a tag AND and a branch created in SCM when > preparing a release. Or other companies might want to have tag created for > "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as > part of release:perform. > To provide better flexibility of such company-wide strategies, it might be a > solution to introduce an interface "ReleaseStrategy" which acts as a worker > for the prepare and perform goals (and possibly others). The current built-in > strategy could be refactored to be a default-included > "DefaultReleaseStrategy" for backwards compatibility, while users could > configure a new property "releaseStrategy" to point to an Extension which > provides a differently working strategy. > To make this work, certainly the Strategy implementation needs to get passed > a context which allows to fire actions like "tag version", "create branch", > "change pom version" and so on, just as the current built-in strategy has. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-956) Release Strategy Interface
[ https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336634#comment-15336634 ] Robert Scholte commented on MRELEASE-956: - That would be great. My idea would be to add to the maven-release-api the required interface(s). The current default behavior can have its implementation in the maven-release-manager, additional implementations can be added as modules. Have a look at the version policy, which should explain the pattern we have in mind. > Release Strategy Interface > -- > > Key: MRELEASE-956 > URL: https://issues.apache.org/jira/browse/MRELEASE-956 > Project: Maven Release Plugin > Issue Type: New Feature > Components: perform >Reporter: Markus Karg > Labels: strategy > > The release plugin has built-in strategies for preparation and performing of > a release. For example, the strategy for preparation contains increasing > versions numbers, comitting to SCM, tagging in SCM, and so. > Not all users share the same strategies in real life. For example, some > companies might want to have a tag AND and a branch created in SCM when > preparing a release. Or other companies might want to have tag created for > "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as > part of release:perform. > To provide better flexibility of such company-wide strategies, it might be a > solution to introduce an interface "ReleaseStrategy" which acts as a worker > for the prepare and perform goals (and possibly others). The current built-in > strategy could be refactored to be a default-included > "DefaultReleaseStrategy" for backwards compatibility, while users could > configure a new property "releaseStrategy" to point to an Extension which > provides a differently working strategy. > To make this work, certainly the Strategy implementation needs to get passed > a context which allows to fire actions like "tag version", "create branch", > "change pom version" and so on, just as the current built-in strategy has. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-956) Release Strategy Interface
[ https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336580#comment-15336580 ] Markus Karg commented on MRELEASE-956: -- If you like I could provide a PR on GitHub as an early draft. > Release Strategy Interface > -- > > Key: MRELEASE-956 > URL: https://issues.apache.org/jira/browse/MRELEASE-956 > Project: Maven Release Plugin > Issue Type: New Feature > Components: perform >Reporter: Markus Karg > Labels: strategy > > The release plugin has built-in strategies for preparation and performing of > a release. For example, the strategy for preparation contains increasing > versions numbers, comitting to SCM, tagging in SCM, and so. > Not all users share the same strategies in real life. For example, some > companies might want to have a tag AND and a branch created in SCM when > preparing a release. Or other companies might want to have tag created for > "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as > part of release:perform. > To provide better flexibility of such company-wide strategies, it might be a > solution to introduce an interface "ReleaseStrategy" which acts as a worker > for the prepare and perform goals (and possibly others). The current built-in > strategy could be refactored to be a default-included > "DefaultReleaseStrategy" for backwards compatibility, while users could > configure a new property "releaseStrategy" to point to an Extension which > provides a differently working strategy. > To make this work, certainly the Strategy implementation needs to get passed > a context which allows to fire actions like "tag version", "create branch", > "change pom version" and so on, just as the current built-in strategy has. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-956) Release Strategy Interface
[ https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336261#comment-15336261 ] Robert Scholte commented on MRELEASE-956: - Yes, I have this idea for quite some time. Just didn't had the need to implement it yet, there are enough issues screaming to be fixed too. > Release Strategy Interface > -- > > Key: MRELEASE-956 > URL: https://issues.apache.org/jira/browse/MRELEASE-956 > Project: Maven Release Plugin > Issue Type: New Feature > Components: perform >Reporter: Markus Karg > Labels: strategy > > The release plugin has built-in strategies for preparation and performing of > a release. For example, the strategy for preparation contains increasing > versions numbers, comitting to SCM, tagging in SCM, and so. > Not all users share the same strategies in real life. For example, some > companies might want to have a tag AND and a branch created in SCM when > preparing a release. Or other companies might want to have tag created for > "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as > part of release:perform. > To provide better flexibility of such company-wide strategies, it might be a > solution to introduce an interface "ReleaseStrategy" which acts as a worker > for the prepare and perform goals (and possibly others). The current built-in > strategy could be refactored to be a default-included > "DefaultReleaseStrategy" for backwards compatibility, while users could > configure a new property "releaseStrategy" to point to an Extension which > provides a differently working strategy. > To make this work, certainly the Strategy implementation needs to get passed > a context which allows to fire actions like "tag version", "create branch", > "change pom version" and so on, just as the current built-in strategy has. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MRELEASE-956) Release Strategy Interface
Markus Karg created MRELEASE-956: Summary: Release Strategy Interface Key: MRELEASE-956 URL: https://issues.apache.org/jira/browse/MRELEASE-956 Project: Maven Release Plugin Issue Type: New Feature Components: perform Reporter: Markus Karg The release plugin has built-in strategies for preparation and performing of a release. For example, the strategy for preparation contains increasing versions numbers, comitting to SCM, tagging in SCM, and so. Not all users share the same strategies in real life. For example, some companies might want to have a tag AND and a branch created in SCM when preparing a release. Or other companies might want to have tag created for "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as part of release:perform. To provide better flexibility of such company-wide strategies, it might be a solution to introduce an interface "ReleaseStrategy" which acts as a worker for the prepare and perform goals (and possibly others). The current built-in strategy could be refactored to be a default-included "DefaultReleaseStrategy" for backwards compatibility, while users could configure a new property "releaseStrategy" to point to an Extension which provides a differently working strategy. To make this work, certainly the Strategy implementation needs to get passed a context which allows to fire actions like "tag version", "create branch", "change pom version" and so on, just as the current built-in strategy has. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSTAGE-20) No implementation for org.apache.maven.plugins.stage.RepositoryCopier was bound
[
https://issues.apache.org/jira/browse/MSTAGE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335711#comment-15335711
]
Anders Jacobsen commented on MSTAGE-20:
---
I get the same error when using the plugin. It does not make any difference to
add the plexus-component-metadata plugin to the pom.xml of the stage-file.
{code}
[DEBUG] Configuring mojo org.apache.maven.plugins:maven-stage-plugin:1.0:copy
from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-stage-plugin:1.0, parent:
sun.misc.Launcher$AppClassLoader@1c8825a5]
[WARNING] Error injecting: org.apache.maven.plugins.stage.CopyRepositoryMojo
com.google.inject.ProvisionException: Unable to provision, see the following
errors:
1) No implementation for org.apache.maven.plugins.stage.RepositoryCopier was
bound.
while locating org.apache.maven.plugins.stage.CopyRepositoryMojo
1 error
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1018)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
at
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at
org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
at
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
at
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:36)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at
org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:546)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
[jira] [Commented] (MSHARED-552) add a utility to activate ANSI color only if Maven 3.4+
[ https://issues.apache.org/jira/browse/MSHARED-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335564#comment-15335564 ] Hudson commented on MSHARED-552: SUCCESS: Integrated in maven-shared #2155 (See [https://builds.apache.org/job/maven-shared/2155/]) [MSHARED-552] forgot toString() method... (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1748798]) * maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/AnsiUtils.java > add a utility to activate ANSI color only if Maven 3.4+ > --- > > Key: MSHARED-552 > URL: https://issues.apache.org/jira/browse/MSHARED-552 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-project-utils >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: maven-project-utils-1.0.0 > > > Some plugins implement color messages > Having such color messages when running without color Maven (introduced in > Maven 3.4.0 MNG-3507) will look strange > it's better if color is activated only when Maven 3.4 color support is there -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-779) add color to report generation messages
[
https://issues.apache.org/jira/browse/MSITE-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335563#comment-15335563
]
Hudson commented on MSITE-779:
--
SUCCESS: Integrated in maven-plugins #6469 (See
[https://builds.apache.org/job/maven-plugins/6469/])
[MSITE-779] removed JAnsi dependency: not used directly any more (hboutemy:
[http://svn.apache.org/viewvc/?view=rev=1748799])
* maven-site-plugin/pom.xml
> add color to report generation messages
> ---
>
> Key: MSITE-779
> URL: https://issues.apache.org/jira/browse/MSITE-779
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.5.1
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 3.6
>
>
> with ANSI color support added in MNG-3507, it would be useful to use the same
> color rendering for report generation messages:
> {noformat}[INFO] Generating "Summary" report ---
> maven-project-info-reports-plugin:2.9:summary{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
