[jira] (MNG-5615) Rework credentials handling
Anders Hammar created MNG-5615: -- Summary: Rework credentials handling Key: MNG-5615 URL: https://jira.codehaus.org/browse/MNG-5615 Project: Maven 2 & 3 Issue Type: Improvement Components: Settings Environment: n/a Reporter: Anders Hammar It would be great with a way to handle credentials outside of settings.xml. Preferably in a pluggable manner so that it can be integratedwith corporate environments for example. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5615) Rework credentials handling
[ https://jira.codehaus.org/browse/MNG-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MNG-5615: --- Fix Version/s: Issues to be reviewed for 4.x > Rework credentials handling > --- > > Key: MNG-5615 > URL: https://jira.codehaus.org/browse/MNG-5615 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Settings > Environment: n/a >Reporter: Anders Hammar > Fix For: Issues to be reviewed for 4.x > > > It would be great with a way to handle credentials outside of settings.xml. > Preferably in a pluggable manner so that it can be integratedwith corporate > environments for example. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5604) make it possible to mark a maven module as deprected
[
https://jira.codehaus.org/browse/MNG-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344710#comment-344710
]
Kenney Westerhof commented on MNG-5604:
---
Deprecation always requires a reference to the preferred solution, because if
the functionality is not provided by an alternative, the module is still useful.
The idea behind Maven is to have stable builds, producing the same result on
any system, but it does allow for automatic project metadata updates using
version ranges on dependencies.
The relocation functionality was made to cover cases such as projects not
adhering to decent versioning standards and is a different problem. In this
case it can be used to automatically update from log4j 1.2.17 to 2.0 even
though the artifactId has changed.
A project moving away from using one library in favour of another will manage
the change on it's end: by changing the dependencies and updating their code to
conform to the new API. Similarly, using version ranges resulting in an
incompatible dependency being used, either the pom or the code must be changed.
Either way, it requires manual intervention which is a pretty clear message.
That said, nothing is stopping you from adding that XML snippet to the pom, for
instance in a section of a plugin. No-one said that plugin
configuration should be imperative only. My suggestion would be to add a mojo
to the enforcer-plugin which inspects the reactor models for enforcer-plugin
configuration for the deprecation information and display a notice.
This leaves whether or not to receive deprecation warnings up to the projects
using potentially deprecated dependencies, opens the door for more flexibility
without having to rely on the POM to change, and fit's with Maven's design of
providing standardized, extensible project lifecycle management.
> make it possible to mark a maven module as deprected
>
>
> Key: MNG-5604
> URL: https://jira.codehaus.org/browse/MNG-5604
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Klaus Claszen
>Priority: Minor
> Labels: build, pom.xml
>
> It would be great if it would be possible to mark a maven module as
> 'deprecated'. It would help to document that a module is outdated. The
> information could be used during build processes to show warnings and guide
> the user to a better alternative.
> Maybe it could be a pom enhancement linke this
> {code:xml}
>
> not maintained anymore
>
> foo
> bar
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-671) Cryptic debug warning message needs improvement and/or documentation
[
https://jira.codehaus.org/browse/MASSEMBLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344701#comment-344701
]
William Ferguson commented on MASSEMBLY-671:
NB I would open the issue again if I could, but I don't seem to have that
capability
> Cryptic debug warning message needs improvement and/or documentation
>
>
> Key: MASSEMBLY-671
> URL: https://jira.codehaus.org/browse/MASSEMBLY-671
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2.1, 2.4
> Environment: irrelevant
>Reporter: Steve Cohen
>
> I have used the assembly plugin both versions 2.4 and 2.2.1. While the
> plugin basically works, I have some problems with it, (see MASSEMBLY-670),
> which I suspect may be related to the following message that shows up when
> running Maven in debug mode (-X):
> {noformat}
> [DEBUG] All known ContainerDescriptorHandler components: [plexus,
> metaInf-spring, metaInf-services, file-aggregator]
> [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException
> role: org.apache.maven.artifact.resolver.ArtifactResolver
> roleHint: project-cache-aware
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at
> com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
> at
> com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
> at
> org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
> at
> org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
> at
> org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112)
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>at or
[jira] (MASSEMBLY-671) Cryptic debug warning message needs improvement and/or documentation
[
https://jira.codehaus.org/browse/MASSEMBLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344699#comment-344699
]
William Ferguson commented on MASSEMBLY-671:
Sent pull request containing a simple modification of the assembly descriptor
that shows 671.
> Cryptic debug warning message needs improvement and/or documentation
>
>
> Key: MASSEMBLY-671
> URL: https://jira.codehaus.org/browse/MASSEMBLY-671
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2.1, 2.4
> Environment: irrelevant
>Reporter: Steve Cohen
>
> I have used the assembly plugin both versions 2.4 and 2.2.1. While the
> plugin basically works, I have some problems with it, (see MASSEMBLY-670),
> which I suspect may be related to the following message that shows up when
> running Maven in debug mode (-X):
> {noformat}
> [DEBUG] All known ContainerDescriptorHandler components: [plexus,
> metaInf-spring, metaInf-services, file-aggregator]
> [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException
> role: org.apache.maven.artifact.resolver.ArtifactResolver
> roleHint: project-cache-aware
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at
> com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
> at
> com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
> at
> org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
> at
> org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
> at
> org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112)
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>
[jira] (MNG-5478) Order of plugin execution does not match order of definition in profile
[
https://jira.codehaus.org/browse/MNG-5478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344698#comment-344698
]
David Eckel commented on MNG-5478:
--
MNG-5539 may be a duplicate of this issue. There may be additional details
there that can help with this issue.
> Order of plugin execution does not match order of definition in profile
> ---
>
> Key: MNG-5478
> URL: https://jira.codehaus.org/browse/MNG-5478
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle, Profiles
>Affects Versions: 3.0.5
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
> Maven home: /usr/local/Cellar/maven/3.0.5/libexec
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.7.5", arch: "x86_64", family: "mac"
>Reporter: Martin Burger
>
> I would like to create an assembly that contains an obfuscated all-in-one
> version of the main JAR artifacts of a multi-module project. For this
> purpose, I created a profile that binds the following plugins and goals,
> respectively, to phase {{package}}:
> # {{maven-shade-plugin:shade}} - creates a single JAR file that contains all
> classes of all modules (basically, an uberjar that, however, does not contain
> 3rd-party libraries)
> # {{proguard-maven-plugin:proguard}} - creates an obfuscated version of the
> above JAR file
> # {{maven-assembly-plugin:single}} - creates a single distributable archive
> that contains the above obfuscated JAR file alongside of 3rd-party JAR files
> and some CLI scripts
> Having the above configuration, it should be sufficient to call {{maven
> package}} in order to create the desired assembly.
> However, the plugins are not executed in the above order but the ProGuard
> plugin gets executed first which consequently complains about the missing
> input file (the latter should be created by the Shade plugin).
> As a workaround, I created a profile that only binds the first two plugins to
> phase {{package}}. Furthermore, I first call {{mvn package}} to create the
> obfuscated "uberjar"; only then, I call {{mvn assembly:single}} to create the
> desired assembly file.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-171) Site plugin uses plain dependencies for reactor projects instead of results of earlier modules
[ https://jira.codehaus.org/browse/MSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344693#comment-344693 ] Florian Brunner commented on MSITE-171: --- 36 votes! Any updates? > Site plugin uses plain dependencies for reactor projects instead of results > of earlier modules > -- > > Key: MSITE-171 > URL: https://jira.codehaus.org/browse/MSITE-171 > Project: Maven Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-5 > Environment: Win XP, Linux >Reporter: Alex Rau > Attachments: install_site_runs.log, site_fails.log, > subsequent_site_runs.log > > > When creating a multi-module site the site plugin uses dependencies from > related modules from the repository instead of using artifacts from the same > execution. > That causes inconsistent reports on the sites. An example: > Project A has modules B and C defined. B is build first and a site for > project B is created. Then project C is build using a dependency either from > the local or remote repository. Therefore the site contains results which > rely on a build with an "out-dated" artifact used as dependency. This leads > to plainly wrong results when examining surefire-reports as Project C should > have been build with the (current) artifact of project B (taken from the same > execution of the site plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-746) Use '--' to separate filenames from revisions within Git
deckrider created SCM-746: - Summary: Use '--' to separate filenames from revisions within Git Key: SCM-746 URL: https://jira.codehaus.org/browse/SCM-746 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.9 Environment: git version 1.7.10.5 Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+) Java version: 1.7.0_45, vendor: Oracle Corporation Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "2.6.32-358.11.1.el6.x86_64", arch: "amd64", family: "unix" Reporter: deckrider Priority: Minor We had a maven multi module project where a module was unfortunately named "master". This caused a problem when working on the Git master branch: Provider message: The git-log command failed. Command output: --- >From file:///foo/bar * branchmaster -> FETCH_HEAD fatal: ambiguous argument 'master': both revision and filename Use '--' to separate filenames from revisions --- Our workaround was to rename the "master" module to "master-module" and reflect that in the parent pom which lists all the module directories. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5613) NPE error when building a reactor with duplicated artifacts
[
https://jira.codehaus.org/browse/MNG-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344691#comment-344691
]
Jason van Zyl commented on MNG-5613:
Great, thanks Dominique.
> NPE error when building a reactor with duplicated artifacts
> ---
>
> Key: MNG-5613
> URL: https://jira.codehaus.org/browse/MNG-5613
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Dominique Broeglin
> Attachments: foo.zip
>
>
> Using v3.2.1 when building a malformed project containing a duplicated
> groupId:artifactId I got this rather unhelpful error:
> {code}
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> 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:601)
> 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
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:270)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> ... 11 more
> {code}
> The more helpful error should have been:
> {code}
> org.apache.maven.project.DuplicateProjectException: Project
> 'com.foo.bar:foo-bar:2.15.0' is duplicated in the reactor
> at org.apache.maven.project.ProjectSorter.(ProjectSorter.java:93)
> at
> org.apache.maven.DefaultProjectDependencyGraph.(DefaultProjectDependencyGraph.java:53)
> at
> org.apache.maven.DefaultMaven.createProjectDependencyGraph(DefaultMaven.java:819)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:268)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> 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:601)
> 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
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-332) Update to maven-reporting-impl 2.2
[ https://jira.codehaus.org/browse/MCHANGES-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-332. Resolution: Fixed Fix Version/s: 2.10 Assignee: Dennis Lundberg Fixed in [r1586395|http://svn.apache.org/viewvc?view=revision&revision=1586395]. > Update to maven-reporting-impl 2.2 > -- > > Key: MCHANGES-332 > URL: https://jira.codehaus.org/browse/MCHANGES-332 > Project: Maven Changes Plugin > Issue Type: Task >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.10 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-331) Update to Doxia 1.4 and Doxia Sitetools 1.4
[ https://jira.codehaus.org/browse/MCHANGES-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-331. Resolution: Fixed Fix Version/s: 2.10 Assignee: Dennis Lundberg Fixed in [r1586395|http://svn.apache.org/viewvc?view=revision&revision=1586395]. > Update to Doxia 1.4 and Doxia Sitetools 1.4 > --- > > Key: MCHANGES-331 > URL: https://jira.codehaus.org/browse/MCHANGES-331 > Project: Maven Changes Plugin > Issue Type: Task >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.10 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-332) Update to maven-reporting-impl 2.2
Dennis Lundberg created MCHANGES-332: Summary: Update to maven-reporting-impl 2.2 Key: MCHANGES-332 URL: https://jira.codehaus.org/browse/MCHANGES-332 Project: Maven Changes Plugin Issue Type: Task Reporter: Dennis Lundberg -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-331) Update to Doxia 1.4 and Doxia Sitetools 1.4
Dennis Lundberg created MCHANGES-331: Summary: Update to Doxia 1.4 and Doxia Sitetools 1.4 Key: MCHANGES-331 URL: https://jira.codehaus.org/browse/MCHANGES-331 Project: Maven Changes Plugin Issue Type: Task Reporter: Dennis Lundberg -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344684#comment-344684
]
Robert Scholte commented on MCHECKSTYLE-225:
[~dennislundberg], the piece of code is a bit too small to see what's happening
here. The {{LicenseResourceManager}} has several ResourceLoader, such as jar,
file and this one. It will loop over these resourceLoaders until in has found
the resource. MCHECKSTYLE-219 shows that files from the maven-checkstyle-plugin
can leak. There's only one file which is allowed to be pulled from the plugin,
and that is the {{config/maven-header.txt}}. The next line after the
if-statement (but within the for-loop) tries to find the resource.
MCHECKSTYLE-225 shows there's another way to refer to a license, for which no
integration-test was written yet. This is an additional jar, which is added as
dependency so it ends up on the classpath. Right now there's a discussion about
immutable classpaths on the dev-list and this is a nice example. The
license-jar is just an additional jar and has nothing to do with the classpath
of the plugin. It could be any file, as long as the checkstyle-plugin knows how
to pick it up. We're working on a proposal for this, but it requires a
modification in the pom.xml.
For now we need to restore the ability to add a license by dependency, without
searching through the original dependencies of the plugin. I think I've found a
solution, but need to write some more tests to confirm that only the additional
jars are read.
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>Assignee: Robert Scholte
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MCHECKSTYLE-225:
--
Assignee: Robert Scholte
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>Assignee: Robert Scholte
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-875) release:prepare does not commit pom.xml if not in the git root
[
https://jira.codehaus.org/browse/MRELEASE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344681#comment-344681
]
Robert Scholte commented on MRELEASE-875:
-
Version 2.5 was a Git special release, which should have fixed this issue
(SCM-709). A couple of users confirmed that this fixed their issues, so I'm
surprised you hit it again.
To narrow the issue: how about the combinations m-release-p-2.4.2 + Git 1.9.0
and m-release-p-2.5 + Git 1.7?
When running with debug logging (add {{\-X}} or {{\--debug}} to your
commandline), you'll see the Git commandlines being executed. What do you see
and what should it be?
> release:prepare does not commit pom.xml if not in the git root
> --
>
> Key: MRELEASE-875
> URL: https://jira.codehaus.org/browse/MRELEASE-875
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.5
> Environment: git 1.9.0
>Reporter: john ten Den
>
> When the project pom.xml is not in the Git project root (f.e. in the "src"
> directory) the pom.xml not committed and pushed (before tagging)
> Commit of the pom.xml during release:prepare works fine if it is in the /
> (root) of the git repository
> Using the pom.xml in a subdirectory worked well with version 2.4.2 using git
> 1.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5478) Order of plugin execution does not match order of definition in profile
[
https://jira.codehaus.org/browse/MNG-5478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344680#comment-344680
]
Christopher Tubbs commented on MNG-5478:
Okay, I was definitely able to verify that it still executes out of order, at
least with the maven-release-plugin executing items in a profile. The problem
seems to happen with 3.0.4, 3.1.1, and 3.2.1. The following is the relevant
section of my POM:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
org.apache.accumulo
accumulo-project
1.6.0
accumulo-docs
pom
Documentation
User documentation for Apache Accumulo.
docs
org.apache.accumulo
accumulo-core
org.codehaus.mojo
exec-maven-plugin
prep-output-dir
exec
compile
mkdir
-p
${project.build.directory}/latex/accumulo_user_manual/appendices
config-html
java
compile
org.apache.accumulo.core.conf.DefaultConfiguration
compile
--generate-html
${project.build.directory}/config.html
config-appendix
java
compile
org.apache.accumulo.core.conf.DefaultConfiguration
compile
--generate-latex
${project.build.directory}/latex/accumulo_user_manual/appendices/config.tex
org.codehaus.mojo
latex-maven-plugin
build-pdf-manuals
latex
org.codehaus.mojo
build-helper-maven-plugin
attach-user-manual-pdf
attach-artifact
${project.build.directory}/accumulo_user_manual.pdf
pdf
user-manual
{code}
And this is the relevant debug output:
{code}
[INFO] [DEBUG]
---
[INFO] [DEBUG] Goal: org.codehaus.mojo:latex-maven-plugin:1.1:latex
(build-pdf-manuals)
[INFO] [DEBUG] Style: Regular
[INFO] [DEBUG] Configuration:
[INFO]
[INFO] ${latex.binariesPath}
[INFO] ${project.build.directory}
[INFO] ${latex.commonsDirName}
[INFO] ${latex.docsRoot}
[INFO] ${project.latex.build.directory}
[INFO]
[INFO] [DEBUG]
---
[INFO] [DEBUG] Goal: org.codehaus.mojo:exec-maven-plugin:1.2.1:exec
(prep-output-dir)
[INFO] [DEBUG] Style: Regular
[INFO] [DEBUG] Configuration:
[INFO]
[INFO]
[INFO] -p
[INFO]
/local/cltubbs/git/apache/accumulo/docs/target/latex/accumulo_user_manual/appendices
[INFO]
[INFO]
[INFO] ${exec.classpathScope}
[INFO] ${exec.args}
[INFO] mkdir
[INFO] ${exec.longClasspath}
[INFO] ${exec.outputFile}
[INFO]
[INFO]
[INFO] ${skip}
[INFO] ${sourceRoot}
[INFO] ${testSourceRoot}
[INFO] ${exec.workingdir}
[INFO]
[INFO] [DEBUG] --- init fork of org.apache.accumulo:accumulo-docs:1.6.0 for
org.codehaus.mojo:exec-maven-plugin:1.2.1:java (config-html) ---
[INFO] [DEBUG] Dependencies (collect): []
[INFO] [DEBUG] Dependencies (resolve): [test]
[INFO] [DEBUG]
---
[INFO] [DEBUG] Goal:
com.google.code.sortpom:maven-sortpom-plugin:2.3.0:verify (verify-sorted-pom)
[INFO] [DEBUG] Style: Regular
[INFO] [DEBUG] Configuration:
[INFO]
[INFO] ${sort.backupFileExtension}
[INFO] ${sort.createBackupFile}
[INFO] ${sort.encoding}
{code}
Note: the latex-maven-plugin binds to the compile phase by default, and the
project builds fine with verify, but not with the release:prepare (with
preparationGoals set to verify). When I explicitly set t
[jira] (MRELEASE-875) release:prepare does not commit pom.xml if not in the git root
john ten Den created MRELEASE-875: - Summary: release:prepare does not commit pom.xml if not in the git root Key: MRELEASE-875 URL: https://jira.codehaus.org/browse/MRELEASE-875 Project: Maven Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.5 Environment: git 1.9.0 Reporter: john ten Den When the project pom.xml is not in the Git project root (f.e. in the "src" directory) the pom.xml not committed and pushed (before tagging) Commit of the pom.xml during release:prepare works fine if it is in the / (root) of the git repository Using the pom.xml in a subdirectory worked well with version 2.4.2 using git 1.7. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://jira.codehaus.org/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reopened MNG-5359: Re-opening as there is an IT attached. > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://jira.codehaus.org/browse/MNG-5359 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-191) bannedDependencies shouls work with regeg pattern as banTransitiveDependencies does
[ https://jira.codehaus.org/browse/MENFORCER-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Brugger updated MENFORCER-191: --- Patch Submitted: Yes Attachment: enforcer-rules.patch Testcase included: yes > bannedDependencies shouls work with regeg pattern as > banTransitiveDependencies does > --- > > Key: MENFORCER-191 > URL: https://jira.codehaus.org/browse/MENFORCER-191 > Project: Maven Enforcer Plugin > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: Marc Brugger > Attachments: enforcer-rules.patch > > > banTransitiveDependencies does work with regex pattern by using the > org.apache.maven.plugins.enforcer.utils.ArtifactMatcher class. > The same should be used for bannedDependencies -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-191) bannedDependencies shouls work with regeg pattern as banTransitiveDependencies does
Marc Brugger created MENFORCER-191: -- Summary: bannedDependencies shouls work with regeg pattern as banTransitiveDependencies does Key: MENFORCER-191 URL: https://jira.codehaus.org/browse/MENFORCER-191 Project: Maven Enforcer Plugin Issue Type: Bug Affects Versions: 1.3.1 Reporter: Marc Brugger banTransitiveDependencies does work with regex pattern by using the org.apache.maven.plugins.enforcer.utils.ArtifactMatcher class. The same should be used for bannedDependencies -- This message was sent by Atlassian JIRA (v6.1.6#6162)
