[jira] Commented: (MNG-2966) Use optional transitive dependencies versions as dependencyManagement does
[
http://jira.codehaus.org/browse/MNG-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215621#action_215621
]
Mike Youngstrom commented on MNG-2966:
--
I've done some additional thinking and put together a POC patch.
In my poc patch:
* I've added a step in the model build after the DependencyManagement import
process.
* I build an effective model for each of the concrete dependencies of the root
model.
* Any of these optional DependencieManagements I add to the root model I set
optional=true to differentiate this DependencyManagement Dependency from
traditional DependencyManagement Dependencies.
I believe this approach has the following benefits:
* Allows any dependencies in the root model without versions to be resolved
along with the other DependencyManagement resolution.
* Since "optional" in a dependencyManagement dependency previously was ignored
this marker can now be used to identify which DependencyManagement dependencies
came from DependencyManagement and which came from optional transitive
dependencies.
* Since these optional DependencyManagements are added after other
DependencyManagements this should maintain 100% backwards compatibility.
The only concern I have about this approach is the polluting of the
DependencyManagement of an effective pom that is going on. So viewing an
effective pom could have a significantly larger number of dependencies in the
DependencyManagement section. Though that can be good too so the developer can
know what optional dependencies are available to them.
In my prototype I only go one level of dependencies deep. To match transitive
dependency semantics I should probably recurse through all transitive levels
maintaining the same dependency version semantics of transitive dependencies.
Any thoughts about this approach? I should have a patch ready to post for
review soon.
Mike
> Use optional transitive dependencies versions as dependencyManagement does
> --
>
> Key: MNG-2966
> URL: http://jira.codehaus.org/browse/MNG-2966
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 2.0.6
>Reporter: Daniel Beland
> Fix For: 3.x (to be reviewed)
>
>
> I would like to be able to add an includes statement on a dependency to get
> its optional dependency(ies).
> ie:
>
> hibernate
> hibernate
> 3.2.1.ga
>
>
> jgroups
> jgroups-all
> runtime
> false
>
>
>
> For example, I use hibernate 3.2.1.ga, it has an optional dependency on
> jgroups-all-2.2.8.
> I would like to be able to add an inclusion statement on the hibernate lib to
> tell that I want to include jgroups as well.
> The main reason for this is that I want the same version as specified in the
> hibernate pom.
> This way, upgrading hibernate would also upgrade my version of jgroups at the
> same time.
> Obviously, we need to be able to define a scope and optional attribute as
> well (not inherited)
> Or maybe we could set the dependency explicitly in the pom without specifying
> the version and have maven resolve the version from the nearest source (as it
> does normally) automatically or we specify where to resolve it.
> ie something like:
>
> jgroups
> jgroups-all
>automatically or we need to tell maven where to find it -->
>
> hibernate
> hibernate
>
> ${hibernate.version}
>
> runtime
> false
>
--
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: (SCM-526) scm:checkout and scm:export ignores excludes and includes configuration
[ http://jira.codehaus.org/browse/SCM-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SCM-526. Resolution: Fixed Fixed in - [r928126|http://svn.apache.org/viewvc?view=revision&revision=928126] - [r928132|http://svn.apache.org/viewvc?view=revision&revision=928132] > scm:checkout and scm:export ignores excludes and includes configuration > > > Key: SCM-526 > URL: http://jira.codehaus.org/browse/SCM-526 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.4 > > > we can honor this documented configuration at post checkout/export actions. > This is very good improvement for the usecase where scm plugin > checkout/export are used intensively to move files to maven structure -- 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-2116) Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data.
[ http://jira.codehaus.org/browse/MNG-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215591#action_215591 ] Paul Benedict commented on MNG-2116: Is it possible to introduce a new POM element or attribute that identifies the POM as a generated stub? If people know it, they can do something about it -- like replace it. > Add strict mode, to avoid any stubbing, dummying, etc. activities to account > for missing data. > -- > > Key: MNG-2116 > URL: http://jira.codehaus.org/browse/MNG-2116 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: General >Affects Versions: 2.0.2 >Reporter: John Casey >Priority: Minor > Fix For: 3.0-alpha-8 > > > Currently, Maven will create a stub POM when it cannot find one on the remote > repository. However, there are cases where we need to have the ability to > verify that all the components of an application or some other type of build > are present. Therefore, we need a strict mode for Maven, which will suppress > any stubbing activities like this. -- 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: (MANTTASKS-181) update tasks code to use Java 5
[ http://jira.codehaus.org/browse/MANTTASKS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MANTTASKS-181. --- Resolution: Fixed Fix Version/s: 2.1.1 Assignee: Herve Boutemy done in [r928113|http://svn.apache.org/viewvc?view=revision&revision=928113] > update tasks code to use Java 5 > --- > > Key: MANTTASKS-181 > URL: http://jira.codehaus.org/browse/MANTTASKS-181 > Project: Maven 2.x Ant Tasks > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.1.1 > > > since the Maven core version used already needs Java 5... -- 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: (MAVENUPLOAD-2760) I am DynamicJasper's project leader, please upload.
I am DynamicJasper's project leader, please upload. --- Key: MAVENUPLOAD-2760 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2760 Project: Maven Upload Requests Issue Type: Task Reporter: Juan Manuel Alvarez I am DynamicJasper's project leader, please upload. DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it helps developers to save time when designing simple/medium complexity reports generating the layout of the report elements automatically. It creates reports dynamically, defining at runtime the columns, column width (auto width), groups, variables, fonts, charts, crosstabs, sub reports (that can also be dynamic), page size and everything else that you can define at design 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] Created: (MANTTASKS-181) update tasks code to use Java 5
update tasks code to use Java 5 --- Key: MANTTASKS-181 URL: http://jira.codehaus.org/browse/MANTTASKS-181 Project: Maven 2.x Ant Tasks Issue Type: Improvement Affects Versions: 2.1.0 Reporter: Herve Boutemy since the Maven core version used already needs Java 5... -- 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: (MANTTASKS-172) extend scope of 'result' variable in org.apache.maven.artifact.ant.DependenciesTask.doExecute()
[
http://jira.codehaus.org/browse/MANTTASKS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MANTTASKS-172.
---
Resolution: Fixed
Fix Version/s: 2.1.1
Assignee: Herve Boutemy
done in [r928095|http://svn.apache.org/viewvc?view=revision&revision=928095]
I didn't add a class attribute but created {{protected ArtifactResolutionResult
doExecuteResolution()}} method to override when you need it
> extend scope of 'result' variable in
> org.apache.maven.artifact.ant.DependenciesTask.doExecute()
>
>
> Key: MANTTASKS-172
> URL: http://jira.codehaus.org/browse/MANTTASKS-172
> Project: Maven 2.x Ant Tasks
> Issue Type: Wish
> Components: dependencies task
>Reporter: diego tognola
>Assignee: Herve Boutemy
>Priority: Trivial
> Fix For: 2.1.1
>
>
> Change the variable 'result' defined locally in the doExecute() method of
> org.apache.maven.artifact.ant.DependenciesTask to be a class member, instead.
> It should be accessible to subclasses (directly or via a getter method).
> This will allow the creation of customized ant tasks extending
> DependenciesTask which can use 'results' for post-processing.
--
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: (MANTTASKS-172) extend scope of 'result' variable in org.apache.maven.artifact.ant.DependenciesTask.doExecute()
[ http://jira.codehaus.org/browse/MANTTASKS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-172: Component/s: dependencies task > extend scope of 'result' variable in > org.apache.maven.artifact.ant.DependenciesTask.doExecute() > > > Key: MANTTASKS-172 > URL: http://jira.codehaus.org/browse/MANTTASKS-172 > Project: Maven 2.x Ant Tasks > Issue Type: Wish > Components: dependencies task >Reporter: diego tognola >Priority: Trivial > > Change the variable 'result' defined locally in the doExecute() method of > org.apache.maven.artifact.ant.DependenciesTask to be a class member, instead. > It should be accessible to subclasses (directly or via a getter method). > This will allow the creation of customized ant tasks extending > DependenciesTask which can use 'results' for post-processing. -- 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: (MNG-2933) Declaring the same resource dir in pom and overwriting it in a profile
[
http://jira.codehaus.org/browse/MNG-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-2933:
---
Fix Version/s: (was: 3.0-alpha-8)
3.x (to be reviewed)
Solving this properly requires an id field for the {{}} element to be
able to tell merging and additive effects apart.
> Declaring the same resource dir in pom and overwriting it in a profile
> --
>
> Key: MNG-2933
> URL: http://jira.codehaus.org/browse/MNG-2933
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.6
>Reporter: Dirk Olmes
>Priority: Minor
> Fix For: 3.x (to be reviewed)
>
>
> I have a pom that declares a resource dir in the main section of the pom and
> a profile which re-declares the same resource dir in a profile, this time
> with excludes.
> Example:
>
>
>
>
> src/main/resources
>
>
>
>
>
>
>
>
>
> src/main/resources
>
>
>
>
>
>
> Running mvn -X with the profile activated shows that the same resource dir is
> added twice to the runtime model.
> I would have expected the profile to "overwrite" the resource directory as
> this is the behaviour for re-declaring dependencies in a profile over
> dependencies in the main section.
--
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: (MANTTASKS-179) Variables nested in pom.xml are not being resolved
[
http://jira.codehaus.org/browse/MANTTASKS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215570#action_215570
]
Herve Boutemy commented on MANTTASKS-179:
-
ok, bug reproduced in
[r928083|http://svn.apache.org/viewvc?view=revision&revision=928083]
> Variables nested in pom.xml are not being resolved
> --
>
> Key: MANTTASKS-179
> URL: http://jira.codehaus.org/browse/MANTTASKS-179
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: pom task
>Affects Versions: 2.1.0
>Reporter: Joe Stano
>
> My build project parses a project's pom.xml to expose the data to various ant
> tasks. After parsing the pom.xml, the ant tasks use the normal variable
> syntax such as ${project.build.directory} to dig into the pom's contents.
> The value of this specific element in my project is "${basedir}/target". In
> 2.0.10, the resulting value of this lookup will be fully resolved to the
> project's directory. With 2.1.0, the value resolves to the literal
> "${basedir}/target" and the build fails.
> 2.1.0 failure with a ${project.build.directory} value of "${basedir}\target":
> java.io.FileNotFoundException:
> c:\Projects\ProjectName\${basedir}\target\version.jsp (The system cannot find
> the path specified)
--
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-2443) Don't download pom if artifact is already in the local repository
[ http://jira.codehaus.org/browse/MNG-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-2443. -- Resolution: Duplicate Fix Version/s: (was: 3.0-alpha-8) Assignee: Benjamin Bentmann (was: Jason van Zyl) > Don't download pom if artifact is already in the local repository > - > > Key: MNG-2443 > URL: http://jira.codehaus.org/browse/MNG-2443 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Carsten Ziegeler >Assignee: Benjamin Bentmann > > There are many projects out there just providing their artifact without a pom > (whether this is good or not is a different question). Now in this case m2 > always tries to download a pom for those artifacts, even if the artifact > itself is already in the local repository. And if you have several of those > artifacts combined with more than one repository configured, then there are a > lot of unnecessary download attempts. > I think this falls into the same category as changing a pom in the repository > (which should be forbidden) - so if for the first time the artifact is > downloaded no pom available, then there will never be a pom for this specific > artifact. -- 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-2194) no downloading attempts of non-existing artifact
[ http://jira.codehaus.org/browse/MNG-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-2194. -- Resolution: Duplicate Fix Version/s: (was: 3.0-alpha-8) Assignee: Benjamin Bentmann > no downloading attempts of non-existing artifact > > > Key: MNG-2194 > URL: http://jira.codehaus.org/browse/MNG-2194 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.2 > Environment: not dependent on environment >Reporter: John Franey >Assignee: Benjamin Bentmann >Priority: Minor > > I'm converting a project to maven 2. Some dependencies do not exist in > ibiblio, so I've 'installed' these into my local repository. > I'm unhappy because every time I perform a run, there is a significant > delay (sometimes) when maven tries to download these non-existent > artifacts. I get these messages: > Downloading: http://repo1.maven.org/maven2/.../...pom > How can I prevent maven's attempt to download these non-existent > artifacts? I'm most interested in eliminating the delay. > I know I can run with the 'offline' option. This is OK as long as I'm > sure all existing artifacts that are already downloaded into my cache. > So I can do this until I build on a system with no local cache of add a > new dependency to my projects, at which time the delay is experienced > due to these non-existent artifacts. -- 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-3349) reactor build order doesn't consider plugins modules in build order
[ http://jira.codehaus.org/browse/MNG-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-3349. -- Resolution: Duplicate Fix Version/s: (was: 3.0-alpha-8) Assignee: Benjamin Bentmann > reactor build order doesn't consider plugins modules in build order > --- > > Key: MNG-3349 > URL: http://jira.codehaus.org/browse/MNG-3349 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.8 >Reporter: nicolas de loof >Assignee: Benjamin Bentmann >Priority: Minor > > When a project has maven plugins as modules, and some modules use the plugin, > the reactor SHOULD build the plugins before the modules that use it. > A workaround is to declare plugins modules FIRST in parent POM -- 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-2285) local repository path cannot have special characters
[
http://jira.codehaus.org/browse/MNG-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-2285.
--
Resolution: Fixed
Fix Version/s: (was: 3.0-alpha-8)
3.0-alpha-3
Assignee: Benjamin Bentmann
This is a side effect of MNG-3607. Class loaders fail to load stuff from broken
URLs like {{file:/C:/Documents and
Settings/#rvarana/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.3/maven-clean-plugin-2.3.jar}}.
So while the artifacts themselves end up in the proper location, Maven isn't
able to read any classes/resources from them.
> local repository path cannot have special characters
>
>
> Key: MNG-2285
> URL: http://jira.codehaus.org/browse/MNG-2285
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.2
> Environment: Windows XP
>Reporter: Ravi Varanasi
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 3.0-alpha-3
>
> Attachments: settings.xml
>
>
> When there are special characters in the path and running
> the command *mvn clean*.causes the exception
> ---
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginM
> anager.java:295)
> at
> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(De
> faultPluginManager.java:200)
> at
> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlug
> inManager.java:165)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Defa
> ultLifecycleExecutor.java:1218)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor
> (DefaultLifecycleExecutor.java:1430)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListBy
> AggregationNeeds(DefaultLifecycleExecutor.java:378)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:134)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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)
> ---
> Attached is the settiings.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] Closed: (MNG-2345) mvn -fn install fails when a module could not be found
[ http://jira.codehaus.org/browse/MNG-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-2345. -- Resolution: Won't Fix Fix Version/s: (was: 3.0-alpha-8) Assignee: Benjamin Bentmann The reactor failure modes apply to the actual build process, not to the fundamental metadata describing the participating projects. I don't see a good reason to not fail if not even the POMs can be properly read. > mvn -fn install fails when a module could not be found > -- > > Key: MNG-2345 > URL: http://jira.codehaus.org/browse/MNG-2345 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Command Line, Reactor and workspace >Reporter: Lars Rosenberg >Assignee: Benjamin Bentmann >Priority: Minor > > mvn -fn install fails when you have a mother project which reference a module > in its modules section and the corresponding directory does not contain a > pom.xml. This should not happen when you have the fail never option turned on. > G:\si\serviceinfrastructure>mvn clean install | tee build.txt > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: unknown > Reason: Could not find the model file > 'G:\si\serviceinfrastructure\si-adapter-co > mmon\pom.xml'. > [INFO] > > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Could not find the model > file > 'G:\si\serviceinfrastructure\si-adapter-common\pom.xml'. > at > org.apache.maven.DefaultMaven.getProjects(Lorg/apache/maven/execution > /MavenExecutionRequest;Lorg/apache/maven/profiles/ProfileManager;)Ljava/util/Lis > t;(DefaultMaven.java:365) > at > org.apache.maven.DefaultMaven.doExecute(Lorg/apache/maven/execution/M > avenExecutionRequest;Lorg/apache/maven/monitor/event/EventDispatcher;)Lorg/apach > e/maven/execution/ReactorManager;(DefaultMaven.java:278) > at > org.apache.maven.DefaultMaven.execute(Lorg/apache/maven/execution/Mav > enExecutionRequest;)V(DefaultMaven.java:115) > at > org.apache.maven.cli.MavenCli.main([Ljava/lang/String;Lorg/codehaus/c > lassworlds/ClassWorld;)I(MavenCli.java:256) > at > jrockit.reflect.NativeMethodInvoker.invoke0(Ljava/lang/Object;ILjava/ > lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source) > at > jrockit.reflect.NativeMethodInvoker.invoke(Ljava/lang/Object;[Ljava/l > ang/Object;)Ljava/lang/Object;(Unknown Source) > at > java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object; > I)Ljava/lang/Object;(Unknown Source) > at > org.codehaus.classworlds.Launcher.launchEnhanced([Ljava/lang/String;) > V(Launcher.java:315) > at > org.codehaus.classworlds.Launcher.launch([Ljava/lang/String;)V(Launch > er.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode([Ljava/lang/String > ;)I(Launcher.java:430) > at > org.codehaus.classworlds.Launcher.main([Ljava/lang/String;)V(Launcher > .java:375) > Caused by: org.apache.maven.project.ProjectBuildingException: Could not find > the > model file 'G:\si\serviceinfrastructure\si-adapter-common\pom.xml'. > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Ljava/l > ang/String;Ljava/io/File;Z)Lorg/apache/maven/model/Model;(DefaultMavenProjectBui > lder.java:1274) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi > leInternal(Ljava/io/File;Lorg/apache/maven/artifact/repository/ArtifactRepositor > y;Lorg/apache/maven/profiles/ProfileManager;Z)Lorg/apache/maven/project/MavenPro > ject;(DefaultMavenProjectBuilder.java:414) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(Ljava/io/Fi > le;Lorg/apache/maven/artifact/repository/ArtifactRepository;Lorg/apache/maven/pr > ofiles/ProfileManager;)Lorg/apache/maven/project/MavenProject;(DefaultMavenProje > ctBuilder.java:192) > at > org.apache.maven.DefaultMaven.getProject(Ljava/io/File;Lorg/apache/ma > ven/artifact/repository/ArtifactRepository;Lorg/apache/maven/settings/Settings;L > org/apache/maven/profiles/ProfileManager;)Lorg/apache/maven/project/MavenProject > ;(DefaultMaven.java:515) > at > org.apache.maven.DefaultMaven.collectProjects(Ljava/util/List;Lorg/ap > ache/maven/artifact/repository/ArtifactRepository;ZLorg/apache/maven/settings/Se > ttings;Lorg/apache/maven/profiles/ProfileManager;Z)Ljava/util/List;(DefaultMaven > .java:447) > at > org.apache.maven.DefaultMaven.collectProjects(Ljava/util/List;Lorg/ap > ache/mave
[jira] Closed: (MNG-2222) dependency to dependency without source code fails
[ http://jira.codehaus.org/browse/MNG-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-. -- Resolution: Fixed Assignee: Benjamin Bentmann Fixed in [r928058|http://svn.apache.org/viewvc?view=revision&revision=928058]. > dependency to dependency without source code fails > -- > > Key: MNG- > URL: http://jira.codehaus.org/browse/MNG- > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Linux apple 2.6.12-1.1381_FC3smp #1 SMP Fri Oct 21 > 04:03:26 EDT 2005 i686 i686 i386 GNU/Linux > java version "1.5.0_06" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) > Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) >Reporter: Michael Mosmann >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-8 > > > - project1 > - project2 (dep project1) > - project3 (dep project2) > - parent pom (module project1,project2,project3) > mvn compile > build project1 > build project2 > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > build project3 > [INFO] Failed to resolve artifact. > in project2 no target created > --- > Workaround > put Noop.java into source so it will build some sources -- 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-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
[ http://jira.codehaus.org/browse/MDEPLOY-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21#action_21 ] Dan Tran commented on MDEPLOY-120: -- the below link my be helpful http://old.nabble.com/deploy-large-file-to-nexus-requires-huge-memory-td27645198.html > Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 > Enterprise > > > Key: MDEPLOY-120 > URL: http://jira.codehaus.org/browse/MDEPLOY-120 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.5 > Environment: Nexus Server: > Nexus 1.5.0 OSS running on Linux 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 > 17:17:21 EST 2007 i686 i686 i386 GNU/Linux > Maven client OS: > Windows Server 2003 Enterprise with all security updates applied > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) > Output from mvn -v: > Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) > Java version: 1.6.0_14 > Java home: D:\jdk1.6.0_14\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" >Reporter: Keith Wedinger >Priority: Blocker > Attachments: mavenuploadfiles.zip > > > Attached to this issue are the files I am using to deploy a large file to my > Nexus repository. The file being deployed is an EXE file whose size is > 22,413,688 bytes. During deployment, the upload times out after several > minutes with the stack trace below which I captured by running mvn with the > -X argument. Deploying smaller files does appear to work but I have not done > enough testing to determine the threshold when deployment fails. There is no > proxy between the client OS and the Nexus server. The steps to reproduce > this on my system are below. > 1. Download and unzip mavenuploadfiles.zip onto a Windows Server 2003 > Enterprise system. > 2. Run mavenupload.cmd to get the syntax for this command script. The > syntax message is self-explanatory. > The ZIP file also contains my copy of settings.xml, the Maven settings file I > am using. > If you believe this is a Nexus 1.5.0 issue, please let me know and I will > open the appropriate bug for Nexus OSS 1.5.0. > STACK TRACE BEGIN: > -- > Error writing to server > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error transferring file > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > 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:592) > 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 deploying > artifact: Error transferring file > at > org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240) > 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.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Error transferring fi
[jira] Created: (MAVENUPLOAD-2759) Maven Upload Requests - j2j-0.1.13.jar
Maven Upload Requests - j2j-0.1.13.jar -- Key: MAVENUPLOAD-2759 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2759 Project: Maven Upload Requests Issue Type: Wish Reporter: David Wellman http://sourceforge.net/projects/json2java/files/j2j-bundle.jar/download http://sourceforge.net/projects/json2java/about.txt http://sourceforge.net/projects/json2java I'm a developer with json2json, please upload! -- 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-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
[ http://jira.codehaus.org/browse/MDEPLOY-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215551#action_215551 ] Dan Tran commented on MDEPLOY-120: -- btw, I am able to deploy 800M artifact with maven 2.2.1 to nexus 5.0.1 professional > Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 > Enterprise > > > Key: MDEPLOY-120 > URL: http://jira.codehaus.org/browse/MDEPLOY-120 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.5 > Environment: Nexus Server: > Nexus 1.5.0 OSS running on Linux 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 > 17:17:21 EST 2007 i686 i686 i386 GNU/Linux > Maven client OS: > Windows Server 2003 Enterprise with all security updates applied > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) > Output from mvn -v: > Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) > Java version: 1.6.0_14 > Java home: D:\jdk1.6.0_14\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" >Reporter: Keith Wedinger >Priority: Blocker > Attachments: mavenuploadfiles.zip > > > Attached to this issue are the files I am using to deploy a large file to my > Nexus repository. The file being deployed is an EXE file whose size is > 22,413,688 bytes. During deployment, the upload times out after several > minutes with the stack trace below which I captured by running mvn with the > -X argument. Deploying smaller files does appear to work but I have not done > enough testing to determine the threshold when deployment fails. There is no > proxy between the client OS and the Nexus server. The steps to reproduce > this on my system are below. > 1. Download and unzip mavenuploadfiles.zip onto a Windows Server 2003 > Enterprise system. > 2. Run mavenupload.cmd to get the syntax for this command script. The > syntax message is self-explanatory. > The ZIP file also contains my copy of settings.xml, the Maven settings file I > am using. > If you believe this is a Nexus 1.5.0 issue, please let me know and I will > open the appropriate bug for Nexus OSS 1.5.0. > STACK TRACE BEGIN: > -- > Error writing to server > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error transferring file > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > 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:592) > 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 deploying > artifact: Error transferring file > at > org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240) > 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.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Error transferring file > at > org.apache.maven
[jira] Commented: (MDEPLOY-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
[ http://jira.codehaus.org/browse/MDEPLOY-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215542#action_215542 ] Keith Wedinger commented on MDEPLOY-120: I reran the Maven 2.2.0 test and let it finish. After several minutes, the deployment failed with the following stack trace: 62680/21888K 62684/21888K 62688/21888K [DEBUG] Software caused connection abort: socket write error java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon$RequestEntityImplementation.writeRequest(AbstractHttpClientWagon.java:160) at hidden.org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499) at hidden.org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114) at hidden.org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096) at hidden.org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) at hidden.org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) at hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:446) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:330) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:236) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41) 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] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Software caused connection abort: socket write error [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Software caused connection abort: socket write error at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org.apache.maven.lifecycle.DefaultLifecycleE
[jira] Commented: (MCHECKSTYLE-59) Checkstyle Report fails if propertyExpansion contains backslash characters
[
http://jira.codehaus.org/browse/MCHECKSTYLE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215539#action_215539
]
Edward Ciramella commented on MCHECKSTYLE-59:
-
Sorry Olivier -
I found my solution and figured it'd be good to post here in case someone else
searches and finds this thing.
I switched:
to
and everything is happy now.
Sorry for the noise!
> Checkstyle Report fails if propertyExpansion contains backslash characters
> --
>
> Key: MCHECKSTYLE-59
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-59
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP, JDK 1.4, Maven 2.0.4
>Reporter: Carsten Karkola
>Assignee: Dennis Lundberg
> Fix For: 2.2
>
> Attachments: MCHECKSTYLE-59-PATCH.patch, MCHECKSTYLE-59-PATCH2.patch
>
>
> The chechkstyle plugin fails on windows plattforms, if the propertyExpansion
> element contains file names like
>
> mms.suppressions.file=${basedir}/../../project/resources/checkstyle/suppressions.xml
> The backslashes in ${basedir} (like D:\foo\bar) are missing (D:foobar) and
> checkstyle fails. It seems to be an issue with StringInputStream.
> I've replaced the following old code in CheckstyleReport.java
> {code}
> if ( StringUtils.isNotEmpty( propertyExpansion ) )
> {
> p.load( new StringInputStream( propertyExpansion ) );
> }
> {code}
> with the new Code
> {code}
> if ( StringUtils.isNotEmpty( propertyExpansion ) ) {
> BufferedReader reader = new BufferedReader(new
> StringReader(propertyExpansion));
> String line = reader.readLine();
> while (line != null) {
> int delimPosition = line.indexOf('=');
> if (delimPosition > -1) {
> String name = line.substring(0, delimPosition).trim();
> delimPosition++;
> if (delimPosition < line.length()) {
> String value = line.substring(delimPosition).trim();
> if (value.length() > 0) {
> p.put(name, value);
> getLog().info("Property: " + name + " = " +
> p.getProperty(name));
> }
> }
> }
> line = reader.readLine();
> }
> reader.close();
> }
> {code}
> and it works.
> Regards, carsten
--
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: (MEV-656) Log4J 1.2.15 POM references bad javax.mail POM
Log4J 1.2.15 POM references bad javax.mail POM -- Key: MEV-656 URL: http://jira.codehaus.org/browse/MEV-656 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Pete Ford Log4J 1.2.15 has a dependency on javax.mail 1.4 but may be pointing at an old location for it; the javamail POM in my repository after download contains this: 301 Moved Permanently Moved Permanently The document has moved http://download.java.net/maven/1/javax.mail/poms/mail-1.4.pom";>here. Apache Server at maven-repository.dev.java.net Port 443 -- 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-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
[ http://jira.codehaus.org/browse/MDEPLOY-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215532#action_215532 ] Benjamin Bentmann commented on MDEPLOY-120: --- bq. it appears that Maven 2.2.0 is trying to upload data beyond the end of the file. When authentication is involved, the data is effectively sent twice, first without and second with credentials. This makes the progress meter show upload of twice the file size. > Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 > Enterprise > > > Key: MDEPLOY-120 > URL: http://jira.codehaus.org/browse/MDEPLOY-120 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.5 > Environment: Nexus Server: > Nexus 1.5.0 OSS running on Linux 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 > 17:17:21 EST 2007 i686 i686 i386 GNU/Linux > Maven client OS: > Windows Server 2003 Enterprise with all security updates applied > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) > Output from mvn -v: > Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) > Java version: 1.6.0_14 > Java home: D:\jdk1.6.0_14\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" >Reporter: Keith Wedinger >Priority: Blocker > Attachments: mavenuploadfiles.zip > > > Attached to this issue are the files I am using to deploy a large file to my > Nexus repository. The file being deployed is an EXE file whose size is > 22,413,688 bytes. During deployment, the upload times out after several > minutes with the stack trace below which I captured by running mvn with the > -X argument. Deploying smaller files does appear to work but I have not done > enough testing to determine the threshold when deployment fails. There is no > proxy between the client OS and the Nexus server. The steps to reproduce > this on my system are below. > 1. Download and unzip mavenuploadfiles.zip onto a Windows Server 2003 > Enterprise system. > 2. Run mavenupload.cmd to get the syntax for this command script. The > syntax message is self-explanatory. > The ZIP file also contains my copy of settings.xml, the Maven settings file I > am using. > If you believe this is a Nexus 1.5.0 issue, please let me know and I will > open the appropriate bug for Nexus OSS 1.5.0. > STACK TRACE BEGIN: > -- > Error writing to server > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error transferring file > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > 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:592) > 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 deploying > artifact: Error transferring file > at > org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycle
[jira] Commented: (MDEPLOY-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
[ http://jira.codehaus.org/browse/MDEPLOY-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215531#action_215531 ] Keith Wedinger commented on MDEPLOY-120: The Nexus log is not showing any errors during the failed Maven deployment. Using Maven 2.2.0 actually makes things worse. Based on the small snippet below of the debug output during the upload, it appears that Maven 2.2.0 is trying to upload data beyond the end of the file. I eventually killed the process after several minutes. 33392/21888K 33396/21888K 33400/21888K 33404/21888K 33408/21888K 33412/21888K 33416/21888K 33420/21888K 33424/21888K 33428/21888K 33432/21888K 33436/21888K 33440/21888K 33444/21888K > Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 > Enterprise > > > Key: MDEPLOY-120 > URL: http://jira.codehaus.org/browse/MDEPLOY-120 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.5 > Environment: Nexus Server: > Nexus 1.5.0 OSS running on Linux 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 > 17:17:21 EST 2007 i686 i686 i386 GNU/Linux > Maven client OS: > Windows Server 2003 Enterprise with all security updates applied > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) > Output from mvn -v: > Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) > Java version: 1.6.0_14 > Java home: D:\jdk1.6.0_14\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" >Reporter: Keith Wedinger >Priority: Blocker > Attachments: mavenuploadfiles.zip > > > Attached to this issue are the files I am using to deploy a large file to my > Nexus repository. The file being deployed is an EXE file whose size is > 22,413,688 bytes. During deployment, the upload times out after several > minutes with the stack trace below which I captured by running mvn with the > -X argument. Deploying smaller files does appear to work but I have not done > enough testing to determine the threshold when deployment fails. There is no > proxy between the client OS and the Nexus server. The steps to reproduce > this on my system are below. > 1. Download and unzip mavenuploadfiles.zip onto a Windows Server 2003 > Enterprise system. > 2. Run mavenupload.cmd to get the syntax for this command script. The > syntax message is self-explanatory. > The ZIP file also contains my copy of settings.xml, the Maven settings file I > am using. > If you believe this is a Nexus 1.5.0 issue, please let me know and I will > open the appropriate bug for Nexus OSS 1.5.0. > STACK TRACE BEGIN: > -- > Error writing to server > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error transferring file > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > 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:592) > 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 deploying > artifact: Error transferring file > at > org.apache.maven.plugin.de
[jira] Commented: (MCHECKSTYLE-59) Checkstyle Report fails if propertyExpansion contains backslash characters
[
http://jira.codehaus.org/browse/MCHECKSTYLE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215528#action_215528
]
Olivier Lamy commented on MCHECKSTYLE-59:
-
can you please open a new issue (or clone this issue) and a provide a sample
project to reproduce this issue.
Thanks
> Checkstyle Report fails if propertyExpansion contains backslash characters
> --
>
> Key: MCHECKSTYLE-59
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-59
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP, JDK 1.4, Maven 2.0.4
>Reporter: Carsten Karkola
>Assignee: Dennis Lundberg
> Fix For: 2.2
>
> Attachments: MCHECKSTYLE-59-PATCH.patch, MCHECKSTYLE-59-PATCH2.patch
>
>
> The chechkstyle plugin fails on windows plattforms, if the propertyExpansion
> element contains file names like
>
> mms.suppressions.file=${basedir}/../../project/resources/checkstyle/suppressions.xml
> The backslashes in ${basedir} (like D:\foo\bar) are missing (D:foobar) and
> checkstyle fails. It seems to be an issue with StringInputStream.
> I've replaced the following old code in CheckstyleReport.java
> {code}
> if ( StringUtils.isNotEmpty( propertyExpansion ) )
> {
> p.load( new StringInputStream( propertyExpansion ) );
> }
> {code}
> with the new Code
> {code}
> if ( StringUtils.isNotEmpty( propertyExpansion ) ) {
> BufferedReader reader = new BufferedReader(new
> StringReader(propertyExpansion));
> String line = reader.readLine();
> while (line != null) {
> int delimPosition = line.indexOf('=');
> if (delimPosition > -1) {
> String name = line.substring(0, delimPosition).trim();
> delimPosition++;
> if (delimPosition < line.length()) {
> String value = line.substring(delimPosition).trim();
> if (value.length() > 0) {
> p.put(name, value);
> getLog().info("Property: " + name + " = " +
> p.getProperty(name));
> }
> }
> }
> line = reader.readLine();
> }
> reader.close();
> }
> {code}
> and it works.
> Regards, carsten
--
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] Moved: (MANTRUN-133) maven-antrun-plugin with the ejbgen ant task
[ http://jira.codehaus.org/browse/MANTRUN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy moved MANTTASKS-180 to MANTRUN-133: - Component/s: (was: dependencies task) Affects Version/s: (was: 2.0.10) Key: MANTRUN-133 (was: MANTTASKS-180) Project: Maven 2.x Antrun Plugin (was: Maven 2.x Ant Tasks) > maven-antrun-plugin with the ejbgen ant task > - > > Key: MANTRUN-133 > URL: http://jira.codehaus.org/browse/MANTRUN-133 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug > Environment: Dev environment >Reporter: polireddy > Attachments: ejbgen-build-maven.xml, pom.xml > > > When i am calling ant build.xml from maven to run ejbgen task, getting the > following issue. > [null] Exception in thread "main" java.lang.NoClassDefFoundError: > com/sun/j > avadoc/Type > [null] at > com.bea.util.jam.provider.JamServiceFactoryImpl.createSourceB > uilder(JamServiceFactoryImpl.java:205) > [null] at > com.bea.util.jam.provider.JamServiceFactoryImpl.createBuilder > (JamServiceFactoryImpl.java:158) > [null] at > com.bea.util.jam.provider.JamServiceFactoryImpl.createClassLo > ader(JamServiceFactoryImpl.java:137) > [null] at > com.bea.util.jam.provider.JamServiceFactoryImpl.createService > (JamServiceFactoryImpl.java:78) > [null] at > com.bea.sgen.loader.JClassLoaderImpl.load(JClassLoaderImpl.ja > va:107) > [null] at com.bea.sgen.SGen.run(SGen.java:190) > [null] at com.bea.wls.ejbgen.EJBGen.main(EJBGen.java:212) > [null] at com.bea.wls.ejbgen.EJBGen.main(EJBGen.java:238) >[ejbgen] Java returned: 1 > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An Ant BuildException has occured: The following error occurred while > exe > cuting this line: > C:\apps-maven\sasejb\sasejb-ear\ejbgen-build-maven.xml:32: Java returned: 1 > If i run ant build.xml from command prompt, not getting any issue. it's > working fine. > Issue is comming if i do from Maven. > Would you please me to fix this issue. it's very urgent for me -- 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] Reopened: (MANTTASKS-162) java.lang.ClassCastException: org.codehaus.plexus.component.configurator.BasicComponentConfigurator cannot be cast to org.codehaus.plexus.component.configurator.Compon
[ http://jira.codehaus.org/browse/MANTTASKS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy reopened MANTTASKS-162: - can you attach a (non-)working example, that I can unzip and run to reproduce the problem? > java.lang.ClassCastException: > org.codehaus.plexus.component.configurator.BasicComponentConfigurator cannot > be cast to org.codehaus.plexus.component.configurator.ComponentConfigurator > -- > > Key: MANTTASKS-162 > URL: http://jira.codehaus.org/browse/MANTTASKS-162 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.10 > Environment: Windows / Maven 2.2.1 >Reporter: Vincent ASTRUC > > When we have the following declaration, a classcastexception occured > > org.apache.maven.plugins > maven-antrun-plugin > > > kodo > package > > >antfile="/build.xml"/> > > > > run > > > > > > org.apache.maven > maven-ant-tasks > 2.0.10 > > > -- 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-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
[ http://jira.codehaus.org/browse/MDEPLOY-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215523#action_215523 ] Benjamin Bentmann commented on MDEPLOY-120: --- It might be worth to try this also with Maven 2.2.0 as it uses another HTTP wagon by default that might produce different results or maybe even a more precise error message. Checking the Nexus logs for errors on the server side for such a transfer would also be helpful. > Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 > Enterprise > > > Key: MDEPLOY-120 > URL: http://jira.codehaus.org/browse/MDEPLOY-120 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.5 > Environment: Nexus Server: > Nexus 1.5.0 OSS running on Linux 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 > 17:17:21 EST 2007 i686 i686 i386 GNU/Linux > Maven client OS: > Windows Server 2003 Enterprise with all security updates applied > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) > Output from mvn -v: > Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) > Java version: 1.6.0_14 > Java home: D:\jdk1.6.0_14\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" >Reporter: Keith Wedinger >Priority: Blocker > Attachments: mavenuploadfiles.zip > > > Attached to this issue are the files I am using to deploy a large file to my > Nexus repository. The file being deployed is an EXE file whose size is > 22,413,688 bytes. During deployment, the upload times out after several > minutes with the stack trace below which I captured by running mvn with the > -X argument. Deploying smaller files does appear to work but I have not done > enough testing to determine the threshold when deployment fails. There is no > proxy between the client OS and the Nexus server. The steps to reproduce > this on my system are below. > 1. Download and unzip mavenuploadfiles.zip onto a Windows Server 2003 > Enterprise system. > 2. Run mavenupload.cmd to get the syntax for this command script. The > syntax message is self-explanatory. > The ZIP file also contains my copy of settings.xml, the Maven settings file I > am using. > If you believe this is a Nexus 1.5.0 issue, please let me know and I will > open the appropriate bug for Nexus OSS 1.5.0. > STACK TRACE BEGIN: > -- > Error writing to server > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error transferring file > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > 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:592) > 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 deploying > artifact: Error transferring file > at > org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultL
[jira] Created: (MDEPLOY-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise Key: MDEPLOY-120 URL: http://jira.codehaus.org/browse/MDEPLOY-120 Project: Maven 2.x Deploy Plugin Issue Type: Bug Components: deploy:deploy-file Affects Versions: 2.5 Environment: Nexus Server: Nexus 1.5.0 OSS running on Linux 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:17:21 EST 2007 i686 i686 i386 GNU/Linux Maven client OS: Windows Server 2003 Enterprise with all security updates applied Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) Output from mvn -v: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_14 Java home: D:\jdk1.6.0_14\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" Reporter: Keith Wedinger Priority: Blocker Attachments: mavenuploadfiles.zip Attached to this issue are the files I am using to deploy a large file to my Nexus repository. The file being deployed is an EXE file whose size is 22,413,688 bytes. During deployment, the upload times out after several minutes with the stack trace below which I captured by running mvn with the -X argument. Deploying smaller files does appear to work but I have not done enough testing to determine the threshold when deployment fails. There is no proxy between the client OS and the Nexus server. The steps to reproduce this on my system are below. 1. Download and unzip mavenuploadfiles.zip onto a Windows Server 2003 Enterprise system. 2. Run mavenupload.cmd to get the syntax for this command script. The syntax message is self-explanatory. The ZIP file also contains my copy of settings.xml, the Maven settings file I am using. If you believe this is a Nexus 1.5.0 issue, please let me know and I will open the appropriate bug for Nexus OSS 1.5.0. STACK TRACE BEGIN: -- Error writing to server [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Error transferring file at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) 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:592) 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 deploying artifact: Error transferring file at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240) 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.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Error transferring file at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:121) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:236) ... 19 more Caused by: org.apache.maven.wagon.TransferFailedException: Error transferring file at org.apache.maven.wagon.providers.http.LightweightHttpWagon.finishPutTransfer(LightweightHttpWagon.java:213) at org.apache.maven.wagon.Abstrac
[jira] Closed: (MNG-4610) Bump maven-release-plugin to v2.0 in super POM
[ http://jira.codehaus.org/browse/MNG-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4610. -- Resolution: Fixed Fix Version/s: 3.0-alpha-8 Assignee: Benjamin Bentmann Done in [r927965|http://svn.apache.org/viewvc?view=revision&revision=927965]. Still, given that most of the Release Plugin goals require a POM, you're in rather good position to just control the plugin version yourself. > Bump maven-release-plugin to v2.0 in super POM > -- > > Key: MNG-4610 > URL: http://jira.codehaus.org/browse/MNG-4610 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.0-alpha-7 > Environment: n/a >Reporter: Anders Hammar >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-8 > > > Change the default version of maven-release-plugin to 2.0 in the super POM. > The background for this request is that v2.0-beta-9 doesn't have signatures > and I have some customers requiring signature verification for Apache > artifacts. As some Maven commands are run outside of a POM, the default > version would be used. Which doesn't work in this case. -- 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: (MNG-4612) Password escpaping doesn't work
[
http://jira.codehaus.org/browse/MNG-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4612:
---
Description:
In MNG-4611 some user presented a *cleartext* password of the form
{noformat}
{DESede}y+qq...==
{noformat}
Given the presence of braces, this password needs to be escaped to be used as a
cleartext password. However, the escaping syntax documented in [Maven Password
Encryption|http://maven.apache.org/guides/mini/guide-encryption.html#Tips] is
broken. Trying the documented way of putting in backslashes and embedding the
entire string again in braces like
{noformat}
{\{DESede\}y+qq...==}
{noformat}
yields
{noformat}
[WARNING] Not decrypting password for server 'maven-core-it' due to exception
in security handler.
Cause: null
[DEBUG] Full trace follows
org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
org.sonatype.plexus.components.cipher.PlexusCipherException:
java.lang.ArrayIndexOutOfBoundsException
at
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher.decrypt(DefaultSecDispatcher.java:121)
at
org.apache.maven.DefaultMaven.resolveParameters(DefaultMaven.java:738)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:250)
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:592)
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.sonatype.plexus.components.cipher.PlexusCipherException:
java.lang.ArrayIndexOutOfBoundsException
at
org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:193)
at
org.sonatype.plexus.components.cipher.DefaultPlexusCipher.decrypt(DefaultPlexusCipher.java:72)
at
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher.decrypt(DefaultSecDispatcher.java:96)
... 13 more
Caused by: java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at
org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:175)
... 15 more
{noformat}
Trying without the surrounding braces as suggested by the source code
{noformat}
\{DESede\}y+qq...==
{noformat}
successfully prevents decryption, but the string isn't unescaped either, making
Maven use a wrong password.
was:
In MNG-4611 some user presented a *cleartext* password of the form
{noformat}
{DESede}y+qq...==
{noformat}
Given the presence of braces, this password needs to be escaped to be used as a
cleartext password. However, the escaping syntax documented in [Maven Password
Encryption|http://maven.apache.org/guides/mini/guide-encryption.html#Tips] is
broken. Trying the documented way of putting in backslashes and embedding the
entire string again in braces like
{noformat}
{\{DESede\}y+qq...==}
{noformat}
yields
{noformat}
[WARNING] Not decrypting password for server 'maven-core-it' due to exception
in security handler.
Cause: null
[DEBUG] Full trace follows
org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
org.sonatype.plexus.components.cipher.PlexusCipherException:
java.lang.ArrayIndexOutOfBoun
dsException
at
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher.decrypt(DefaultSecDispatcher.java:121)
at
org.apache.maven.DefaultMaven.resolveParameters(DefaultMaven.java:738)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:250)
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:592)
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(La
[jira] Created: (MNG-4612) Password escpaping doesn't work
Password escpaping doesn't work
---
Key: MNG-4612
URL: http://jira.codehaus.org/browse/MNG-4612
Project: Maven 2 & 3
Issue Type: Bug
Components: Settings
Affects Versions: 3.0-alpha-7, 2.2.1
Reporter: Benjamin Bentmann
Priority: Minor
In MNG-4611 some user presented a *cleartext* password of the form
{noformat}
{DESede}y+qq...==
{noformat}
Given the presence of braces, this password needs to be escaped to be used as a
cleartext password. However, the escaping syntax documented in [Maven Password
Encryption|http://maven.apache.org/guides/mini/guide-encryption.html#Tips] is
broken. Trying the documented way of putting in backslashes and embedding the
entire string again in braces like
{noformat}
{\{DESede\}y+qq...==}
{noformat}
yields
{noformat}
[WARNING] Not decrypting password for server 'maven-core-it' due to exception
in security handler.
Cause: null
[DEBUG] Full trace follows
org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
org.sonatype.plexus.components.cipher.PlexusCipherException:
java.lang.ArrayIndexOutOfBoun
dsException
at
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher.decrypt(DefaultSecDispatcher.java:121)
at
org.apache.maven.DefaultMaven.resolveParameters(DefaultMaven.java:738)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:250)
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:592)
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.sonatype.plexus.components.cipher.PlexusCipherException:
java.lang.ArrayIndexOutOfBoundsException
at
org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:193)
at
org.sonatype.plexus.components.cipher.DefaultPlexusCipher.decrypt(DefaultPlexusCipher.java:72)
at
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher.decrypt(DefaultSecDispatcher.java:96)
... 13 more
Caused by: java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at
org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:175)
... 15 more
{noformat}
Trying without the surrounding braces as suggested by the source code
{noformat}
\{DESede\}y+qq...==
{noformat}
successfully prevents decryption, but the string isn't unescaped either, making
Maven use a wrong password.
--
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-4611) 3.0-alpha7 password decryption log verbosity
[
http://jira.codehaus.org/browse/MNG-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4611.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
In conformance with [Maven Password
Encryption|http://maven.apache.org/guides/mini/guide-encryption.html], the
password you use should be decrypted by Maven but its format is invalid, so the
log messages are justified.
AFAICT, the escape mechanism documented on that page is broken, so right now
your only option is to either ignore the log messages or encrypt you password
properly using Maven.
> 3.0-alpha7 password decryption log verbosity
>
>
> Key: MNG-4611
> URL: http://jira.codehaus.org/browse/MNG-4611
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: Dale Wyttenbach
>Assignee: Benjamin Bentmann
>
> The log verbosity of password decryption in 3.0-alpha7 that makes the mvn -X
> option effectively unusable. The password I've got in my settings.xml file
> looks like this:
> {DESede}y+qq...==
> This is an Artifactory setup password and it does work, however mvn -X logs
> exceptions about it so frequently that it makes -X almost impossible to use.
> Is there some way I can suppress this behavior through configuration? The
> exception that it logs over and over again is:
> [DEBUG] Failed to decrypt password for server central:
> org.sonatype.plexus.components.cipher.PlexusCipherException:
> java.lang.ArrayIndexOutOfBoundsException
> org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
> org.sonatype.plexus.components.cipher.PlexusCipherException:
> java.lang.ArrayIndexOutOfBoundsException
> ...
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:175)
> ... 47 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: (MNG-4607) Regression: Maven Android Plugin dependency pull in fails under maven3alpha7
[ http://jira.codehaus.org/browse/MNG-4607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215508#action_215508 ] Manfred Moser commented on MNG-4607: I have verified that with the latest snapshot release of the maven android plugin and it indeed works now. Thanks > Regression: Maven Android Plugin dependency pull in fails under maven3alpha7 > > > Key: MNG-4607 > URL: http://jira.codehaus.org/browse/MNG-4607 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0-alpha-7 > Environment: Macosx, Maven 3 alpha 7 from apache, Maven 2.2.1 from > macports >Reporter: Manfred Moser >Assignee: Benjamin Bentmann > > The maven android plugin is supposed to pull in external dependencies during > its build to extract the class files and convert them to dx files. With maven > 3 alpha 7 this does however not happen. With 2.2.1 it works fine. > I have filed an issue on the plugin page > http://code.google.com/p/maven-android-plugin/issues/detail?id=57 > I am also a committer on the plugin and willing to help. However I do not > know where to start - with the maven android plugin and the config or > dependencies of it, maven 3 itself or potentially somehow with the dependency > plugin. > What can I provide to give more details? -- 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-4611) 3.0-alpha7 password decryption log verbosity
3.0-alpha7 password decryption log verbosity
Key: MNG-4611
URL: http://jira.codehaus.org/browse/MNG-4611
Project: Maven 2 & 3
Issue Type: Bug
Reporter: Dale Wyttenbach
The log verbosity of password decryption in 3.0-alpha7 that makes the mvn -X
option effectively unusable. The password I've got in my settings.xml file
looks like this:
{DESede}y+qq...==
This is an Artifactory setup password and it does work, however mvn -X logs
exceptions about it so frequently that it makes -X almost impossible to use.
Is there some way I can suppress this behavior through configuration? The
exception that it logs over and over again is:
[DEBUG] Failed to decrypt password for server central:
org.sonatype.plexus.components.cipher.PlexusCipherException:
java.lang.ArrayIndexOutOfBoundsException
org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
org.sonatype.plexus.components.cipher.PlexusCipherException:
java.lang.ArrayIndexOutOfBoundsException
...
Caused by: java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at
org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:175)
... 47 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: (MCHECKSTYLE-59) Checkstyle Report fails if propertyExpansion contains backslash characters
[ http://jira.codehaus.org/browse/MCHECKSTYLE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215496#action_215496 ] Edward Ciramella commented on MCHECKSTYLE-59: - I'm running maven 2.2.1, Checkstyle plugin 2.5 and I'm running into this exact same problem: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Failed during checkstyle configuration Unable to instantiate GenericIllegalRegexpCheck Our Module is configured as follows: This is just like the example checkstyle gives in their documentation. Full output here: Unable to instantiate GenericIllegalRegexpCheck [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during page generation at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387 ) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) 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:592) 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 during page generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:114) 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.apache.maven.doxia.siterenderer.RendererException: Error rendering Maven report: Failed during checkstyle conf iguration at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:174) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:328) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:132) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:142) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:109) ... 19 more Caused by: org.apache.maven.reporting.MavenReportException: Failed during checkstyle configuration at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:591) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:131) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:164) ... 23 more Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: cannot initialize module TreeWalker - Unable to instantia te GenericIllegalRegexp at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:177) at com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:207) at org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:176) at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:576) ... 25 more Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: Unable to instantiate GenericIllegalRegexp at com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.jav
[jira] Created: (MNG-4610) Bump maven-release-plugin to v2.0 in super POM
Bump maven-release-plugin to v2.0 in super POM -- Key: MNG-4610 URL: http://jira.codehaus.org/browse/MNG-4610 Project: Maven 2 & 3 Issue Type: Improvement Affects Versions: 3.0-alpha-7 Environment: n/a Reporter: Anders Hammar Change the default version of maven-release-plugin to 2.0 in the super POM. The background for this request is that v2.0-beta-9 doesn't have signatures and I have some customers requiring signature verification for Apache artifacts. As some Maven commands are run outside of a POM, the default version would be used. Which doesn't work in this case. -- 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-481) small typo in log message
small typo in log message - Key: MASSEMBLY-481 URL: http://jira.codehaus.org/browse/MASSEMBLY-481 Project: Maven 2.x Assembly Plugin Issue Type: Bug Reporter: Jon Osborn Priority: Trivial when using unpack, the log message shows: [INFO] Unpacking /java_build/maven/repo/company/utils/15.0.0-SNAPSHOT/company-utils-15.0.0-SNAPSHOT.jarto /java_build/hudson/jobs/WL10UpgradeDev/workspace/shared-services/ws-clients/fee/target/classes Note the space missing between the '.jar' and the 'to'. Folks wanting to parse log files may find the lack of whitespace troublesome. -- 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-156) Plugin should support setting file encoding
[
http://jira.codehaus.org/browse/MECLIPSE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215481#action_215481
]
Guillaume Husta commented on MECLIPSE-156:
--
In the last version of MECLIPSE, this still does't work.
Apparently, the last patch by Jerome Lacoste has not been applied
(IdeUtils.java).
I've tested a little, and discovered some problems :
* the value for the property "project.build.sourceEncoding" is not taken into
account (see upper)
* the value for encoding isn't interpolated, so if you use for example
{code:xml}
${myencoding}
{code}
the string "${myencoding}" will be output instead of the interpolated value in
the settings
* the settings are written in the wrong file : _org.eclipse.jdt.core.prefs_
instead of _org.eclipse.core.resources.prefs_ (see
EclipseSettingsWriter.FILE_ECLIPSE_JDT_CORE_PREFS)
* if a new settings file has to be created by this Mojo, maybe should it be
also deleted in the *eclipse:clean* goal (see EclipseCleanMojo)
> Plugin should support setting file encoding
> ---
>
> Key: MECLIPSE-156
> URL: http://jira.codehaus.org/browse/MECLIPSE-156
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
>Reporter: Ralph Poellath
>Assignee: nicolas de loof
> Fix For: 2.8
>
> Attachments: maven-eclipse-plugin-2.5.1.tar.gz,
> MECLIPSE-156-maven-eclipse-plugin.patch,
> MECLIPSE-156_proper_use_of_project_build_sourceEncoding.patch
>
>
> The plugin should support setting Eclipse's text file encoding on a
> per-project basis.
--
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-4609) AMP packaging type is not seen as java project by cobertura
[
http://jira.codehaus.org/browse/MNG-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215473#action_215473
]
Julien HENRY commented on MNG-4609:
---
Maybe a known issue related to plexus and custom packaging type.
To reproduce you can try:
{code}
> mvn archetype:generate -DarchetypeGroupId=com.sourcesense.alfresco
> -DarchetypeArtifactId=maven-alfresco-amp-archetype -DarchetypeVersion=1.9.1
> -DgroupId=com.mycompany \
-DartifactId=myamp -Dversion=1.0-SNAPSHOT
-DarchetypeRepository=http://maven.alfresco.com/nexus/content/repositories/releases
-DinteractiveMode=false
> cd myamp/
> mvn clean cobertura:cobertura
{code}
> AMP packaging type is not seen as java project by cobertura
> ---
>
> Key: MNG-4609
> URL: http://jira.codehaus.org/browse/MNG-4609
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Julien HENRY
>Assignee: Benjamin Bentmann
>
> I have a project that is using Maven Alfresco integration [1] to produce AMP
> artifacts. There is a new packaging type "amp". Looking at the source code of
> the plugin the language is "java" [2].
> On cobertura side there is a check [3] to prevent instrumentation in case of
> non java artifact:
> {code}
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info(
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package" );
> }
> {code}
> As AMP is supposed to be a "java" artifact (and that's actually true) I was
> expecting cobertura to perform instrumentation. But in fact it is not:
> {code}
> [INFO]
>
> [INFO] Building My Project AMP Packaging
> [INFO]task-segment:
> [org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
> [INFO]
>
> [INFO] Preparing cobertura:cobertura
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [INFO] Storing buildNumber: 5 at timestamp: 1268819729587
> [INFO] [nosnapshot:strip {execution: default}]
> [INFO] Storing noSnapshotVersion: 0.1
> [INFO] [resources:resources {execution: default-resources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [cobertura:instrument {execution: default-instrument}]
> [INFO] Not executing cobertura:instrument as the project is not a Java
> classpath-capable package
> [INFO] [resources:testResources {execution: default-testResources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 3 resources
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> /var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
> ---
> T E S T S
> ---
> Running fr.myproject.contrat.CoreTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO] [cobertura:cobertura {execution: default-cli}]
> [INFO] Not executing cobertura:report as the cobertura data file
> (/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
> could not be found
> [WARN] Cobertura report not found at
> /var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
> {code}
> Do you have any idea of the problem? Does it come from AMP plugin, cobertura
> plugin or Maven core?
> [1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
> [2]
> http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
> [3]
> http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
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] Reopened: (MNG-4609) AMP packaging type is not seen as java project by cobertura
[
http://jira.codehaus.org/browse/MNG-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien HENRY reopened MNG-4609:
---
> AMP packaging type is not seen as java project by cobertura
> ---
>
> Key: MNG-4609
> URL: http://jira.codehaus.org/browse/MNG-4609
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Julien HENRY
>Assignee: Benjamin Bentmann
>
> I have a project that is using Maven Alfresco integration [1] to produce AMP
> artifacts. There is a new packaging type "amp". Looking at the source code of
> the plugin the language is "java" [2].
> On cobertura side there is a check [3] to prevent instrumentation in case of
> non java artifact:
> {code}
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info(
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package" );
> }
> {code}
> As AMP is supposed to be a "java" artifact (and that's actually true) I was
> expecting cobertura to perform instrumentation. But in fact it is not:
> {code}
> [INFO]
>
> [INFO] Building My Project AMP Packaging
> [INFO]task-segment:
> [org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
> [INFO]
>
> [INFO] Preparing cobertura:cobertura
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [INFO] Storing buildNumber: 5 at timestamp: 1268819729587
> [INFO] [nosnapshot:strip {execution: default}]
> [INFO] Storing noSnapshotVersion: 0.1
> [INFO] [resources:resources {execution: default-resources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [cobertura:instrument {execution: default-instrument}]
> [INFO] Not executing cobertura:instrument as the project is not a Java
> classpath-capable package
> [INFO] [resources:testResources {execution: default-testResources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 3 resources
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> /var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
> ---
> T E S T S
> ---
> Running fr.myproject.contrat.CoreTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO] [cobertura:cobertura {execution: default-cli}]
> [INFO] Not executing cobertura:report as the cobertura data file
> (/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
> could not be found
> [WARN] Cobertura report not found at
> /var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
> {code}
> Do you have any idea of the problem? Does it come from AMP plugin, cobertura
> plugin or Maven core?
> [1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
> [2]
> http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
> [3]
> http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
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-4609) AMP packaging type is not seen as java project by cobertura
[
http://jira.codehaus.org/browse/MNG-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4609.
--
Resolution: Incomplete
Assignee: Benjamin Bentmann
bq. Do you have any idea of the problem?
No offense, but seriously how are we supposed to tell without some demo project
to reproduce this?
> AMP packaging type is not seen as java project by cobertura
> ---
>
> Key: MNG-4609
> URL: http://jira.codehaus.org/browse/MNG-4609
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Julien HENRY
>Assignee: Benjamin Bentmann
>
> I have a project that is using Maven Alfresco integration [1] to produce AMP
> artifacts. There is a new packaging type "amp". Looking at the source code of
> the plugin the language is "java" [2].
> On cobertura side there is a check [3] to prevent instrumentation in case of
> non java artifact:
> {code}
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info(
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package" );
> }
> {code}
> As AMP is supposed to be a "java" artifact (and that's actually true) I was
> expecting cobertura to perform instrumentation. But in fact it is not:
> {code}
> [INFO]
>
> [INFO] Building My Project AMP Packaging
> [INFO]task-segment:
> [org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
> [INFO]
>
> [INFO] Preparing cobertura:cobertura
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [INFO] Storing buildNumber: 5 at timestamp: 1268819729587
> [INFO] [nosnapshot:strip {execution: default}]
> [INFO] Storing noSnapshotVersion: 0.1
> [INFO] [resources:resources {execution: default-resources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [cobertura:instrument {execution: default-instrument}]
> [INFO] Not executing cobertura:instrument as the project is not a Java
> classpath-capable package
> [INFO] [resources:testResources {execution: default-testResources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 3 resources
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> /var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
> ---
> T E S T S
> ---
> Running fr.myproject.contrat.CoreTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO] [cobertura:cobertura {execution: default-cli}]
> [INFO] Not executing cobertura:report as the cobertura data file
> (/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
> could not be found
> [WARN] Cobertura report not found at
> /var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
> {code}
> Do you have any idea of the problem? Does it come from AMP plugin, cobertura
> plugin or Maven core?
> [1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
> [2]
> http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
> [3]
> http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
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-3700) ModelUtils.clone doesn't clone plugin entries where inherited == false
[ http://jira.codehaus.org/browse/MNG-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-3700. -- Resolution: Fixed Assignee: Benjamin Bentmann ModelUtils is no longer used in 3.x, instead it uses Modello generated clone() methods. > ModelUtils.clone doesn't clone plugin entries where inherited == false > -- > > Key: MNG-3700 > URL: http://jira.codehaus.org/browse/MNG-3700 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-8 > > Attachments: ModelUtilsTest.patch > > > ModelUtils.clone(..) uses the ModelInheritanceAssembler under the covers, > with assembleAsInheritance == true. This is not strictly true, since > inheritance semantics are different in some ways from clone semantics. > This becomes an issue where plugins are concerned, especially when the plugin > entry in the POM contains inherited == "false", which will lead to the > cloning process *excluding* that plugin from the clone result. -- 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-3287) profiles.xml does not always override pom.xml, at least when using sub-modules
[ http://jira.codehaus.org/browse/MNG-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-3287. -- Resolution: Won't Fix Fix Version/s: (was: 3.0-alpha-8) Assignee: Benjamin Bentmann As per MNG-4060, support for profiles.xml has been dropped. > profiles.xml does not always override pom.xml, at least when using sub-modules > -- > > Key: MNG-3287 > URL: http://jira.codehaus.org/browse/MNG-3287 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation, Profiles >Affects Versions: 2.0.7 >Reporter: Boris Maras >Assignee: Benjamin Bentmann > Attachments: TestInheritance.zip > > > I have attached a test case to reproduce the problem. It has to be launched > with profile "dev". > I have a master pom.xml and a child pom.xml > In the master pom.xml is defined a profile "dev", with a property set to the > value "dev_pom.xml". > In the child pom.xml, I display the value of the property with the ant plugin. > There is also a file profiles.xml that overrides the property of the profile, > with the value "dev_profiles.xml". > If you run "mvn install -Pdev" on the child module, it displays > "dev_profiles.xml". > If you run "mvn antrun:run -Pdev" on the child module, it also displays > "dev_profiles.xml". > But if you run "mvn install -Pdev" on the master module, it displays > "dev_pom.xml". > It looks like the child module uses the value defined in the master pom, and > ignores the fact that it has been overriden by profiles.xml. And this > behavior occurs only if this child module is called through the master pom. > Moreover, if you remove the value in the master pom, then the child pom is > able to find the value in profiles.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: (MNG-4609) AMP packaging type is not seen as java project by cobertura
AMP packaging type is not seen as java project by cobertura
---
Key: MNG-4609
URL: http://jira.codehaus.org/browse/MNG-4609
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
I have a project that is using Maven Alfresco integration [1] to produce AMP
artifacts. There is a new packaging type "amp". Looking at the source code of
the plugin the language is "java" [2].
On cobertura side there is a check [3] to prevent instrumentation in case of
non java artifact:
{code}
ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
if ( !"java".equals( artifactHandler.getLanguage() ) )
{
getLog().info(
"Not executing cobertura:instrument as the project is not a Java
classpath-capable package" );
}
{code}
As AMP is supposed to be a "java" artifact (and that's actually true) I was
expecting cobertura to perform instrumentation. But in fact it is not:
{code}
[INFO]
[INFO] Building My Project AMP Packaging
[INFO]task-segment: [org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
[INFO]
[INFO] Preparing cobertura:cobertura
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 5 at timestamp: 1268819729587
[INFO] [nosnapshot:strip {execution: default}]
[INFO] Storing noSnapshotVersion: 0.1
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Not executing cobertura:instrument as the project is not a Java
classpath-capable package
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
---
T E S T S
---
Running fr.myproject.contrat.CoreTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [cobertura:cobertura {execution: default-cli}]
[INFO] Not executing cobertura:report as the cobertura data file
(/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
could not be found
[WARN] Cobertura report not found at
/var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
{code}
Do you have any idea of the problem? Does it come from AMP plugin, cobertura
plugin or Maven core?
[1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
[2]
http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
[3]
http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
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: (MNG-3725) Cannot override plugin dependencies in maven 2.0.9
[
http://jira.codehaus.org/browse/MNG-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-3725:
---
Attachment: pom.xml
Using Maven 2.0.9 on the attached POM yields the following debug output:
{noformat}
[DEBUG] Plugin dependencies for:
org.apache.torque:torque-maven-plugin:3.3
are:
org.apache.torque:torque-templates:jar:3.3-RC3:compile
org.apache.maven:maven-plugin-api:jar:2.0:runtime
org.apache.maven:maven-artifact:jar:2.0:runtime
org.apache.maven:maven-settings:jar:2.0:runtime
org.apache.maven:maven-plugin-descriptor:jar:2.0:runtime
org.apache.maven:maven-core:jar:2.0:runtime
org.apache.torque:torque-generator:jar:3.3:runtime
org.apache.maven:maven-project:jar:2.0:runtime
org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
log4j:log4j:jar:1.2.14:runtime
commons-configuration:commons-configuration:jar:1.4:runtime
{noformat}
i.e. the overriden version of torque-templates is used.
More than likely, the issue is another occurrence of MNG-1323.
As a final note, the act of downloading something does not induce it is
actually used.
> Cannot override plugin dependencies in maven 2.0.9
> --
>
> Key: MNG-3725
> URL: http://jira.codehaus.org/browse/MNG-3725
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_13
> OS name: "mac os x" version: "10.5.4" arch: "ppc" Family: "unix"
>Reporter: Graham Leggett
> Attachments: pom.xml
>
>
> When an attempt is made to override the version of torque-templates used by
> the maven-torque-plugin as below, maven still tries to use the original
> version of the torque-templates jar. The overridden jar is ignored.
> According to http://jira.codehaus.org/browse/MNG-2972, this behaviour used to
> be broken in maven v2.0.8 and earlier, and was apparently fixed. This doesn't
> seem to be the case though.
> The configuration looks like this:
> {code:xml}
>
> org.apache.torque
> torque-maven-plugin
> 3.3
>
>
> org.apache.derby
> derby
> 10.4.1.3
>
>
> org.apache.torque
> torque-templates
> 3.3.1
>
>
>
> {code}
> The original torque-templates jar is v3.3. The overridden torque-templates
> jar is v3.3.1.
> As the plugin gives no clues as to which version is being used, I deleted the
> original torque-templates v3.3 release from the local repository. What I
> expected to see was maven ignoring the v3.3 jar and using the v3.3.1 jar
> instead, but maven tries to re-download the v3.3 release and use it instead.
> maven-torque-plugin depends on torque-gen, which in turn depends on
> torque-templates. It may be that direct plugin dependencies can be
> overridden, but transitive plugin dependencies cannot be overridden.
--
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-3725) Cannot override plugin dependencies in maven 2.0.9
[
http://jira.codehaus.org/browse/MNG-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-3725.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 3.0-alpha-8)
Assignee: Benjamin Bentmann
> Cannot override plugin dependencies in maven 2.0.9
> --
>
> Key: MNG-3725
> URL: http://jira.codehaus.org/browse/MNG-3725
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_13
> OS name: "mac os x" version: "10.5.4" arch: "ppc" Family: "unix"
>Reporter: Graham Leggett
>Assignee: Benjamin Bentmann
> Attachments: pom.xml
>
>
> When an attempt is made to override the version of torque-templates used by
> the maven-torque-plugin as below, maven still tries to use the original
> version of the torque-templates jar. The overridden jar is ignored.
> According to http://jira.codehaus.org/browse/MNG-2972, this behaviour used to
> be broken in maven v2.0.8 and earlier, and was apparently fixed. This doesn't
> seem to be the case though.
> The configuration looks like this:
> {code:xml}
>
> org.apache.torque
> torque-maven-plugin
> 3.3
>
>
> org.apache.derby
> derby
> 10.4.1.3
>
>
> org.apache.torque
> torque-templates
> 3.3.1
>
>
>
> {code}
> The original torque-templates jar is v3.3. The overridden torque-templates
> jar is v3.3.1.
> As the plugin gives no clues as to which version is being used, I deleted the
> original torque-templates v3.3 release from the local repository. What I
> expected to see was maven ignoring the v3.3 jar and using the v3.3.1 jar
> instead, but maven tries to re-download the v3.3 release and use it instead.
> maven-torque-plugin depends on torque-gen, which in turn depends on
> torque-templates. It may be that direct plugin dependencies can be
> overridden, but transitive plugin dependencies cannot be overridden.
--
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-2036) The clean plugin requires dependent plugins defined in a project's pom.xml to be in the repository before it can perform a clean
[
http://jira.codehaus.org/browse/MNG-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-2036.
--
Resolution: Not A Bug
Fix Version/s: (was: 3.0-alpha-8)
Assignee: Benjamin Bentmann
"mvn clean" refers to a lifecycle phase and in order to calculate what plugins
participate in that, the phase for each and every plugin execution needs to be
determined. If the POM lacks this information, the plugin metadata needs to be
consulted/resolved.
Users that don't like this can simply add the missing {{}} elements to
the plugin executions or just invoke "mvn clean:clean" directly.
> The clean plugin requires dependent plugins defined in a project's pom.xml to
> be in the repository before it can perform a clean
>
>
> Key: MNG-2036
> URL: http://jira.codehaus.org/browse/MNG-2036
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Plugins and Lifecycle
> Environment: maven2 2.0.1
>Reporter: Chad Brandon
>Assignee: Benjamin Bentmann
>
> It appears that any plugins that are in my pom.xml need to be downloaded
> before clean can work, otherwise it fails with unsatisfied dependencies (for
> example, I can't clean our distribution until the rest of the plugins of our
> build are installed).
--
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-4608) Cross module dependencies for multi-module projects
[ http://jira.codehaus.org/browse/MNG-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4608. -- Resolution: Duplicate Assignee: Benjamin Bentmann > Cross module dependencies for multi-module projects > --- > > Key: MNG-4608 > URL: http://jira.codehaus.org/browse/MNG-4608 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 2.0.9 > Environment: windows, jdk1.6.0_16 >Reporter: Robert Lieb >Assignee: Benjamin Bentmann >Priority: Blocker > > Considering a multi-module project A which declares two sub-projects > (modules) B and C. > Having module C indicating in its POM a dependency against module B. > Module B uses the shade plugin to 'merge' classes from B with his > dependencies. > Separate install of B and C works fine, but an install on A fails by > compiling C > because of missing classes. Maven don't use the generated jar file of B for > compiling C. > I need a different behaviour (maybe command line option) to change it. > This is not only related to shade plugin. In any cases in which a maven > project uses > some 'manipulation' plugins after compile phase, will fail. -- 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-4608) Cross module dependencies for multi-module projects
Cross module dependencies for multi-module projects --- Key: MNG-4608 URL: http://jira.codehaus.org/browse/MNG-4608 Project: Maven 2 & 3 Issue Type: Improvement Affects Versions: 2.0.9 Environment: windows, jdk1.6.0_16 Reporter: Robert Lieb Priority: Blocker Considering a multi-module project A which declares two sub-projects (modules) B and C. Having module C indicating in its POM a dependency against module B. Module B uses the shade plugin to 'merge' classes from B with his dependencies. Separate install of B and C works fine, but an install on A fails by compiling C because of missing classes. Maven don't use the generated jar file of B for compiling C. I need a different behaviour (maybe command line option) to change it. This is not only related to shade plugin. In any cases in which a maven project uses some 'manipulation' plugins after compile phase, will fail. -- 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
