[jira] Closed: (MNG-4318) MavenProject.executionRoot is not set correctly
[ http://jira.codehaus.org/browse/MNG-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4318. -- Assignee: Benjamin Bentmann Resolution: Fixed Fixed in [r807526|http://svn.apache.org/viewvc?view=rev&revision=807526]. > MavenProject.executionRoot is not set correctly > --- > > Key: MNG-4318 > URL: http://jira.codehaus.org/browse/MNG-4318 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0-alpha-3 >Reporter: Olivier Lamy >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-3 > > > using site plugin from 3.x branch and trunk 807360. > It MSITE-304 failed due to non project with executionRoot set to true -- 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-4319) Property expansion does not work for goals in plugin executions
Property expansion does not work for goals in plugin executions
---
Key: MNG-4319
URL: http://jira.codehaus.org/browse/MNG-4319
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.2.1, 2.2.0, 2.1.0, 2.1.0-M1
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_02
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Marc Rohlfs
I am using a (global) property to control the goal(s) of the Assembly Plugin to
be executed:
{code:xml}
${build.assembly.goal}
{code}
The property is pre-defined in my (parent) POM and may be overwritten using the
{{-D}} option on the command line or (for convenience) using a profile. This is
(was) a very convenient way to switch from ZIP (goal {{single}}) to directory
(goal {{directory-single}}) packaging during development of programm packages.
When I tried to upgrade from Maven 2.0.10 to Maven 2.2.1 I noticed that this
doesn't work any more. I also tried intermediate versions and it seems that
2.0.10 was the last version where it works.
--
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-4320) [regression] Aggregators invoked from CLI no longer resolve dependencies for all reactor projects
[regression] Aggregators invoked from CLI no longer resolve dependencies for
all reactor projects
-
Key: MNG-4320
URL: http://jira.codehaus.org/browse/MNG-4320
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle, Reactor and workspace
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
For a mojo with
{code:java}
@requiresDependencyResolution test
@aggregrator true
{code}
that gets directly from the CLI the dependencies of all projects in the reactor
should be resolved, not just the dependencies of the top-level project.
--
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-4320) [regression] Aggregators invoked from CLI no longer resolve dependencies for all reactor projects
[
http://jira.codehaus.org/browse/MNG-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4320:
---
Description:
For a mojo with
{code:java}
@requiresDependencyResolution test
@aggregrator true
{code}
that gets invoked directly from the CLI the dependencies of all projects in the
reactor should be resolved, not just the dependencies of the top-level project.
was:
For a mojo with
{code:java}
@requiresDependencyResolution test
@aggregrator true
{code}
that gets directly from the CLI the dependencies of all projects in the reactor
should be resolved, not just the dependencies of the top-level project.
> [regression] Aggregators invoked from CLI no longer resolve dependencies for
> all reactor projects
> -
>
> Key: MNG-4320
> URL: http://jira.codehaus.org/browse/MNG-4320
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 3.0-alpha-3
>Reporter: Benjamin Bentmann
>
> For a mojo with
> {code:java}
> @requiresDependencyResolution test
> @aggregrator true
> {code}
> that gets invoked directly from the CLI the dependencies of all projects in
> the reactor should be resolved, not just the dependencies of the top-level
> project.
--
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-4321) [regression] Configuration from plugin management is not applied to goals invoked from CLI
[regression] Configuration from plugin management is not applied to goals
invoked from CLI
--
Key: MNG-4321
URL: http://jira.codehaus.org/browse/MNG-4321
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
E.g. for
{code:xml}
org.apache.maven.plugins
maven-antrun-plugin
1.3
PASSED
{code}
and "mvn antrun:run" nothing gets printed, i.e. the configured echo task is
lost.
The bug only applies to those plugins that are not also given in the regular
build/plugins sections, either explicitly or implicitly by lifecycle mappings.
--
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-4321) [regression] Plugin-level configuration from plugin management is not applied to goals invoked from CLI
[
http://jira.codehaus.org/browse/MNG-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4321:
---
Summary: [regression] Plugin-level configuration from plugin management is
not applied to goals invoked from CLI (was: [regression] Configuration from
plugin management is not applied to goals invoked from CLI)
> [regression] Plugin-level configuration from plugin management is not applied
> to goals invoked from CLI
> ---
>
> Key: MNG-4321
> URL: http://jira.codehaus.org/browse/MNG-4321
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3
>Reporter: Benjamin Bentmann
>
> E.g. for
> {code:xml}
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.3
>
>
> PASSED
>
>
>
>
>
>
> {code}
> and "mvn antrun:run" nothing gets printed, i.e. the configured echo task is
> lost.
> The bug only applies to those plugins that are not also given in the regular
> build/plugins sections, either explicitly or implicitly by lifecycle mappings.
--
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: (MSHARED-120) Unable to generate single report with latest maven-reporting-impl
[
http://jira.codehaus.org/browse/MSHARED-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188437#action_188437
]
Vincent Siveton commented on MSHARED-120:
-
Dennis, the differences are not betwen the latest Doxia/Reporting-impl version
and the previous versions but when you *upgrade* a plugin to these dependencies.
Several Maven release plugins use old (very old) Doxia/reporting-impl. Takes
the changelog plugin case:
The release POM [1] uses this dependency:
{noformat}
doxia
doxia-sink-api
1.0-alpha-5
{noformat}
Take care of the groupId.
FYI, in the repos, Doxia has 3 differents groupdIds: _doxia_,
_org.codehaus.doxia_ and the official _org.apache.maven.doxia_
Here are the steps to bump to latest releases:
- checkout the changelog tag and uses the 2.1.1-SNAPSHOT version
- update the POM to Doxia to org.apache.maven.doxia:doxia-sink-api:1.0
- update to reporting impl 2.0.4 or later. This implies to replace
org.codehaus.doxia.* imports by org.apache.maven.doxia.* and to modify the
renderer component.
Now, running the following, no single report will be generated:
{noformat}
mvn org.apache.maven.plugins:maven-changelog-plugin:2.1.1-SNAPSHOT:changelog
{noformat}
Is it more clear?
[1]
http://repo2.maven.org/maven2/org/apache/maven/plugins/maven-changelog-plugin/2.1/maven-changelog-plugin-2.1.pom
> Unable to generate single report with latest maven-reporting-impl
> -
>
> Key: MSHARED-120
> URL: http://jira.codehaus.org/browse/MSHARED-120
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl 2.0.4.1, maven-reporting-impl
> 2.0.4.2
>Reporter: Vincent Siveton
>Priority: Blocker
> Attachments: MSHARED-120.patch, reporting.patch
>
>
> Recently, I fixed several report plugins (changelog, changes etc.) to use
> Doxia 1.0 and latest maven-reporting-impl.
> The main goal was to make reporting plugins available in PDF (see MPDF-26 and
> doc [1])
> I notified that running a single report doesn't work but works when coupling
> with maven-site-plugin 2.0.x.
> For instance, run:
> {noformat}
> mvn org.apache.maven.plugins:maven-changelog-plugin:2.2-SNAPSHOT:changelog
> {noformat}
> In Doxia 1.0, the SiteRenderSink [2] uses a StringWriter by default to use
> getBody() in the renderer [3]. So running a single report doesn't write a
> file with reporting-impl:2.0.4.2
> In MPIR 2.1.2, we overrided the mojo.execute() to handle a default renderer
> [4] so we are able to run a single report. I propose to move this logic in
> AbstractMavenReport.
> [1]
> http://maven.apache.org/plugins/maven-pdf-plugin-1.1-SNAPSHOT/examples/configuring-reports.html#Maven_Reporting_Plugins_Issues
> [2]
> http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/sink/SiteRendererSink.html#47
> [3]
> http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.html#433
> [4]
> http://maven.apache.org/plugins/maven-project-info-reports-plugin/xref/org/apache/maven/report/projectinfo/AbstractProjectInfoReport.html#137
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-366) Wrong TOC when styles
Wrong TOC when styles
-
Key: DOXIA-366
URL: http://jira.codehaus.org/browse/DOXIA-366
Project: Maven Doxia
Issue Type: Bug
Components: Core
Affects Versions: 1.1.1
Reporter: Vincent Siveton
Using the following APT
{noformat}
Main Title
%{toc|section=0|fromDepth=0|toDepth=5}
* {sectionTitle1}
foo
* {sectionTitle2 with the <<<\>>>}
bar
{noformat}
The generated TOC is
{noformat}
* Main Title
o sectionTitle1
o sectionTitle2 with the
{noformat}
--
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: (MSHARED-120) No single report generated with latest maven-reporting-impl
[
http://jira.codehaus.org/browse/MSHARED-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MSHARED-120:
Summary: No single report generated with latest maven-reporting-impl (was:
Unable to generate single report with latest maven-reporting-impl)
> No single report generated with latest maven-reporting-impl
> ---
>
> Key: MSHARED-120
> URL: http://jira.codehaus.org/browse/MSHARED-120
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl 2.0.4.1, maven-reporting-impl
> 2.0.4.2
>Reporter: Vincent Siveton
>Priority: Blocker
> Attachments: MSHARED-120.patch, reporting.patch
>
>
> Recently, I fixed several report plugins (changelog, changes etc.) to use
> Doxia 1.0 and latest maven-reporting-impl.
> The main goal was to make reporting plugins available in PDF (see MPDF-26 and
> doc [1])
> I notified that running a single report doesn't work but works when coupling
> with maven-site-plugin 2.0.x.
> For instance, run:
> {noformat}
> mvn org.apache.maven.plugins:maven-changelog-plugin:2.2-SNAPSHOT:changelog
> {noformat}
> In Doxia 1.0, the SiteRenderSink [2] uses a StringWriter by default to use
> getBody() in the renderer [3]. So running a single report doesn't write a
> file with reporting-impl:2.0.4.2
> In MPIR 2.1.2, we overrided the mojo.execute() to handle a default renderer
> [4] so we are able to run a single report. I propose to move this logic in
> AbstractMavenReport.
> [1]
> http://maven.apache.org/plugins/maven-pdf-plugin-1.1-SNAPSHOT/examples/configuring-reports.html#Maven_Reporting_Plugins_Issues
> [2]
> http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/sink/SiteRendererSink.html#47
> [3]
> http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.html#433
> [4]
> http://maven.apache.org/plugins/maven-project-info-reports-plugin/xref/org/apache/maven/report/projectinfo/AbstractProjectInfoReport.html#137
--
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-4321) [regression] Plugin-level configuration from plugin management is not applied to goals invoked from CLI
[
http://jira.codehaus.org/browse/MNG-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4321.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 3.0-alpha-3
Fixed in [r807576|http://svn.apache.org/viewvc?view=rev&revision=807576].
> [regression] Plugin-level configuration from plugin management is not applied
> to goals invoked from CLI
> ---
>
> Key: MNG-4321
> URL: http://jira.codehaus.org/browse/MNG-4321
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
>
> E.g. for
> {code:xml}
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.3
>
>
> PASSED
>
>
>
>
>
>
> {code}
> and "mvn antrun:run" nothing gets printed, i.e. the configured echo task is
> lost.
> The bug only applies to those plugins that are not also given in the regular
> build/plugins sections, either explicitly or implicitly by lifecycle mappings.
--
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-4320) [regression] Aggregators invoked from CLI no longer resolve dependencies for all reactor projects
[
http://jira.codehaus.org/browse/MNG-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4320.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 3.0-alpha-3
Fixed in [r807638|http://svn.apache.org/viewvc?view=rev&revision=807638].
> [regression] Aggregators invoked from CLI no longer resolve dependencies for
> all reactor projects
> -
>
> Key: MNG-4320
> URL: http://jira.codehaus.org/browse/MNG-4320
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 3.0-alpha-3
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
>
> For a mojo with
> {code:java}
> @requiresDependencyResolution test
> @aggregrator true
> {code}
> that gets invoked directly from the CLI the dependencies of all projects in
> the reactor should be resolved, not just the dependencies of the top-level
> project.
--
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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188451#action_188451 ] François LEIBER commented on MJAR-28: - Any progress on this? I'm still having the issue with latest available versions of maven (2.2.1) and of all plugins... > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko >Assignee: John Casey > Attachments: MJAR-28-patch.txt > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- 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: (MSHADE-60) [PATCH] maven shade plugin fails if artifact dependencies contain artifacts that cannot be opened with JarFile class
[PATCH] maven shade plugin fails if artifact dependencies contain artifacts that cannot be opened with JarFile class Key: MSHADE-60 URL: http://jira.codehaus.org/browse/MSHADE-60 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.2.1 Reporter: Brane F. Gracnar Attachments: maven-shade-plugin-1.2.1.patch Maven Shade plugin fails to create an artifact if artifact dependecies include artifacts that cannot be opened with JarFile JVM class. This behaviour happens if someone puts something -- 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: (MSHADE-60) [PATCH] maven shade plugin fails if artifact dependencies contain artifacts that cannot be opened with JarFile class
[ http://jira.codehaus.org/browse/MSHADE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188466#action_188466 ] Brane F. Gracnar commented on MSHADE-60: Sorry, i hit enter button by accident. Maven Shade plugin fails to create an artifact if artifact dependecies include artifacts that cannot be opened with JarFile JVM class. This behaviour happens if pom.xml contains something like this: name com.example 1.0.0 pom I attached patch which skips inclusion of files, that cannot be included into artifact. > [PATCH] maven shade plugin fails if artifact dependencies contain artifacts > that cannot be opened with JarFile class > > > Key: MSHADE-60 > URL: http://jira.codehaus.org/browse/MSHADE-60 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Brane F. Gracnar > Attachments: maven-shade-plugin-1.2.1.patch > > > Maven Shade plugin fails to create an artifact if artifact dependecies > include artifacts that cannot be opened with JarFile JVM class. > This behaviour happens if someone puts something > -- 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: (MSHADE-60) [PATCH] maven shade plugin fails if artifact dependencies contain artifacts that cannot be opened with JarFile class
[ http://jira.codehaus.org/browse/MSHADE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188467#action_188467 ] Brane F. Gracnar commented on MSHADE-60: maven-shade-plugin version 1.2.1 fails with the following exception: --- snip --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error creating shaded jar. Embedded error: error in opening zip file [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error creating shaded jar. 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:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating shaded jar. at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:402) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.java:114) at java.util.jar.JarFile.(JarFile.java:133) at java.util.jar.JarFile.(JarFile.java:97) at org.apache.maven.plugins.shade.DefaultShader.shade(DefaultShader.java:72) at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:361) ... 19 more --- snip --- > [PATCH] maven shade plugin fails if artifact dependencies contain artifacts > that cannot be opened with JarFile class > > > Key: MSHADE-60 > URL: http://jira.codehaus.org/browse/MSHADE-60 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Brane F. Gracnar > Attachments: maven-shade-plugin-1.2.1.patch > > > Maven Shade plugin fails to create an artifact if artifact dependecies > include artifacts that cannot be opened with JarFile JVM class. > This behaviour happens if someone puts something > -- 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-4322) Ability to rename a dependency's jar when putting it on the lib folder
Ability to rename a dependency's jar when putting it on the lib folder -- Key: MNG-4322 URL: http://jira.codehaus.org/browse/MNG-4322 Project: Maven 2 Issue Type: New Feature Components: Artifacts and Repositories Reporter: Magno Machado Paulo Maven put on my 'lib' folder the jars of my project's dependencies named like -.jar This is a problem when we need to reference the jar filename from sourcecode, because if we change the dependency version, we have to track all source code references to it and correct them. This is the case when importing a taglib into a jsp page It would be better if Maven put only .jar on the lib folder. And even better if it let us use any custom name we want for the dependencies. If no name is specified, then it could use the current pattern. -- 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-4322) Ability to rename a dependency's jar when putting it on the lib folder
[ http://jira.codehaus.org/browse/MNG-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188479#action_188479 ] Benjamin Bentmann commented on MNG-4322: More than likely, you refer to some Maven plugin and not the Maven core. What exactly is "putting it on the lib folder"? Do you have a POM or debug log to look at? > Ability to rename a dependency's jar when putting it on the lib folder > -- > > Key: MNG-4322 > URL: http://jira.codehaus.org/browse/MNG-4322 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Reporter: Magno Machado Paulo > > Maven put on my 'lib' folder the jars of my project's dependencies named like > -.jar > This is a problem when we need to reference the jar filename from sourcecode, > because if we change the dependency version, we have to track all source code > references to it and correct them. This is the case when importing a taglib > into a jsp page > It would be better if Maven put only .jar on the lib folder. And > even better if it let us use any custom name we want for the dependencies. If > no name is specified, then it could use the current pattern. -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MJAR-28: -- Fix Version/s: 2.3 Looks like this is fixed in trunk, so I'm updating the fix version to the next scheduled release. > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko >Assignee: John Casey > Fix For: 2.3 > > Attachments: MJAR-28-patch.txt > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- 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: (MJAR-118) Upgrade maven-archiver dependency to 2.4
[
http://jira.codehaus.org/browse/MJAR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MJAR-118.
--
Resolution: Fixed
Trunk is currently using maven-archiver version 2.4, so this will be fixed by
the next release.
> Upgrade maven-archiver dependency to 2.4
>
>
> Key: MJAR-118
> URL: http://jira.codehaus.org/browse/MJAR-118
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Sören Chittka
> Fix For: 2.3
>
>
> Hi,
> currently I am using the maven-jar-plugin 2.2.
> One of my project-teams really has the need to specify the
> introduced with maven-archiver 2.4.
> Just adding maven-archiver 2.4 to the dependencies of the maven-jar-plugin
> did not help.
> What I am trying is to use following -entry in maven-jar-plugin:
>
> true
> custom
>
> ${artifact.artifactId}.${artifact.extension}
>
> But the classpath-entries are only resolved to null.null, I guess 'artifact'
> is not resolved to anything.
--
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: (MJAR-118) Upgrade maven-archiver dependency to 2.4
[
http://jira.codehaus.org/browse/MJAR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MJAR-118:
---
Priority: Major (was: Critical)
Fix Version/s: 2.3
> Upgrade maven-archiver dependency to 2.4
>
>
> Key: MJAR-118
> URL: http://jira.codehaus.org/browse/MJAR-118
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Sören Chittka
> Fix For: 2.3
>
>
> Hi,
> currently I am using the maven-jar-plugin 2.2.
> One of my project-teams really has the need to specify the
> introduced with maven-archiver 2.4.
> Just adding maven-archiver 2.4 to the dependencies of the maven-jar-plugin
> did not help.
> What I am trying is to use following -entry in maven-jar-plugin:
>
> true
> custom
>
> ${artifact.artifactId}.${artifact.extension}
>
> But the classpath-entries are only resolved to null.null, I guess 'artifact'
> is not resolved to anything.
--
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: (MJAR-105) Regression: Build fails for an empty main jar with 2.2
[
http://jira.codehaus.org/browse/MJAR-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188495#action_188495
]
Paul Gier commented on MJAR-105:
Can you just set the packaging to "pom"? That will skip the compile and jar
related phases. Or is the reason because you still want the test
(test-compile, test-resources, etc) phases to run so that you can create the
test jar?
> Regression: Build fails for an empty main jar with 2.2
> --
>
> Key: MJAR-105
> URL: http://jira.codehaus.org/browse/MJAR-105
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Joerg Schaible
> Attachments: MJAR-105.zip
>
>
> We have quite some projects with integration tests that have only test code,
> but no sources (neither Java nor other resources) that are included into the
> main artifact. With jar-plugin version 2.2 these kind of projects suddenly
> fail:
> {noformat}
> [INFO]
>
> [INFO] Building eIP TempAccess Integration Tests
> [INFO]task-segment: [clean, deploy]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> D:\work\standard\eIP\TempAccess\EnterpriseArchive\integration-test-jar\target
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] No sources to compile
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Compiling 1 source file to
> D:\work\standard\eIP\TempAccess\EnterpriseArchive\integration-test-jar\target\test-classes
> [INFO] [surefire:test]
> [INFO] Tests are skipped.
> [INFO] [jar:jar]
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling JAR
> Embedded error: You must set at least one file.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 14 minutes 44 seconds
> [INFO] Finished at: Wed Apr 16 08:18:43 CEST 2008
> [INFO] Final Memory: 111M/200M
> [INFO]
>
> {noformat}
> With 2.1 an empty main jar has been created and this behaviour was explicitly
> acknowledged in MJAR-8.
> We stumbled about this upgrading from M205 to M209 that allowed us to use
> also the newer jar-plugin version. Currently we're stuck with jar-plugin
> version 2.1 because of 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] Commented: (MJAR-20) Don't create empty jars
[ http://jira.codehaus.org/browse/MJAR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188498#action_188498 ] Paul Gier commented on MJAR-20: --- Rodrigo, I took a look at the patch, but the problem I see is what happens when you get to the install phase? If you try to run "install" with no jar file available the build will crash, this might need to be addressed in the maven install plugin. The other problem would be deploying to the repository. If you deploy a pom with packaging "jar" then it might cause problems in the dependency resolution if there is no jar there. > Don't create empty jars > --- > > Key: MJAR-20 > URL: http://jira.codehaus.org/browse/MJAR-20 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Priority: Minor > Attachments: MJAR-20-02.patch, MJAR-20.patch > > > Creating empty jars is confusing, it should just print a warning > use case: > parent pom attaching test jar, some subprojects may not have tests, why > create jars for them? -- 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-4323) flexibility in profiles.xml
flexibility in profiles.xml --- Key: MNG-4323 URL: http://jira.codehaus.org/browse/MNG-4323 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.1.0 Reporter: Lakshmanan Venkatachalam Priority: Minor It looks like maven is hardcoded to support only the profiles under profiles.xml. Suppose if I have profiles_.xml, its just ignores. I agree we can always activates different profiles based on the -D parameters. But in my situation I could not do it that way. In my environment, bamboo is running in a separate server for nightly build for all the different projects. This server is using maven 2.1.0 version. production, Accepatance and development for this project runs on maven 2.0.9. Maven 2.1.0 not supporting the maven 2.0.9 schema for profiles.xml. So my build breaks in the nightly build. So now i moved the content of profiles.xml into parent pom and passing -D parameter to activiate the profile respectively. I believe If we have flexibility in choosing the profiles.xml filename using parameters as we have for pom files using -f parameter. This is not the major issue and not very common in every environment. But haveint it, is good for scenarios like the one mentioned above. -- 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: (MJAR-105) Regression: Build fails for an empty main jar with 2.2
[
http://jira.codehaus.org/browse/MJAR-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188523#action_188523
]
Joerg Schaible commented on MJAR-105:
-
With package type "pom" you cannot generate Eclipse projects anymore - another
no-no.
Additionally it is very annoying if you setup template projects that do not
contain anything yet.
> Regression: Build fails for an empty main jar with 2.2
> --
>
> Key: MJAR-105
> URL: http://jira.codehaus.org/browse/MJAR-105
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Joerg Schaible
> Attachments: MJAR-105.zip
>
>
> We have quite some projects with integration tests that have only test code,
> but no sources (neither Java nor other resources) that are included into the
> main artifact. With jar-plugin version 2.2 these kind of projects suddenly
> fail:
> {noformat}
> [INFO]
>
> [INFO] Building eIP TempAccess Integration Tests
> [INFO]task-segment: [clean, deploy]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> D:\work\standard\eIP\TempAccess\EnterpriseArchive\integration-test-jar\target
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] No sources to compile
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Compiling 1 source file to
> D:\work\standard\eIP\TempAccess\EnterpriseArchive\integration-test-jar\target\test-classes
> [INFO] [surefire:test]
> [INFO] Tests are skipped.
> [INFO] [jar:jar]
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling JAR
> Embedded error: You must set at least one file.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 14 minutes 44 seconds
> [INFO] Finished at: Wed Apr 16 08:18:43 CEST 2008
> [INFO] Final Memory: 111M/200M
> [INFO]
>
> {noformat}
> With 2.1 an empty main jar has been created and this behaviour was explicitly
> acknowledged in MJAR-8.
> We stumbled about this upgrading from M205 to M209 that allowed us to use
> also the newer jar-plugin version. Currently we're stuck with jar-plugin
> version 2.1 because of 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] Commented: (MANTTASKS-109) classifier not supported
[ http://jira.codehaus.org/browse/MANTTASKS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188525#action_188525 ] Krashan Brahmanjara commented on MANTTASKS-109: --- This problem should be opened. Maven install and deploy support classifier! This option is necesarry and usable. Example of command mvn deploy:deploy-file -DgroupId=org.icefaces -Durl=http://10.4.101.41:/nexus/content/repositories/thirdparty -DrepositoryId=thirdparty -Dversion=1.8.1 -DartifactId=icefaces-parent -Dfile=pom.xml -Dpackaging=pom -DgeneratePom=false -DcreateChecksum=true -Dpackaging=jar -Dclassifier=asseco > classifier not supported > > > Key: MANTTASKS-109 > URL: http://jira.codehaus.org/browse/MANTTASKS-109 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.8 > Environment: ant tasks 2.0.8, ant 1.7.0, Sun Java 5 >Reporter: t redeske >Assignee: Paul Gier > > When attempting to install/deploy with a pom, if the pom contains a > classifier, it doesn't work. > Example pom: > > > 4.0.0 > wow > wow > wow > tar > wowser > > Example build.xml: > > > > > > > > Error is: > Error parsing pom: Unrecognised tag: 'classifier' (position: START_+TAG seen > ... \n ... @9:17) > -- 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-109) classifier not supported
[ http://jira.codehaus.org/browse/MANTTASKS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188529#action_188529 ] Paul Gier commented on MANTTASKS-109: - Krashan, your comment doesn't make any sense. Your example is already supported by the maven deploy plugin, and there is already a way to do this with the ant tasks, so I don't know what you are asking for. > classifier not supported > > > Key: MANTTASKS-109 > URL: http://jira.codehaus.org/browse/MANTTASKS-109 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.8 > Environment: ant tasks 2.0.8, ant 1.7.0, Sun Java 5 >Reporter: t redeske >Assignee: Paul Gier > > When attempting to install/deploy with a pom, if the pom contains a > classifier, it doesn't work. > Example pom: > > > 4.0.0 > wow > wow > wow > tar > wowser > > Example build.xml: > > > > > > > > Error is: > Error parsing pom: Unrecognised tag: 'classifier' (position: START_+TAG seen > ... \n ... @9:17) > -- 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-4324) Add the ability to launch a reactor build with -amd or -am options from a submodule
Add the ability to launch a reactor build with -amd or -am options from a submodule --- Key: MNG-4324 URL: http://jira.codehaus.org/browse/MNG-4324 Project: Maven 2 Issue Type: New Feature Components: Command Line, Reactor and workspace Affects Versions: 2.2.1 Reporter: Arnaud Heritier This is an idea comming from this thread : http://www.nabble.com/Hibernate-feedback-about-Maven-usage.-td25137434.html And more particularly from this blog post : http://relation.to/12116.lace The idea is to not have to set the -pl option, and use the current module for it. Maven will have to search the reactor through parents to construct and launch the build. -- 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-4322) Ability to rename a dependency's jar when putting it on the lib folder
[ http://jira.codehaus.org/browse/MNG-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188536#action_188536 ] Magno Machado Paulo commented on MNG-4322: -- Sorry, I think I wasn't clear... Let's try again.. I'm going to attach a project on this issue where you can see what I'm saying. First, do a "mvn package" on the project. Then, go to TestMaven/target/TestMaven/WEB-INF/lib Among other files, there's a "mentawai-1.14.1.jar" there. What I want is force Maven to rename this jar. To understand why do I whant this, look at the "TestMaven/src/main/webapp/index.jsp" file. The first line on thie file is: <%@ taglib uri="/WEB-INF/lib/mentawai-1.14.1.jar" prefix="mtw" %> Now imagine I have this line on a lot of source files, and I decide to use a new version of the library. I would have to go on any source file and correct the references. Now, imagine Maven had renamed this jar to, say, "mentawai.jar". What I'd have on my index.jsp would be: <%@ taglib uri="/WEB-INF/lib/mentawai.jar" prefix="mtw" %> And if I decide to move to a different version, I don't have to correct any references. I think we could have an addicional tag on the dependency declaration, something like this: org.mentaframework mentawai 1.14.1 compile mentarai.jar <- This is a new tag And, in the case where this new tag isn't used, Maven would use the current pattern, so it would be 100% backward compatible. > Ability to rename a dependency's jar when putting it on the lib folder > -- > > Key: MNG-4322 > URL: http://jira.codehaus.org/browse/MNG-4322 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Reporter: Magno Machado Paulo > Attachments: TestMaven.rar > > > Maven put on my 'lib' folder the jars of my project's dependencies named like > -.jar > This is a problem when we need to reference the jar filename from sourcecode, > because if we change the dependency version, we have to track all source code > references to it and correct them. This is the case when importing a taglib > into a jsp page > It would be better if Maven put only .jar on the lib folder. And > even better if it let us use any custom name we want for the dependencies. If > no name is specified, then it could use the current pattern. -- 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-4322) Ability to rename a dependency's jar when putting it on the lib folder
[ http://jira.codehaus.org/browse/MNG-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magno Machado Paulo updated MNG-4322: - Attachment: TestMaven.rar Test project > Ability to rename a dependency's jar when putting it on the lib folder > -- > > Key: MNG-4322 > URL: http://jira.codehaus.org/browse/MNG-4322 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Reporter: Magno Machado Paulo > Attachments: TestMaven.rar > > > Maven put on my 'lib' folder the jars of my project's dependencies named like > -.jar > This is a problem when we need to reference the jar filename from sourcecode, > because if we change the dependency version, we have to track all source code > references to it and correct them. This is the case when importing a taglib > into a jsp page > It would be better if Maven put only .jar on the lib folder. And > even better if it let us use any custom name we want for the dependencies. If > no name is specified, then it could use the current pattern. -- 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: (MWAR-211) Ability to rename a dependency's jar when putting it on the lib folder
[ http://jira.codehaus.org/browse/MWAR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MNG-4322 to MWAR-211: - Component/s: (was: Artifacts and Repositories) Complexity: (was: Intermediate) Key: MWAR-211 (was: MNG-4322) Project: Maven 2.x WAR Plugin (was: Maven 2) > Ability to rename a dependency's jar when putting it on the lib folder > -- > > Key: MWAR-211 > URL: http://jira.codehaus.org/browse/MWAR-211 > Project: Maven 2.x WAR Plugin > Issue Type: New Feature >Reporter: Magno Machado Paulo > Attachments: TestMaven.rar > > > Maven put on my 'lib' folder the jars of my project's dependencies named like > -.jar > This is a problem when we need to reference the jar filename from sourcecode, > because if we change the dependency version, we have to track all source code > references to it and correct them. This is the case when importing a taglib > into a jsp page > It would be better if Maven put only .jar on the lib folder. And > even better if it let us use any custom name we want for the dependencies. If > no name is specified, then it could use the current pattern. -- 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: (MWAR-211) Ability to rename a dependency's jar when putting it on the lib folder
[ http://jira.codehaus.org/browse/MWAR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188541#action_188541 ] Benjamin Bentmann commented on MWAR-211: I was told the example [File Name Mapping|http://maven.apache.org/plugins/maven-war-plugin/examples/file-name-mapping.html] from the Maven WAR Plugin could be want you want. > Ability to rename a dependency's jar when putting it on the lib folder > -- > > Key: MWAR-211 > URL: http://jira.codehaus.org/browse/MWAR-211 > Project: Maven 2.x WAR Plugin > Issue Type: New Feature >Reporter: Magno Machado Paulo > Attachments: TestMaven.rar > > > Maven put on my 'lib' folder the jars of my project's dependencies named like > -.jar > This is a problem when we need to reference the jar filename from sourcecode, > because if we change the dependency version, we have to track all source code > references to it and correct them. This is the case when importing a taglib > into a jsp page > It would be better if Maven put only .jar on the lib folder. And > even better if it let us use any custom name we want for the dependencies. If > no name is specified, then it could use the current pattern. -- 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] Issue Comment Edited: (MWAR-211) Ability to rename a dependency's jar when putting it on the lib folder
[ http://jira.codehaus.org/browse/MWAR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188541#action_188541 ] Benjamin Bentmann edited comment on MWAR-211 at 8/25/09 5:44 PM: - I was told the example [File Name Mapping|http://maven.apache.org/plugins/maven-war-plugin/examples/file-name-mapping.html] from the Maven WAR Plugin could be what you want. was (Author: bentmann): I was told the example [File Name Mapping|http://maven.apache.org/plugins/maven-war-plugin/examples/file-name-mapping.html] from the Maven WAR Plugin could be want you want. > Ability to rename a dependency's jar when putting it on the lib folder > -- > > Key: MWAR-211 > URL: http://jira.codehaus.org/browse/MWAR-211 > Project: Maven 2.x WAR Plugin > Issue Type: New Feature >Reporter: Magno Machado Paulo > Attachments: TestMaven.rar > > > Maven put on my 'lib' folder the jars of my project's dependencies named like > -.jar > This is a problem when we need to reference the jar filename from sourcecode, > because if we change the dependency version, we have to track all source code > references to it and correct them. This is the case when importing a taglib > into a jsp page > It would be better if Maven put only .jar on the lib folder. And > even better if it let us use any custom name we want for the dependencies. If > no name is specified, then it could use the current pattern. -- 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-2575) I am DynamicJasper's project leader, please upload.
I am DynamicJasper's project leader, please upload. --- Key: MAVENUPLOAD-2575 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2575 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
