[jira] Created: (MRRESOURCES-50) Add @threadSafe support for maven3
Add @threadSafe support for maven3 -- Key: MRRESOURCES-50 URL: http://jira.codehaus.org/browse/MRRESOURCES-50 Project: Maven 2.x Remote Resources Plugin Issue Type: Improvement Reporter: Baptiste MATHUS Would be great if this plugin could be marked as thread-safe to be able to enable parallel build using this plugin. Cheers -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-106) Add @threadSafe support for maven3
Add @threadSafe support for maven3 -- Key: MENFORCER-106 URL: http://jira.codehaus.org/browse/MENFORCER-106 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Reporter: Baptiste MATHUS Would be great if this plugin could be marked as thread-safe to be able to enable parallel build using this plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MENFORCER-98) requirePluginVersions rule is not compatible with maven 3.0-beta-1
[
http://jira.codehaus.org/browse/MENFORCER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234740#action_234740
]
Petr Kozelka commented on MENFORCER-98:
---
with Maven 3.0-beta-3 it does not check again
{noformat}
...
[INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-plugin-versions) @
systinet-pom ---
[WARNING] This rule is not compatible with the current version of Maven. The
rule is not able to perform any checks.
...
{noformat}
requirePluginVersions rule is not compatible with maven 3.0-beta-1
--
Key: MENFORCER-98
URL: http://jira.codehaus.org/browse/MENFORCER-98
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-beta-1
Environment: Windows XP
Sun JDK 1.6.0_18
Maven 3.0-beta-1
Reporter: Anders Hammar
When using the requirePluginVersions rule, I get a message saying This rule
is not compatible with the current version of Maven. The rule is not able to
perform any checks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
release:prepare should stop when there is snapshots in dependencies management -- Key: MRELEASE-594 URL: http://jira.codehaus.org/browse/MRELEASE-594 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: thomas bruyelle -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ http://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRELEASE-594: -- Fix Version/s: 2.1 Assignee: Olivier Lamy release:prepare should stop when there is snapshots in dependencies management -- Key: MRELEASE-594 URL: http://jira.codehaus.org/browse/MRELEASE-594 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: thomas bruyelle Assignee: Olivier Lamy Fix For: 2.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4802) Maven should by default use the environment defined proxy settings
Maven should by default use the environment defined proxy settings -- Key: MNG-4802 URL: http://jira.codehaus.org/browse/MNG-4802 Project: Maven 2 3 Issue Type: New Feature Components: Settings Affects Versions: 2.2.1 Reporter: Hugo Palma For people that constantly change places of work it's very annoying having to edit the settings.xml files every time. It would be great if the environment proxy settings were used when no proxy settings were defined in settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ http://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234744#action_234744 ] Joerg Schaible commented on MRELEASE-594: - Such a functionality must be activated via configuration only. In an enviornment using a parent POM for an organization it is *normal* to have some deps in the depMgmt set to SNAPSHOT. This is totally fine as long as they are not used for a release. A strict requirement for all of them to be non-SNAPSHOTs would break our Maven process completely. release:prepare should stop when there is snapshots in dependencies management -- Key: MRELEASE-594 URL: http://jira.codehaus.org/browse/MRELEASE-594 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: thomas bruyelle Assignee: Olivier Lamy Fix For: 2.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ http://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234746#action_234746 ] thomas bruyelle commented on MRELEASE-594: -- Ok, is this true also when the release is done on the parent itself ? release:prepare should stop when there is snapshots in dependencies management -- Key: MRELEASE-594 URL: http://jira.codehaus.org/browse/MRELEASE-594 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: thomas bruyelle Assignee: Olivier Lamy Fix For: 2.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4802) Maven should by default use the environment defined proxy settings
[ http://jira.codehaus.org/browse/MNG-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234747#action_234747 ] Benjamin Bentmann commented on MNG-4802: What exactly are environment proxy settings here, native OS settings? Also, the settings.xml are user/machine specific so why is there a need to edit the settings.xml files every time.? Maven should by default use the environment defined proxy settings -- Key: MNG-4802 URL: http://jira.codehaus.org/browse/MNG-4802 Project: Maven 2 3 Issue Type: New Feature Components: Settings Affects Versions: 2.2.1 Reporter: Hugo Palma For people that constantly change places of work it's very annoying having to edit the settings.xml files every time. It would be great if the environment proxy settings were used when no proxy settings were defined in settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ http://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234748#action_234748 ] Olivier Lamy commented on MRELEASE-594: --- Hi Joerg, uhm not fully agree on the normal :-) The use case is release a parent with a SNAPSHOT in depMgmt. Then release a child with dependency which is finally now SNAPSHOT will failed due to the version inheritance. Yes we could make to configurable stuff but IMHO it should failed by default in such case. Sure it will backward non compatible. Others WDYT here ? release:prepare should stop when there is snapshots in dependencies management -- Key: MRELEASE-594 URL: http://jira.codehaus.org/browse/MRELEASE-594 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: thomas bruyelle Assignee: Olivier Lamy Fix For: 2.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4798) NullPointerException at NearestVersionConflictResolver.selectVersion()
[ http://jira.codehaus.org/browse/MNG-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4798. -- Resolution: Not A Bug Assignee: Benjamin Bentmann Please fill this as a bug against the JDK vendor. NullPointerException at NearestVersionConflictResolver.selectVersion() -- Key: MNG-4798 URL: http://jira.codehaus.org/browse/MNG-4798 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-beta-3 Environment: Maven 3 beta-3, Linux, Java 1.6.0_21 Reporter: Jochen Stiepel Assignee: Benjamin Bentmann this error only occurs with Maven 3 beta-3 but not Maven 3 beta-2. Maby it is related to this error, but has a different stacktrace: MNG-4779 [ERROR] Internal error: java.lang.NullPointerException - [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException at org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:141) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:99) 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:315) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.NullPointerException at org.sonatype.aether.util.graph.transformer.NearestVersionConflictResolver.selectVersion(NearestVersionConflictResolver.java:218) at org.sonatype.aether.util.graph.transformer.NearestVersionConflictResolver.transformGraph(NearestVersionConflictResolver.java:81) at org.sonatype.aether.util.graph.transformer.ChainedDependencyGraphTransformer.transformGraph(ChainedDependencyGraphTransformer.java:76) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:246) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:265) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:117) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:202) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:141) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveDependencies(LifecycleDependencyResolver.java:118) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveDependencies(LifecycleDependencyResolver.java:82) at org.apache.maven.lifecycle.internal.BuilderCommon.resolveBuildPlan(BuilderCommon.java:130) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:83) ... 16 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-562) release:prepare uses incorrect tag source on multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234753#action_234753 ] Cornel Masson commented on MRELEASE-562: AH! I think I might know why this is happening: I've logged a new issue since I think it is a bug and should have a more specific title: [MRELEASE-595] release:prepare uses incorrect tag source on multi-module projects -- Key: MRELEASE-562 URL: http://jira.codehaus.org/browse/MRELEASE-562 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0 Reporter: Juven Xu source code layout: svn://host/app/pom.xml (aggregator) svn://host/app/app-parent/pom.xml (parent) svn://host/app/app-module-a/pom.xml svn://host/app/app-module-b/pom.xml run mvn release:prepare in the aggreagtor foler, I see output like this: [INFO] Executing: cmd.exe /X /C svn --non-interactive copy --file C:\Users\JUVEN\AppData\Local\Temp\maven-scm-2081030526.commit --revision 25 svn://192.168.1.103/app/ svn://192.168.1.103/app/tags/app-aggregator-1.0.0 the tag source should be svn://192.168.1.103/app/trunk similar issue was reported in maven user list: http://old.nabble.com/multi-modules,-scm-and-release-plugin-td28289933.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4802) Maven should by default use the environment defined proxy settings
[ http://jira.codehaus.org/browse/MNG-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234752#action_234752 ] Hugo Palma commented on MNG-4802: - By environment proxy settings i mean the native OS settings. It's very much possible and easy to get those in a Java application. Answering your second question, i'm sure a lot of people have a laptop and use it both at work and at home. At work you have to use a proxy, at home you don't. Is there any way i can use maven following this pattern without having to edit the settings.xml file twice a day ? Maven should by default use the environment defined proxy settings -- Key: MNG-4802 URL: http://jira.codehaus.org/browse/MNG-4802 Project: Maven 2 3 Issue Type: New Feature Components: Settings Affects Versions: 2.2.1 Reporter: Hugo Palma For people that constantly change places of work it's very annoying having to edit the settings.xml files every time. It would be great if the environment proxy settings were used when no proxy settings were defined in settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-595) release:prepare using old SVN structure when creating tag
release:prepare using old SVN structure when creating tag
-
Key: MRELEASE-595
URL: http://jira.codehaus.org/browse/MRELEASE-595
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_18
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Cornel Masson
I made a change in my project's SVN folder structure, and now release:prepare
is creating the tag using the old structure. Example:
In my organization, each project has sub-folders for trunk, tags and branches.
However, my test projectA started out (incorrectly) in SVN *without*
trunk/tags/branches subfolders:
{code}
svnhost/code/projectA:
/gui
/model
-pom.xml
{code}
Later, I realised my mistake, created a trunk subfolder under projectA, and
moved the project contents into trunk. I also added tags and branches folders:
{code}
svnhost/code/projectA:
/trunk
/gui
/model
-pom.xml
/tags
/branches
{code}
I re-checked out a clean projectA and did release:prepare with tagBase =
{{svnhost/code/projectA/tags}} and tag name 'MyTag'. It created MyTag, but the
contents was *all* of trunk/tags/branches(!):
{code}
svnhost/code/projectA:
/trunk
/gui
/model
-pom.xml
/tags
/MyTag
/trunk
/gui
/model
-pom.xml
/tags
/branches
/branches
{code}
instead of just using the contents of trunk at that point.
It looks like it's picking up the *old* SVN structure from the projectA folder.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2879) Thousands of [WARNING] Component returned which is not the same manager.
[ http://jira.codehaus.org/browse/MNG-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234765#action_234765 ] Dmitry Katsubo commented on MNG-2879: - @Paul Benedict: If this warning is an issue to be solved, why not to close it when Maven 3 is released? I confirm the problem for IBM JDK (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32) and Maven 2.2.1 (r801777). Thousands of [WARNING] Component returned which is not the same manager. Key: MNG-2879 URL: http://jira.codehaus.org/browse/MNG-2879 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.6 Reporter: Brian Fox Assignee: Jason van Zyl It happens when processing resources, mostly for war projects although I'm not 100% positive it's only wars. We see one of these warnings apparently for every file processed because sometimes there are just a few and sometimes there are 1000s correlating to the number of files in the project. So far it only happens on dual-core machines although not every time. It smells of a multithreading issue. This issue has already been fixed in PLX-287. This MNG issue is to try and get that fix into 2.0.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4803) Include few new helpful methods to ArtifactVersion interface
Include few new helpful methods to ArtifactVersion interface - Key: MNG-4803 URL: http://jira.codehaus.org/browse/MNG-4803 Project: Maven 2 3 Issue Type: Improvement Reporter: Prashant Bhate It is Useful to include following helpful methods to interface ArtifactVersion and corresponding implementation in DefaultArtifactVersion class getMajorVersion getNextMinorVersion Implementation is easy just do currentVersion+1 It would help towards merging functionality of org.apache.maven.shared.release.versions.VersionInfo into this see http://maven.apache.org/maven-release/maven-release-manager/xref/org/apache/maven/shared/release/versions/VersionInfo.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-500) Embedded error: Unrecognised tag: 'files' (position: START_TAG seen .../includeBaseDirectory\n\n\nfiles... @9:8)
Embedded error: Unrecognised tag: 'files' (position: START_TAG seen .../includeBaseDirectory\n\n\nfiles... @9:8) Key: MASSEMBLY-500 URL: http://jira.codehaus.org/browse/MASSEMBLY-500 Project: Maven 2.x Assembly Plugin Issue Type: Bug Reporter: Dayashankar Attachments: assembly.xml Hi team, I'm using attached assembly.xml file and while doing mvn assembly:assembly is resulting in following error: [INFO] Error reading descriptor Embedded error: Unrecognised tag: 'files' (position: START_TAG seen .../includeBaseDirectory\n\n\nfiles... @9:8) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error reading descriptor at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading descriptor at org.apache.maven.plugin.assembly.AssemblyMojo.readAssembly(AssemblyMojo.java:238) at org.apache.maven.plugin.assembly.AssemblyMojo.execute(AssemblyMojo.java:144) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'files' (position: START_TAG seen .../includeBaseDirectory\n\n\nfiles... @9:8) at org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.parseAssembly(AssemblyXpp3Reader.java:371) at org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.read(AssemblyXpp3Reader.java:982) at org.apache.maven.plugin.assembly.AssemblyMojo.readAssembly(AssemblyMojo.java:230) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ http://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234770#action_234770 ] Joerg Schaible commented on MRELEASE-594: - @Thomas: Yes, it has to. The parent is an artifact on its own defining the versions for any shared artifact (external and internal ones) in the organization. It is in the responsibility of the project to ensure that any of those shared artifacts is released before the project's own release. If not, the required shared artifacts have to be released first, the depMgmt version of the global POM is updated and released also. @Olivier: Yes, the release of the child will fail, but only if it depends on a SNAPSHOT. See, in an organizational POM you manage different components that may or may not be used together. Typically one 3rd of all our internal artifacts (~250) stay on SNAPSHOT for minor releases of individual components or projects. It would be a QA nightmare forcing a release for all of them and would make the release plugin completely unusable for us. And I am quite sure that this *is* normal for an organizational POM. release:prepare should stop when there is snapshots in dependencies management -- Key: MRELEASE-594 URL: http://jira.codehaus.org/browse/MRELEASE-594 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Thomas Bruyelle Assignee: Olivier Lamy Fix For: 2.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2879) Thousands of [WARNING] Component returned which is not the same manager.
[ http://jira.codehaus.org/browse/MNG-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234775#action_234775 ] jieryn commented on MNG-2879: - Is Maven-2.2.1 no longer supported when Maven-3 comes along? Thousands of [WARNING] Component returned which is not the same manager. Key: MNG-2879 URL: http://jira.codehaus.org/browse/MNG-2879 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.6 Reporter: Brian Fox Assignee: Jason van Zyl It happens when processing resources, mostly for war projects although I'm not 100% positive it's only wars. We see one of these warnings apparently for every file processed because sometimes there are just a few and sometimes there are 1000s correlating to the number of files in the project. So far it only happens on dual-core machines although not every time. It smells of a multithreading issue. This issue has already been fixed in PLX-287. This MNG issue is to try and get that fix into 2.0.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-561) autoVersionSubmodules causes an AssertionError with release:branch
[
http://jira.codehaus.org/browse/MRELEASE-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234783#action_234783
]
Alexander Daniel commented on MRELEASE-561:
---
Also happens with release:prepare with Maven 2.2.1 and Java 6.
STEPS TO REPRODUCE (with attached reproduce.tgz)
tar xzf reproduce.tgz cd releasePluginSpike java -version mvn -version
export MAVEN_OPTS='-enableassertions' mvn release:prepare
-DautoVersionSubmodules=true
OUTPUT
$ tar xzf reproduce.tgz cd releasePluginSpike java -version mvn
-version export MAVEN_OPTS='-enableassertions' mvn release:prepare
-DautoVersionSubmodules=true
java version 1.6.0_20
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_20
Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.32-24-generic arch: amd64 Family: unix
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Unnamed - spike:releasePluginSpike:pom:0.1-SNAPSHOT
[INFO] Unnamed - spike:releasePluginSpike-common:jar:0.1-SNAPSHOT
[INFO]
[INFO] Building Unnamed - spike:releasePluginSpike:pom:0.1-SNAPSHOT
[INFO]task-segment: [release:prepare] (aggregator-style)
[INFO]
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: /bin/sh -c cd /home/alex/Desktop/releasePluginSpike svn
--non-interactive status
[INFO] Working directory: /home/alex/Desktop/releasePluginSpike
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for Unnamed -
spike:releasePluginSpike:pom:0.1-SNAPSHOT? (spike:releasePluginSpike) 0.1: :
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.AssertionError
at
org.apache.maven.shared.release.config.ReleaseDescriptor.mapReleaseVersion(ReleaseDescriptor.java:1400)
at
org.apache.maven.shared.release.phase.MapVersionsPhase.execute(MapVersionsPhase.java:128)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 4 seconds
[INFO] Finished at: Thu Sep 09 15:46:49 CEST 2010
[INFO] Final Memory: 23M/291M
[INFO]
[jira] Updated: (MRELEASE-561) autoVersionSubmodules causes an AssertionError with release:branch
[ http://jira.codehaus.org/browse/MRELEASE-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Daniel updated MRELEASE-561: -- Attachment: reproduce.tgz Sample project to reproduce the issue autoVersionSubmodules causes an AssertionError with release:branch -- Key: MRELEASE-561 URL: http://jira.codehaus.org/browse/MRELEASE-561 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Environment: WinXP, maven 2.2.1, Java 5 Reporter: Lucien Weller Attachments: branch-auto-version.patch, reproduce.tgz When I try to run the following command I get an AssertionError because the root projekt is added twice into map: mvn release:branch -DdryRun=true -DbranchName=re3.07.05 -DautoVersionSubmodules=true Attached patch should fix this issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234786#action_234786 ] Bob Fields commented on MDEPLOY-48: --- Problem still exists, and the -DuniqueVersion=false workaround sortof works, however if you are pointing to an existing pom file for the initial deploy, and then point to the same pom file for the -sources deploy, the -sources.jar archive is deployed, however it gives an error when trying to deploy the pom file again (correctly): [INFO] Error installing artifact's metadata: Error while deploying metadata: Failed to transfer file: http://xxx.pom. Returncode is: 400. Workaround is to specify the -DGAV individually, instead of the pom. I know there's a way to tell it not to generate a pom. Is there a way to tell it not to deploy the pom (since it already exists), but still be able to use the GAV information contained in the pom instead of specifying all on the command line? Or better yet, add the options to specify a sources and javadoc archives at the same time as the runtime deploy. deploy:deploy-file does not support deploying sources jars too -- Key: MDEPLOY-48 URL: http://jira.codehaus.org/browse/MDEPLOY-48 Project: Maven 2.x Deploy Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Geoffrey De Smet deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell him where the sources jar is: mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234793#action_234793 ] Brett Porter commented on MDEPLOY-48: - not at present, but the issue is being left open for patching. You'll be encouraged to know that the current trunk of Maven 3 supports subsequent uploads for snapshots with classifiers that will be resolved correctly (see MNG-4452). deploy:deploy-file does not support deploying sources jars too -- Key: MDEPLOY-48 URL: http://jira.codehaus.org/browse/MDEPLOY-48 Project: Maven 2.x Deploy Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Geoffrey De Smet deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell him where the sources jar is: mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2879) Thousands of [WARNING] Component returned which is not the same manager.
[ http://jira.codehaus.org/browse/MNG-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234794#action_234794 ] Brett Porter commented on MNG-2879: --- Maven 2.2.1 will be supported for some time (and for now we still support Maven 2.0.11), but there are unlikely to be new releases unless someone steps up to drive them or there are relevant patches to apply. Non-blocker fixes are unlikely to be backported. Thousands of [WARNING] Component returned which is not the same manager. Key: MNG-2879 URL: http://jira.codehaus.org/browse/MNG-2879 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.6 Reporter: Brian Fox Assignee: Jason van Zyl It happens when processing resources, mostly for war projects although I'm not 100% positive it's only wars. We see one of these warnings apparently for every file processed because sometimes there are just a few and sometimes there are 1000s correlating to the number of files in the project. So far it only happens on dual-core machines although not every time. It smells of a multithreading issue. This issue has already been fixed in PLX-287. This MNG issue is to try and get that fix into 2.0.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4804) EJB dependencies are included when using the ejb-client packaging/type
EJB dependencies are included when using the ejb-client packaging/type -- Key: MNG-4804 URL: http://jira.codehaus.org/browse/MNG-4804 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies Affects Versions: 2.2.1, 2.0.11 Reporter: Jeroen Ruijgers Attachments: maven-artifact-components.xml.patch When generating an EJB-client module and including it in your project, the EJB dependencies are included in your project. This is unnecessary behaviour, because the EJB with it's dependencies will be deployed separately and the only files needed are in de EJB-client library. These dependencies are easely excluded in the compontens.xml by setting the includesDependencies property from DefaultArtifactHandler. Patch attachted -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4785) NPE in dependency resolution code for TC plugin
[
http://jira.codehaus.org/browse/MNG-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4785.
--
Resolution: Fixed
Fix Version/s: 3.0-beta-4
Assignee: Benjamin Bentmann
Fixed in [r995457|http://svn.apache.org/viewvc?view=revisionrevision=995457].
NPE in dependency resolution code for TC plugin
---
Key: MNG-4785
URL: http://jira.codehaus.org/browse/MNG-4785
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories, Dependencies
Affects Versions: 3.0-beta-3
Environment: OS X 10.6
Reporter: Oleg Gusakov
Assignee: Benjamin Bentmann
Fix For: 3.0-beta-4
Attachments: m3tctest.tgz
Terracotta Maven plugin 1.4.0 test produces NPE in 3.0-beta-3, but works fine
in 3.0-beta-2
{code}
[ERROR] [node0]
java.lang.NullPointerException
at
org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:149)
at
org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:139)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:237)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:219)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:584)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:192)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:451)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:307)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:301)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:280)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:258)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
at
org.terracotta.maven.plugins.tc.DsoArtifactResolverImpl.resolveArtifact(DsoArtifactResolverImpl.java:145)
at
org.terracotta.maven.plugins.tc.DsoSurefireMojo.addArtifact(DsoSurefireMojo.java:775)
at
org.terracotta.maven.plugins.tc.DsoSurefireMojo.constructSurefireBooter(DsoSurefireMojo.java:548)
at
org.terracotta.maven.plugins.tc.DsoSurefireMojo$SurefireThread.runSurefire(DsoSurefireMojo.java:434)
at
org.terracotta.maven.plugins.tc.DsoSurefireMojo$SurefireThread.run(DsoSurefireMojo.java:417)
at java.lang.Thread.run(Thread.java:637)
[INFO] All nodes completed
[INFO]
[INFO] Stopping DSO Server
[INFO] [dso stop] 2010-08-30 11:10:42,625 INFO - Terracotta 3.1.0, as of
20090821-080813 (Revision 13442 by cru...@su10mo5 from 3.1)
[INFO] OK
[{code}
Test project - attached
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-596) Enhance DefaultVersionInfo getNextVersion to increment version at specified index
Enhance DefaultVersionInfo getNextVersion to increment version at specified
index
--
Key: MRELEASE-596
URL: http://jira.codehaus.org/browse/MRELEASE-596
Project: Maven 2.x Release Plugin
Issue Type: New Feature
Reporter: Prashant Bhate
Attachments: DefaultVersionInfoTest.java
Current DefaultVersionInfo always increment either annotationRevision if
available or least version from digits. say if 1.2.3 would be incremented to
1.2.4 always.
I am currently implementing fix for
http://jira.codehaus.org/browse/MVERSIONS-124 which requires NextVersion with
version incremented at specified index.
Hence it would be good to include another method shown below that will
increment annotationRevision if parameter index is -ve. Otherwise it would
roll the digit at specified index and reset rest of the digits
{code}
/**
* Increment version at specified index. While incrementing digits set
* remaining segments to zero.
*
* @param index
*If -ve increment annotationRevision else increment digits
at
*index and reset remaining to 0.
* @return new instance of version info
*/
public VersionInfo getNextVersion(int index) {
DefaultVersionInfo version = null;
if (digits != null) {
List digits = new ArrayList(this.digits);
String annotationRevision = this.annotationRevision;
if (index 0) {
if (StringUtils.isNumeric(annotationRevision)) {
annotationRevision =
incrementVersionString(annotationRevision);
}
} else if (index digits.size()) {
int next = index;
digits.set(next,
incrementVersionString((String) digits
.get(next)));
for (int i = next + 1; i digits.size(); i++) {
digits.set(i, 0);
}
}
version = new DefaultVersionInfo(digits, annotation,
annotationRevision, buildSpecifier,
annotationSeparator,
annotationRevSeparator, buildSeparator);
}
return version;
}
{code}
Request some one to validate this and schedule this for checkin if possible
Regards,
Prashant
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4637) -pl switch negates recursion into sub projects
[ http://jira.codehaus.org/browse/MNG-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234798#action_234798 ] Matthew Hughes commented on MNG-4637: - Agree with above. This is still present in Maven 3 beta3. -pl switch negates recursion into sub projects -- Key: MNG-4637 URL: http://jira.codehaus.org/browse/MNG-4637 Project: Maven 2 3 Issue Type: Bug Components: Bootstrap Build Affects Versions: 2.2.1 Reporter: Ittay Dror I have a project with several sub projects, each of which has sub projects. If I use: mvn -pl sub1 I expect sub1 to be built as well as all its sub projects and if I use -am, all their dependencies. Unfortunately, maven will build only sub1. When using just -pl, I can instead cd to sub1 and build from there, but when using -am I can't since any dependencies on projects outside of sub1 will not be found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-135) Can't use a configFile with an URL
[
http://jira.codehaus.org/browse/MCHECKSTYLE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jean-Prost closed MCHECKSTYLE-135.
Resolution: Fixed
Can't use a configFile with an URL
--
Key: MCHECKSTYLE-135
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-135
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.5
Reporter: Dominique Jean-Prost
Assignee: Olivier Lamy
Fix For: 2.6
Attachments: log.txt
If I specify a config file with an url, this file can't be downloaded anymore.
I double checked that this file is reachable by http.
After searching a bit, I guess the problem comes from
org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(String) in
the following lines :
for ( Iterator i = paths.iterator(); i.hasNext(); ) { -- paths is empty there
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4793) Unable to obtain archiver for extension 'zip'
[
http://jira.codehaus.org/browse/MNG-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234801#action_234801
]
Paul Gier commented on MNG-4793:
I tested the change locally and it fixes the problem for me, thanks!
Will this be included in 3.0-beta-4?
Unable to obtain archiver for extension 'zip'
-
Key: MNG-4793
URL: http://jira.codehaus.org/browse/MNG-4793
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0-beta-3
Environment: maven-3-beta-2, maven-3-beta-3
Reporter: Paul Gier
Attachments: build.log
There seems to be a regression in maven-3-beta-3 related to the assembly
plugin. When building a multi-module project using Maven 3-beta-3 I get the
error Unable to obtain archiver for extension 'zip'. This error does not
happen with Maven 3-beta-2.
I wasn't able to reproduce this problem with a smaller project. The source
can be checked out from the jboss repo
{code}
svn co -r 107936 http://anonsvn.jboss.org/repos/jbossas/trunk
{code}
The problem can be seen running building certain modules.
{code}
mvn clean install -pl deployment,server,osgi/zip
{code}
I will try to narrow down the problem further if I have some time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-462) Allow generating linkedResources elements in .project via eclipse:eclipse
[
http://jira.codehaus.org/browse/MECLIPSE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234805#action_234805
]
Luke Yang commented on MECLIPSE-462:
I don't understand this request. Isn't it already supported?
Allow generating linkedResources elements in .project via eclipse:eclipse
---
Key: MECLIPSE-462
URL: http://jira.codehaus.org/browse/MECLIPSE-462
Project: Maven 2.x Eclipse Plugin
Issue Type: Improvement
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.5.1
Reporter: MG
Example:
linkedResources
link
namesrc-2/name
type2/type
location${base_dir}/common/common-coreui/src/main/java/location
/link
link
namesrc-1/name
type2/type
location${base_dir}/tiger/tiger-ui/src/main/java/location
/link
/linkedResources
/projectDescription
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-462) Allow generating linkedResources elements in .project via eclipse:eclipse
[
http://jira.codehaus.org/browse/MECLIPSE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234809#action_234809
]
Marvin Froeder commented on MECLIPSE-462:
-
It may be on the lastest release, but is wasn't by the time I start watching
this feature request.
Allow generating linkedResources elements in .project via eclipse:eclipse
---
Key: MECLIPSE-462
URL: http://jira.codehaus.org/browse/MECLIPSE-462
Project: Maven 2.x Eclipse Plugin
Issue Type: Improvement
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.5.1
Reporter: MG
Example:
linkedResources
link
namesrc-2/name
type2/type
location${base_dir}/common/common-coreui/src/main/java/location
/link
link
namesrc-1/name
type2/type
location${base_dir}/tiger/tiger-ui/src/main/java/location
/link
/linkedResources
/projectDescription
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4802) Maven should by default use the environment defined proxy settings
[ http://jira.codehaus.org/browse/MNG-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234827#action_234827 ] Jason van Zyl commented on MNG-4802: @Hugo I'm glad this is so easy to do this, we eagerly await your patches :-) Maven should by default use the environment defined proxy settings -- Key: MNG-4802 URL: http://jira.codehaus.org/browse/MNG-4802 Project: Maven 2 3 Issue Type: New Feature Components: Settings Affects Versions: 2.2.1 Reporter: Hugo Palma For people that constantly change places of work it's very annoying having to edit the settings.xml files every time. It would be great if the environment proxy settings were used when no proxy settings were defined in settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGINTESTING-17) Add Property to the execution of Maven in ProjectTool
Add Property to the execution of Maven in ProjectTool
-
Key: MPLUGINTESTING-17
URL: http://jira.codehaus.org/browse/MPLUGINTESTING-17
Project: Maven 2.x Plugin Testing
Issue Type: Improvement
Components: plugin-testing-tools
Affects Versions: 1.2
Reporter: Peter Kofler
Priority: Minor
Attachments: maven-plugin-testing-tools_property_patch.txt
{{{BuildTool}}} fails during integration test prepararion when the
{{{help-mojo}}} of {{{maven-plugin-plugin} is executed. The guys from the
Eclipse Plugin found a workaround by disabling it. But so the plugin under test
can't be built from scratch any more. So they used a profile to run the
integration tests and disable {{{help-mojo}}} execution. If the {{{BuildTool}}}
would set a property, a separate profile could be used for different behaviour
during integration testing. A proper profile could then look like that
{{{
profiles
profile
idfailsafe-runnung-it/id
build
!-- skip test resources to speed up things --
testResources
testResource
directorysrc/test/resources/directory
excludes
exclude**/*/exclude
/excludes
/testResource
/testResources
pluginManagement
plugins
!-- skip test compile to speed up things --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
skiptrue/skip
/configuration
/plugin
!-- copied from maven-eclipse-plugin --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
!-- lock down to old version as newer version aborts build upon
no mojos as required during ITs, see below --
version2.4.3/version
executions
!-- disable execution, makes IT preparation using
maven-plugin-testing-tools fail (see target/test-build-logs/setup.build.log) --
execution
idhelp-mojo/id
configuration
extractors
extractor /
/extractors
/configuration
/execution
/executions
/plugin
!-- maven-plugin-testing-tools do not handle Failsafe Plugin --
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdfailsafe-maven-plugin/artifactId
version2.4.3-alpha-1/version
configuration
skipTeststrue/skipTests
/configuration
/plugin
/plugins
/pluginManagement
/build
activation
property
namemaven-plugin-testing-tools:ProjectTool:packageProjectArtifact/name
/property
/activation
/profile
/profiles
}}}
I used a working version of that in
[https://code.google.com/p/code-cop-code/wiki/MackerMavenPlugin].
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGINTESTING-17) Add Property to the execution of Maven in ProjectTool
[
http://jira.codehaus.org/browse/MPLUGINTESTING-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234835#action_234835
]
Peter Kofler commented on MPLUGINTESTING-17:
Sorry for the broken formatting. I thought I used the proper wiki markup and
could not find any Preview Buttons ;-)
Add Property to the execution of Maven in ProjectTool
-
Key: MPLUGINTESTING-17
URL: http://jira.codehaus.org/browse/MPLUGINTESTING-17
Project: Maven 2.x Plugin Testing
Issue Type: Improvement
Components: plugin-testing-tools
Affects Versions: 1.2
Reporter: Peter Kofler
Priority: Minor
Attachments: maven-plugin-testing-tools_property_patch.txt
{{{BuildTool}}} fails during integration test prepararion when the
{{{help-mojo}}} of {{{maven-plugin-plugin} is executed. The guys from the
Eclipse Plugin found a workaround by disabling it. But so the plugin under
test can't be built from scratch any more. So they used a profile to run the
integration tests and disable {{{help-mojo}}} execution. If the
{{{BuildTool}}} would set a property, a separate profile could be used for
different behaviour during integration testing. A proper profile could then
look like that
{{{
profiles
profile
idfailsafe-runnung-it/id
build
!-- skip test resources to speed up things --
testResources
testResource
directorysrc/test/resources/directory
excludes
exclude**/*/exclude
/excludes
/testResource
/testResources
pluginManagement
plugins
!-- skip test compile to speed up things --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
skiptrue/skip
/configuration
/plugin
!-- copied from maven-eclipse-plugin --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
!-- lock down to old version as newer version aborts build
upon no mojos as required during ITs, see below --
version2.4.3/version
executions
!-- disable execution, makes IT preparation using
maven-plugin-testing-tools fail (see target/test-build-logs/setup.build.log)
--
execution
idhelp-mojo/id
configuration
extractors
extractor /
/extractors
/configuration
/execution
/executions
/plugin
!-- maven-plugin-testing-tools do not handle Failsafe Plugin --
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdfailsafe-maven-plugin/artifactId
version2.4.3-alpha-1/version
configuration
skipTeststrue/skipTests
/configuration
/plugin
/plugins
/pluginManagement
/build
activation
property
namemaven-plugin-testing-tools:ProjectTool:packageProjectArtifact/name
/property
/activation
/profile
/profiles
}}}
I used a working version of that in
[https://code.google.com/p/code-cop-code/wiki/MackerMavenPlugin].
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4687) Maven should not warn about incorrect parent path when no relativePath is specified
[
http://jira.codehaus.org/browse/MNG-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234838#action_234838
]
Stan Devitt commented on MNG-4687:
--
Current design of 3.0 betas assumes the pom of the directory above is a parent.
Good design separates the role of parent and aggregation and it makes sense
for the aggregator to be in the directory above, and for the parent to be a
stable configuration that come from the repository.
It would be very nice for this to be sorted out before the release of Maven 3.0.
Maven should not warn about incorrect parent path when no relativePath is
specified
---
Key: MNG-4687
URL: http://jira.codehaus.org/browse/MNG-4687
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Affects Versions: 3.0-beta-1
Reporter: Paul Gier
Priority: Minor
Attachments: MNG-relativePath.zip
If a module pom uses a parent other than the one in the parent directory,
maven logs a warning. In some cases it is necessary that a module pom has an
external parent pom, and there is no way to refer to this external pom in the
relativePath. If nothing is specified in the relativePath, Maven should not
log the warning.
{noformat}
[WARNING] 'parent.relativePath' of POM
org.maven.test:relative-path-parent:0.0.1-SNAPSHOT
(/home/pgier/projects/MNG-relativePath/module-1/pom.xml) points at
org.maven.test:relative-path-test instead of org.apache.maven:maven-parent,
please verify your project structure @
{noformat}
The attached zip reproduces the warning.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-406) Upgrade httpclient
Upgrade httpclient
--
Key: DOXIA-406
URL: http://jira.codehaus.org/browse/DOXIA-406
Project: Maven Doxia
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.3
Reporter: Robert Scholte
Attachments: upgrade-httpclient.patch
The doxia core still uses commons-httpclient-3.x, although the [HttpComponents
site|http://hc.apache.org/index.html] tells the following:
{quote}
HttpClient is a HTTP/1.1 compliant HTTP agent implementation based on HttpCore.
It also provides reusable components for client-side authentication, HTTP state
management, and HTTP connection management. HttpComponents Client is a
successor of and replacement for Commons HttpClient 3.x. Users of Commons
HttpClient are strongly encouraged to upgrade.
{quote}
With this patch DOXIA-394 might be fixed as well, or at least a step closer.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCOMPILER-130) compilerArgument option doesn't work with maxerrs option, compilerArguments does
[ http://jira.codehaus.org/browse/MCOMPILER-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Hedman updated MCOMPILER-130: - Attachment: patch_MCOMPILER-130.txt A patch that informs the user if there is a white-space within the compilerArgument and a explanation in the FAQ segment of site. Added a parameter to turn the warning off. The faq text may need checking. compilerArgument option doesn't work with maxerrs option, compilerArguments does Key: MCOMPILER-130 URL: http://jira.codehaus.org/browse/MCOMPILER-130 Project: Maven 2.x Compiler Plugin Issue Type: Bug Environment: Mac OS X Reporter: Mike Dikan Attachments: patch_MCOMPILER-130.txt I looked into using this configuration for maven: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration compilerArgument-Xmaxerrs 1000/compilerArgument /configuration /plugin But no dice: Failure executing javac, but could not parse the error: javac: invalid flag: -Xmaxerrs 1000 Usage: javac options source files use -help for a list of possible options On the command line using javac, the maxerrs flag works as expected, and using the compilerArguments Map option works: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration forktrue/fork compilerArguments Xmaxerrs10/Xmaxerrs /compilerArguments /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-501) Define a method of using moduleSet/binaries from a child project to gain access to all modules in reactor
Define a method of using moduleSet/binaries from a child project to gain access to all modules in reactor - Key: MASSEMBLY-501 URL: http://jira.codehaus.org/browse/MASSEMBLY-501 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Affects Versions: 2.2-beta-5 Reporter: John Casey Providing access to all modules in a reactor to a child project assembly will make moduleSet/binaries a viable option, since it allows the child project to run after all other projects. This will give it access to the binaries produced by sibling projects. Still need to work out whether there's a way to easily ensure it gets sorted down to the bottom...though I don't suppose that's necessarily required, as long as the modules it does depend on (through includes/excludes) are available by the time it builds. Project dependencies could always handle this, while the moduleSet usage would still open up avenues that dependencySets do not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-501) Define a method of using moduleSet/binaries from a child project to gain access to all modules in reactor
[ http://jira.codehaus.org/browse/MASSEMBLY-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-501: - Fix Version/s: 2.2-beta-6 Define a method of using moduleSet/binaries from a child project to gain access to all modules in reactor - Key: MASSEMBLY-501 URL: http://jira.codehaus.org/browse/MASSEMBLY-501 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Affects Versions: 2.2-beta-5 Reporter: John Casey Assignee: John Casey Fix For: 2.2-beta-6 Providing access to all modules in a reactor to a child project assembly will make moduleSet/binaries a viable option, since it allows the child project to run after all other projects. This will give it access to the binaries produced by sibling projects. Still need to work out whether there's a way to easily ensure it gets sorted down to the bottom...though I don't suppose that's necessarily required, as long as the modules it does depend on (through includes/excludes) are available by the time it builds. Project dependencies could always handle this, while the moduleSet usage would still open up avenues that dependencySets do not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4592) Snapshot artifacts that could not be downloaded due to communication problems are blacklisted for a day by default.
[ http://jira.codehaus.org/browse/MNG-4592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4592. -- Resolution: Fixed Fix Version/s: 3.0-beta-4 Assignee: Benjamin Bentmann Fixed in [r995606|http://svn.apache.org/viewvc?view=revisionrevision=995606]. As suggested, only the not-found case is cached, other transfer errors aren't and will have resolution be retried during the next build. Snapshot artifacts that could not be downloaded due to communication problems are blacklisted for a day by default. - Key: MNG-4592 URL: http://jira.codehaus.org/browse/MNG-4592 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-alpha-7 Reporter: Marc Wirth Assignee: Benjamin Bentmann Fix For: 3.0-beta-4 If an artifact could not be downloaded because of communication problems with the server Maven should not use the update check intervall before rechecking. The fix for http://jira.codehaus.org/browse/MNG-3421 introduced a behaviour that has cost us some time to find a solution. We're facing network problems with one of our nexus servers and this results by default in a 24 hour blacklisting of that artifact. For a continuous integration scenario this is rather painful (build stays red for a whole day) and using a different policy increases the network overhead because then all snapshots are checked. For now we have a very ugly workaround that simply deletes all *.lastUpdated files from the local repository. A better solution from our point of view would be to only write the lastUpdated file if the resource really doesn't exist (DefaultWagonManager#getRemoteFile() threw ResourceDoesNotExistException?), but not if the wagon reported a communication problem (TransferFailedException?). That way the solution to MNG-3421 should still be valid, but without blocking CI in our case. It would also be rather helpful if the real cause for such delayed lookups would be reported by default (Failure to resolve ... was cached in the local repository. Resolution will not be reattempted until ...). In our case we only had the standard error message in the log that the artifact could not be resolved from any repository and it took us a while to figure out that this was really because of the lastUpdated-check. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2803) org/slf4j/slf4j-android directory has wrong permissions
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MAVENUPLOAD-2803. - Resolution: Fixed Assignee: Brett Porter fixed the permissions org/slf4j/slf4j-android directory has wrong permissions Key: MAVENUPLOAD-2803 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2803 Project: Maven Upload Requests Issue Type: Wish Reporter: Ceki Gulcu Assignee: Brett Porter Due to a file permission issue the org/sfl4j/slf4j-android folder was not properly synchronized in the maven central repo. The problem was solved on our end. However, http://repo1.maven.org/maven2/org/slf4j/slf4j-android/ still returns 403 forbidden. Could you either remove the corresponding directory or set its permissions so that it is readable, with the latter option being preferable? Many thanks in advance, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4805) Update default plugin versions in super POM
Update default plugin versions in super POM --- Key: MNG-4805 URL: http://jira.codehaus.org/browse/MNG-4805 Project: Maven 2 3 Issue Type: Task Components: Plugins and Lifecycle Affects Versions: 3.0-beta-3 Reporter: Benjamin Bentmann Priority: Trivial Some of the common plugins have had new releases with bugfixes, in particular regarding parallel build support, we should pick those as defaults. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-134) add support for jdk 6 javac -processorpath parameter
add support for jdk 6 javac -processorpath parameter
Key: MCOMPILER-134
URL: http://jira.codehaus.org/browse/MCOMPILER-134
Project: Maven 2.x Compiler Plugin
Issue Type: New Feature
Affects Versions: 2.3.2
Reporter: Jürgen
Priority: Minor
Attachments: maven-compiler-plugin-2.3.3-SNAPSHOT.jar,
ProcCompilerMojo.java
add support for annotation processing javac option -processorpath
cf.
http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html#processing
while not supported, annotation processor classes have to be supplied via
compile classpath.
annotation processor dependencies (e.g. database, xml processing, ...) might
not be wanted as project dependencies or event be in conflict with them.
as a workaround I have attached new ProcCompilerMojo, where I tried to
implement processorpath support
1) via a new configuration option: dependency resolution is done with bits of
code I copied from other maven classes like ProjectBuilder, ...
{code}
configuration
proconly/proc
processorpath
dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-jdk14/artifactId
version1.5.6/version
/dependency
dependency
groupIdcom.example/groupId
artifactIdannoproc/artifactId
version1.0.0/version
/dependency
/processorpath
/configuration
{code}
2) (unused) via plugin dependencies: I basically make use of ProcCompilerMojo
classloader urls. This variant is quite dirty. it adds unnecessary maven
plugin jars to annotation processor classpath and unnecessary annotation
processor jars to compiler-plugin classpath
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCOMPILER-134) add support for jdk 6 javac -processorpath parameter
[
http://jira.codehaus.org/browse/MCOMPILER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jürgen updated MCOMPILER-134:
-
Attachment: maven-compiler-plugin-2.3.3-SNAPSHOT.jar
first upload might have been corrupted ?
add support for jdk 6 javac -processorpath parameter
Key: MCOMPILER-134
URL: http://jira.codehaus.org/browse/MCOMPILER-134
Project: Maven 2.x Compiler Plugin
Issue Type: New Feature
Affects Versions: 2.3.2
Reporter: Jürgen
Priority: Minor
Attachments: maven-compiler-plugin-2.3.3-SNAPSHOT.jar,
maven-compiler-plugin-2.3.3-SNAPSHOT.jar, ProcCompilerMojo.java
add support for annotation processing javac option -processorpath
cf.
http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html#processing
while not supported, annotation processor classes have to be supplied via
compile classpath.
annotation processor dependencies (e.g. database, xml processing, ...) might
not be wanted as project dependencies or event be in conflict with them.
as a workaround I have attached new ProcCompilerMojo, where I tried to
implement processorpath support
1) via a new configuration option: dependency resolution is done with bits of
code I copied from other maven classes like ProjectBuilder, ...
{code}
configuration
proconly/proc
processorpath
dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-jdk14/artifactId
version1.5.6/version
/dependency
dependency
groupIdcom.example/groupId
artifactIdannoproc/artifactId
version1.0.0/version
/dependency
/processorpath
/configuration
{code}
2) (unused) via plugin dependencies: I basically make use of ProcCompilerMojo
classloader urls. This variant is quite dirty. it adds unnecessary maven
plugin jars to annotation processor classpath and unnecessary annotation
processor jars to compiler-plugin classpath
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2803) org/slf4j/slf4j-android directory has wrong permissions
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234855#action_234855 ] Ceki Gulcu commented on MAVENUPLOAD-2803: - Thank you. org/slf4j/slf4j-android directory has wrong permissions Key: MAVENUPLOAD-2803 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2803 Project: Maven Upload Requests Issue Type: Wish Reporter: Ceki Gulcu Assignee: Brett Porter Due to a file permission issue the org/sfl4j/slf4j-android folder was not properly synchronized in the maven central repo. The problem was solved on our end. However, http://repo1.maven.org/maven2/org/slf4j/slf4j-android/ still returns 403 forbidden. Could you either remove the corresponding directory or set its permissions so that it is readable, with the latter option being preferable? Many thanks in advance, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
