[jira] Created: (MAVENUPLOAD-2351) Please upload ICU4J 4.0.1
Please upload ICU4J 4.0.1 - Key: MAVENUPLOAD-2351 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2351 Project: Maven Upload Requests Issue Type: Wish Reporter: Martin Höller Attachments: icu4j-4.0.1-bundle.jar An older version is allready in the repository and the pom for this one is based on the old 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] Updated: (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ http://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rau updated MWAR-33: - Attachment: MWAR-33-workaround.zip MWAR-33-example.zip MWAR-33-example.zip shows the initial issue. MWAR-33-workaround.zip describes the workaround. jars with differents versions can be in WEB-INF/lib with war as dependencies Key: MWAR-33 URL: http://jira.codehaus.org/browse/MWAR-33 Project: Maven 2.x War Plugin Issue Type: Bug Environment: all Reporter: Olivier Lamy Assignee: Stephane Nicoll Fix For: 2.1 Attachments: MWAR-33-example.zip, MWAR-33-workaround.zip Original Estimate: 15 minutes Time Spent: 30 minutes Remaining Estimate: 0 minutes My pom has the following dependencies : - log4j:log4j:1.2.13 - a war with log4j:log4j:1.2.11 included Result the two jars are in WEB-INF/lib. -- 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-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ http://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163848#action_163848 ] Alex Rau commented on MWAR-33: -- Good news. I looks to me as I was able to work around the issue. After a long-day debug session in maven I figured out how to enable the inclusion of transitive dependencies on WAR dependencies. I changed apache-maven-2.0.9/lib/maven-2.0.9-uber.jar/META-INF/plexus/components.xml which obviously configures the plexus container and its components. component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintwar/role-hint implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration typewar/type includesDependenciesfalse/includesDependencies languagejava/language addedToClasspathfalse/addedToClasspath /configuration /component Changing includeDependendies/ from true to false for WAR artifacts causes Maven to not consider dependencies from WAR artifacts to be already included in the WAR artifact itself. Instead they are *properly* resolved including a proper dependency resolution. I'll attach an sample overlay project so that this is reproducible for others. Using the following section in the overlay build itself leads to an empty WEB-INF/lib for the overlay. build plugins plugin artifactIdmaven-war-plugin/artifactId configuration dependentWarExcludes WEB-INF/lib/*.jar/dependentWarExcludes /configuration /plugin /plugins /build This in combination with the above includesDependencies/ change means: an overlay's WEB-INF/lib is populated with *all* transitive dependencies from scratch. Be aware that I only exclude JAR dependencies here for now. Does that make sense ? Feedback appreciated. Personally I would consider this to be the expected default behaviour (compatibility-issues aside) and would love to see that behaviour in a newer release (either default behaviour or a configuration option somewhere). Right now everyone here has to apply these settings manually in their maven installation which is ok for now (but not in the long term). Someone can give feedback on the consequences and side-effects of the above change ? Do we break something here in this respect in other places ? Regards Alex jars with differents versions can be in WEB-INF/lib with war as dependencies Key: MWAR-33 URL: http://jira.codehaus.org/browse/MWAR-33 Project: Maven 2.x War Plugin Issue Type: Bug Environment: all Reporter: Olivier Lamy Assignee: Stephane Nicoll Fix For: 2.1 Original Estimate: 15 minutes Time Spent: 30 minutes Remaining Estimate: 0 minutes My pom has the following dependencies : - log4j:log4j:1.2.13 - a war with log4j:log4j:1.2.11 included Result the two jars are in WEB-INF/lib. -- 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-1144) List 2 or more maven goals in the defaultGoal of the POM.
[ http://jira.codehaus.org/browse/MNG-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163881#action_163881 ] Brett Porter commented on MNG-1144: --- Unfortunately, POM changes are unlikely in 2.1.x at this stage, and 2.0.x is frozen. List 2 or more maven goals in the defaultGoal of the POM. --- Key: MNG-1144 URL: http://jira.codehaus.org/browse/MNG-1144 Project: Maven 2 Issue Type: New Feature Components: Plugins and Lifecycle, POM Affects Versions: 2.0-beta-3 Environment: Windows Reporter: Alexandre Vivien Fix For: 3.x In the maven 2.0-beta-3 release we can't list more than one goal in the defaultGoal of the POM. For example, this : defaultGoalclean:clean install/defaultGoal doesn't work. It can be useful to add this feature in the maven 2.0 final release. Thanks. Alexandre Vivien -- 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-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163906#action_163906
]
Torben S. Giesselmann commented on MNG-3719:
Since the patch won't make it into 2.0.10, the documentation at
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
should be updated in the meantime. To avoid any confusion, it should be
mentioned that there's a problem. Or remove the comment altogether or change it
to As of 2.0.11.
[regression] plugin execution ordering no longer POM ordered in 2.0.9
-
Key: MNG-3719
URL: http://jira.codehaus.org/browse/MNG-3719
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
Environment: Maven 2.0.9, java version 1.5.0_13 Java(TM) 2 Runtime
Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
Reporter: Gary S. Weaver
Priority: Critical
Fix For: 2.0.11, 2.1.0-M2
Attachments: MNG-3719-maven-project.patch,
plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
I extend my sincere apologies if there is a much easier way of doing this,
but so far I haven't found any.
There should be some way to ensure order of plugin executions through
dependencies on other executions. See attached project for example, or see
below for the applicable example in a pom.xml. When plugins are defined in
pom.xml in the following manner to ensure correct execution order, they are
not executed sequentially and there is no way to indicate dependencies, as
would be expected (note- I'm not expecting that it interpret the step 1...,
..., step 5... IDs, I'm only suggesting that either the plugins be executed
in order that they are found in the XML (most intuitive) or that there be
some concept of priority/ordinal added, or even perhaps (this would be most
ant-like) that plugin executions (and maybe even plugin goal executions) be
allowed to define prequisite execution IDs to be run (even if they are IDs
not defined in the pom, but maybe a parent pom, even though I don't need that
right now).
I know that this could be problematic if a plugin execution from one
lifecycle phase depends on another from another lifecycle phase (and you
could get into circular references that way that would have to be recognized
during pom validation after loading/merging pom.xmls). However, not being
able to at the very least define order of execution of different (or the
same) plugin executions as noted below and in attached project makes it
difficult to chain plugin executions that depend on each other, thereby
reducing the practicality of the pom.xml and Maven 2.
For example, these plugin executions cannot be ordered properly in Maven
2.0.9, since there appears to be no way to indicate dependencies of one
execution on another:
{code}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
!-- backup original source web.xml in preparation for
chaining of plugin modifications to it --
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idstep 1 - backup-original-web.xml-from-src/id
phasegenerate-resources/phase
goals
goalrun/goal
/goals
configuration
tasks
mkdir dir=${pom.basedir}/target/
mkdir dir=${pom.basedir}/target/tmpwebxml/
copy
file=${pom.basedir}/src/main/webapp/WEB-INF/web.xml
todir=${pom.basedir}/target/tmpwebxml//
/tasks
/configuration
/execution
/executions
/plugin
plugin
!-- this plugin converts to
${basedir}/src/main/webapp/WEB-INF/web.xml to ${basedir}/target/jspweb.xml --
groupIdorg.codehaus.mojo/groupId
artifactIdjspc-maven-plugin/artifactId
executions
execution
idstep 2 - jspc/id
phasegenerate-resources/phase
goals
[jira] Created: (MSHARED-92) Cannot retreive FileNameMapper with MapperUtil
Cannot retreive FileNameMapper with MapperUtil
--
Key: MSHARED-92
URL: http://jira.codehaus.org/browse/MSHARED-92
Project: Maven Shared Components
Issue Type: Bug
Components: file-management
Affects Versions: file-management 1.2.1
Environment: any
Reporter: jerome creignou
Attachments: file-management.patch
I'm trying to use file name mappers inside a maven plugin with the
file-management shared project.
I've added a fileset definition in the plugin's configuration as follow :
plugin
groupIdinfo.flex-mojos/groupId
artifactIdflex-compiler-mojo/artifactId
extensionstrue/extensions
version2.0M11-SNAPSHOT/version
configuration
includeSources
param${basedir}/src/param
/includeSources
targetPlayer9.0.28/targetPlayer
fileset
directory${basedir}/src/directory
includes
include**/*.mxml/include
/includes
mapper
typeflatten/type
/mapper
/fileset
/configuration
/plugin
Unfortunately, I get a NPE while trying to retrieve my mapper :
java.lang.NullPointerException
at
org.apache.maven.shared.model.fileset.mappers.MapperUtil.getFileNameMapper(MapperUtil.java:114)
at
info.rvin.mojo.flexmojo.compiler.ApplicationMojo.setUp(ApplicationMojo.java:194)
at
info.rvin.mojo.flexmojo.AbstractIrvinMojo.execute(AbstractIrvinMojo.java:178)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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: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)
I've checked current trunk on shared/file-management, it seems that the
initializeBuiltIns call should initialize implementations but it does not.
I have enclosed a trivial patch which should fix 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: (MNG-3999) validation of Id's too restrictive
[ http://jira.codehaus.org/browse/MNG-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3999. - Assignee: Brett Porter Resolution: Won't Fix validation of Id's too restrictive -- Key: MNG-3999 URL: http://jira.codehaus.org/browse/MNG-3999 Project: Maven 2 Issue Type: Improvement Components: POM Environment: xp, SAP NetWeaver, maven 2.x Reporter: Sven Pressler Assignee: Brett Porter Attachments: pom.xml I guess the validation of the Id's were introduced after issue MNG-801. I think the validation is too strong. The problem is that a lot of valid filenames are not validated as true. The problem is caused by the DefaultModelValidator: private static final String ID_REGEX = [A-Za-z0-9_\\-.]+; This regular expression is far too restrictive since something like x=+%$§~!#^.jar would be a valid filename on a windows operating system I stumbled upon this because I'm developing tools for SAP NetWeaver, currently we still use maven 1 to build our projects but we're in the process of upgrading to maven 2. maven 1 doesn't have this problem, since Id's didn't get validated like that. Problem is SAP have a lot of libraries that have '~' in their names, like 'tc~epbc~pcm~adminapi~java-5.x.y.jar'. Doesn't look any good, I don't like it, I didn't make it like that but I have to work with it. Maybe someone can explain why it's a good idea to be that restrictive about the Ids, but as far as I see it, it's more like: before MNG-801 there was no validation, and after MNG-801 there was some validation, and until now, there was not too much complaining about it. Attached is a pom which produces the following when trying to run mvn install: Project ID: group:com~company~my~project Validation Messages: [0] 'artifactId' with value 'com~company~my~project' does not match a valid id pattern. Reason: Failed to validate POM for project group:com~company~my~project at C:\test\validate\pom.xml [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for project group:com~company~my~project at C:\test\validate\pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:324) 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.project.InvalidProjectModelException: Failed to validate POM for project group:com~company~my~project at C:\test\validate\pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) ... 11 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] Updated: (MNG-3803) [regression] System properties not working any more
[
http://jira.codehaus.org/browse/MNG-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3803:
--
Fix Version/s: (was: 3.0-alpha-4)
3.0-alpha-3
[regression] System properties not working any more
---
Key: MNG-3803
URL: http://jira.codehaus.org/browse/MNG-3803
Project: Maven 2
Issue Type: Bug
Affects Versions: 3.0-alpha-1
Reporter: Amélie Deltour
Assignee: Shane Isbell
Priority: Minor
Fix For: 3.0-alpha-3
Passing system properties to surefire-plugin used to work fine with Maven
2.0.9:
{code:xml}
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
systemProperties
property
namemy.property/name
valuemy.value/value
/property
/systemProperties
/configuration
/plugin
{code}
Now I use Maven 2.1-SNAPSHOT as Embedder launched with m2eclipse.
The properties are not defined any more.
In the logs with Maven 2.0.9 in debug mode I see:
[DEBUG] Setting system property [my.property]=[my.value]
This line is not present in the logs with Maven 2.1.
This compatibility issue is quite annoying...
--
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-1957) jdk/jdk clause in the activation section has to provide more complex expressions.
[ http://jira.codehaus.org/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1957: -- Fix Version/s: (was: 2.0.11) jdk/jdk clause in the activation section has to provide more complex expressions. - Key: MNG-1957 URL: http://jira.codehaus.org/browse/MNG-1957 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0, 2.0.1 Reporter: Trustin Lee Fix For: 2.1.0-M2 Attachments: MNG-1957-maven-project.patch For now, jdk/jdk provides only one operator '!' which means negation, but it would be great if i can use '+' and ~ operator: jdk1.5+/jdk !-- this will be activated when the current JDK version is 1.5 or above (e.g. 1.6) -- jdk1.1 ~ 1.4/jdk !-- this will be activated when the current JDK version is between 1.1 and 1.4 -- jdk~ 1.3/jdk !-- this will be activated when the current JDK version is 1.3 or below -- jdk1.4 ~/jdk. !-- the same with 1.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: (MNG-3803) [regression] System properties not working any more
[
http://jira.codehaus.org/browse/MNG-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell closed MNG-3803.
-
Resolution: Fixed
[regression] System properties not working any more
---
Key: MNG-3803
URL: http://jira.codehaus.org/browse/MNG-3803
Project: Maven 2
Issue Type: Bug
Affects Versions: 3.0-alpha-1
Reporter: Amélie Deltour
Assignee: Shane Isbell
Priority: Minor
Fix For: 3.0-alpha-3
Passing system properties to surefire-plugin used to work fine with Maven
2.0.9:
{code:xml}
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
systemProperties
property
namemy.property/name
valuemy.value/value
/property
/systemProperties
/configuration
/plugin
{code}
Now I use Maven 2.1-SNAPSHOT as Embedder launched with m2eclipse.
The properties are not defined any more.
In the logs with Maven 2.0.9 in debug mode I see:
[DEBUG] Setting system property [my.property]=[my.value]
This line is not present in the logs with Maven 2.1.
This compatibility issue is quite annoying...
--
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-3600) remove default settings of 664 / 775 for permissions
[ http://jira.codehaus.org/browse/MNG-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3600. - Assignee: Brett Porter Resolution: Fixed remove default settings of 664 / 775 for permissions Key: MNG-3600 URL: http://jira.codehaus.org/browse/MNG-3600 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.9 Reporter: Brett Porter Assignee: Brett Porter Fix For: 2.1.0-M2 setting this makes it impossible to have no setting, that is, to trust the umask on the server. This also means that if files on the server are not owned by the user, deploy fails because the mode can't be set. wagon 1.0-beta-3 has fixed a number of long standing issues with file permission setting using scp that were part of the impetus for this change, though it proved ineffectual in the end. -- 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: (MERCURY-83) repository metadata should be excluded from signature generation and checks
repository metadata should be excluded from signature generation and checks --- Key: MERCURY-83 URL: http://jira.codehaus.org/browse/MERCURY-83 Project: Mercury Issue Type: Bug Components: Transport Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov -- 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-1957) jdk/jdk clause in the activation section has to provide more complex expressions.
[ http://jira.codehaus.org/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163914#action_163914 ] Brett Porter commented on MNG-1957: --- applied, thanks! I made one modification - ! is not valid for ranges. I think per the thread on dev@ this is a bit confusing - best to be range or nothing. I added some tests, but still have an IT and docs to add before closing it out (more patches welcome :) jdk/jdk clause in the activation section has to provide more complex expressions. - Key: MNG-1957 URL: http://jira.codehaus.org/browse/MNG-1957 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0, 2.0.1 Reporter: Trustin Lee Fix For: 2.1.0-M2 Attachments: MNG-1957-maven-project.patch For now, jdk/jdk provides only one operator '!' which means negation, but it would be great if i can use '+' and ~ operator: jdk1.5+/jdk !-- this will be activated when the current JDK version is 1.5 or above (e.g. 1.6) -- jdk1.1 ~ 1.4/jdk !-- this will be activated when the current JDK version is between 1.1 and 1.4 -- jdk~ 1.3/jdk !-- this will be activated when the current JDK version is 1.3 or below -- jdk1.4 ~/jdk. !-- the same with 1.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] Commented: (MNG-1144) List 2 or more maven goals in the defaultGoal of the POM.
[ http://jira.codehaus.org/browse/MNG-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163880#action_163880 ] Gabriele Columbro commented on MNG-1144: How tough will it be to add it to 2.0.x or 2.1.x releases? As it will make a real nice improvement in controlling behavior of the build using just profiles. Thanks! List 2 or more maven goals in the defaultGoal of the POM. --- Key: MNG-1144 URL: http://jira.codehaus.org/browse/MNG-1144 Project: Maven 2 Issue Type: New Feature Components: Plugins and Lifecycle, POM Affects Versions: 2.0-beta-3 Environment: Windows Reporter: Alexandre Vivien Fix For: 3.x In the maven 2.0-beta-3 release we can't list more than one goal in the defaultGoal of the POM. For example, this : defaultGoalclean:clean install/defaultGoal doesn't work. It can be useful to add this feature in the maven 2.0 final release. Thanks. Alexandre Vivien -- 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-1957) jdk/jdk clause in the activation section has to provide more complex expressions.
[ http://jira.codehaus.org/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163889#action_163889 ] Brett Porter commented on MNG-1957: --- Joerg - you are correct, and this needs to be worked into the toolchains implementation. As it stands, however, this change seems like an improvement to the existing logic. jdk/jdk clause in the activation section has to provide more complex expressions. - Key: MNG-1957 URL: http://jira.codehaus.org/browse/MNG-1957 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0, 2.0.1 Reporter: Trustin Lee Fix For: 2.0.11, 2.1.0-M2 Attachments: MNG-1957-maven-project.patch For now, jdk/jdk provides only one operator '!' which means negation, but it would be great if i can use '+' and ~ operator: jdk1.5+/jdk !-- this will be activated when the current JDK version is 1.5 or above (e.g. 1.6) -- jdk1.1 ~ 1.4/jdk !-- this will be activated when the current JDK version is between 1.1 and 1.4 -- jdk~ 1.3/jdk !-- this will be activated when the current JDK version is 1.3 or below -- jdk1.4 ~/jdk. !-- the same with 1.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: (MNG-4019) Unrecognised association exclude in pom parsing resourcedirectoryexcludes in 2.0.10-RC10
[ http://jira.codehaus.org/browse/MNG-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4019. - Assignee: Benjamin Bentmann Resolution: Not A Bug Unrecognised association exclude in pom parsing resourcedirectoryexcludes in 2.0.10-RC10 Key: MNG-4019 URL: http://jira.codehaus.org/browse/MNG-4019 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.10 Environment: XP SP3, Java 1.5.0_12-b04, Maven 2.0.10-RC10 2/1/09. Reporter: Bob Fields Assignee: Benjamin Bentmann Priority: Critical Attachments: 209Debug.log, 210Debug.log, pom.xml, pom.xml Fails in Maven 2.0.10-RC10, works in 2.0.8 and 2.0.9. pom.xml containing the following: resources resource directorysrc/java/directory excludes exclude**/*.java/exclude /excludes /resource Fails with: org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. Reason: Unrecognised association: 'excludes' (position: START_TAG seen ...excludes\ excludes... @138:31) for project unknown:andromda-metafacades-uml at C:\workspaces\A34\andromda34\metafacades\uml\pom.xml Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error reading POM. Reason: Unrecognised association: 'excludes' (position: START_TAG seen ...excludes\r\nexcludes... @138:31) for project unknown:andromda-metafacades-uml at C:\workspaces\A34\andromda34\metafacades\uml\pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1591) Not sure if this is related to http://jira.codehaus.org/browse/MNG-3680 pom.xml and mvn -X output from 2.0.9 and 2.0.10 attached. Pom file is from AndroMDA: http://team.andromda.org/docs/source-repository.html under directory metafacades\uml. -- 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-2668) Plugin dependencies should be considered when the reactor creates the build order list
[ http://jira.codehaus.org/browse/MNG-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2668. - Assignee: Brett Porter Resolution: Fixed Plugin dependencies should be considered when the reactor creates the build order list -- Key: MNG-2668 URL: http://jira.codehaus.org/browse/MNG-2668 Project: Maven 2 Issue Type: Bug Components: Reactor and workspace Affects Versions: 2.0.4 Reporter: Vincent Massol Assignee: Brett Porter Fix For: 2.1.0-M2 Attachments: MNG-2668-maven-project.patch, MNG-2668-maven-project.patch In one project, I am using the checkstyle plugin with a plugin dependency on a build-tools module that produces a jar. Maven doesn't recognize that this build-tools module must be built before the module using the checkstyle plugin which has this dependency. -- 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-4021) Multi-project site navigation suddenly broken
Multi-project site navigation suddenly broken - Key: MNG-4021 URL: http://jira.codehaus.org/browse/MNG-4021 Project: Maven 2 Issue Type: Bug Components: Sites Reporting Reporter: Howard M. Lewis Ship Not exactly sure when this started, but the generated site navigation for my multiproject site is broken; sub-modules now use the same navigation links as the master project ... thus per-module files are inaccessible and many links are broken., See http://tapestry.formos.com/nightly/tapestry5 for an example. Using maven-site-plugin verson 2.0-beta-6. It seems to work correctly if I downgrade to 2.0-beta-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] Commented: (MNG-4021) Multi-project site navigation suddenly broken
[ http://jira.codehaus.org/browse/MNG-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163945#action_163945 ] Howard M. Lewis Ship commented on MNG-4021: --- You can't see it now because I did in fact downgrade to beta-5 and rebuild, sorry. Multi-project site navigation suddenly broken - Key: MNG-4021 URL: http://jira.codehaus.org/browse/MNG-4021 Project: Maven 2 Issue Type: Bug Components: Sites Reporting Reporter: Howard M. Lewis Ship Not exactly sure when this started, but the generated site navigation for my multiproject site is broken; sub-modules now use the same navigation links as the master project ... thus per-module files are inaccessible and many links are broken., See http://tapestry.formos.com/nightly/tapestry5 for an example. Using maven-site-plugin verson 2.0-beta-6. It seems to work correctly if I downgrade to 2.0-beta-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] Moved: (MSITE-381) Multi-project site navigation suddenly broken
[ http://jira.codehaus.org/browse/MSITE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MNG-4021 to MSITE-381: -- Component/s: (was: Sites Reporting) inheritance Key: MSITE-381 (was: MNG-4021) Project: Maven 2.x Site Plugin (was: Maven 2) Multi-project site navigation suddenly broken - Key: MSITE-381 URL: http://jira.codehaus.org/browse/MSITE-381 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-6 Reporter: Howard M. Lewis Ship Not exactly sure when this started, but the generated site navigation for my multiproject site is broken; sub-modules now use the same navigation links as the master project ... thus per-module files are inaccessible and many links are broken., See http://tapestry.formos.com/nightly/tapestry5 for an example. Using maven-site-plugin verson 2.0-beta-6. It seems to work correctly if I downgrade to 2.0-beta-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] Updated: (MSITE-381) Multi-project site navigation suddenly broken
[ http://jira.codehaus.org/browse/MSITE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MSITE-381: Affects Version/s: 2.0-beta-6 Multi-project site navigation suddenly broken - Key: MSITE-381 URL: http://jira.codehaus.org/browse/MSITE-381 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-6 Reporter: Howard M. Lewis Ship Not exactly sure when this started, but the generated site navigation for my multiproject site is broken; sub-modules now use the same navigation links as the master project ... thus per-module files are inaccessible and many links are broken., See http://tapestry.formos.com/nightly/tapestry5 for an example. Using maven-site-plugin verson 2.0-beta-6. It seems to work correctly if I downgrade to 2.0-beta-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] Commented: (MSITE-381) Multi-project site navigation suddenly broken
[ http://jira.codehaus.org/browse/MSITE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163950#action_163950 ] Benjamin Bentmann commented on MSITE-381: - The latest release of the Site Plugin is 2.0-beta-7, might be worth a try. Multi-project site navigation suddenly broken - Key: MSITE-381 URL: http://jira.codehaus.org/browse/MSITE-381 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-6 Reporter: Howard M. Lewis Ship Not exactly sure when this started, but the generated site navigation for my multiproject site is broken; sub-modules now use the same navigation links as the master project ... thus per-module files are inaccessible and many links are broken., See http://tapestry.formos.com/nightly/tapestry5 for an example. Using maven-site-plugin verson 2.0-beta-6. It seems to work correctly if I downgrade to 2.0-beta-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: (MJAVADOC-225) The plugin should be able to generate a jar of the aggregated javadoc
The plugin should be able to generate a jar of the aggregated javadoc - Key: MJAVADOC-225 URL: http://jira.codehaus.org/browse/MJAVADOC-225 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Affects Versions: 2.5 Environment: Windows Reporter: Todd Thiessen Priority: Minor The javadoc:jar goal does not jar the aggregated java in a multi-module project. It would be really nice if it did. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2261) Automatic upload of mockito versions.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Brakkee closed MAVENUPLOAD-2261. - Resolution: Fixed The problems appears to be corrected now as I am seeing daily rsyncs in the server logs. Automatic upload of mockito versions. - Key: MAVENUPLOAD-2261 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2261 Project: Maven Upload Requests Issue Type: Wish Reporter: Erik Brakkee Assignee: Carlos Sanchez Authenticity = Please contact Szczepan Faber for information about the authenticity of this request. He is the owner of the mockito.org domain. Also, my name will appear shortly on the mockito wiki at http://code.google.com/p/mockito/. -- 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-1910) Allow jdk 1.4+ as profile requirement
[ http://jira.codehaus.org/browse/MNG-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-1910: --- Fix Version/s: (was: 2.0.7) 3.0-alpha-1 Allow jdk 1.4+ as profile requirement - Key: MNG-1910 URL: http://jira.codehaus.org/browse/MNG-1910 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0.1 Reporter: Jochen Wiedmann Fix For: 3.0-alpha-1 Attachments: jdk_plus.patch, jdk_plus.patch The jdk element in the POM allows for strings like 1.5, or !1.4 only. It would be desirable to use 1.4+, or something similar. The attached patch serves that purpose. A patch for the docs is missing. I am ready to create such a patch as well, if I know that my idea would be accepted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2346) Upload appframework and swinghelper-debug
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163972#action_163972 ] Julien HENRY commented on MAVENUPLOAD-2346: --- Could you please join the Javadoc and the sources for appframework. Thanks Upload appframework and swinghelper-debug - Key: MAVENUPLOAD-2346 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2346 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexandre Navarro Attachments: appframework-1.03-bundle.jar, swinghelper-debug-1.0-bundle.jar Alexandre Navarro a contributor of theses 2 projects, contributor on fest and developer on JavaBuilder and SwingJavaBuilder where we need theses jars. Alexander Potochkin and Hans Muller (https://swinghelper.dev.java.net/ and https://appframework.dev.java.net/), main developers on theses 2 projects. Thanks, 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] Issue Comment Edited: (MAVENUPLOAD-2346) Upload appframework and swinghelper-debug
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163972#action_163972 ] Julien HENRY edited comment on MAVENUPLOAD-2346 at 2/4/09 1:47 PM: --- Could you please join the Javadoc and the sources for appframework. Also I get the following exception when using this class (JDK 1.6): java.lang.ClassNotFoundException: org.jdesktop.swingworker.SwingWorker I know there is a SwingWorker since JDK 1.6 but if you are using an other one, you should add it as a dependency in your pom and ask to upload it also. Thanks was (Author: henryju): Could you please join the Javadoc and the sources for appframework. Thanks Upload appframework and swinghelper-debug - Key: MAVENUPLOAD-2346 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2346 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexandre Navarro Attachments: appframework-1.03-bundle.jar, swinghelper-debug-1.0-bundle.jar Alexandre Navarro a contributor of theses 2 projects, contributor on fest and developer on JavaBuilder and SwingJavaBuilder where we need theses jars. Alexander Potochkin and Hans Muller (https://swinghelper.dev.java.net/ and https://appframework.dev.java.net/), main developers on theses 2 projects. Thanks, 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] Work started: (MSHARED-92) Cannot retreive FileNameMapper with MapperUtil
[
http://jira.codehaus.org/browse/MSHARED-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MSHARED-92 started by Petar Tahchiev.
Cannot retreive FileNameMapper with MapperUtil
--
Key: MSHARED-92
URL: http://jira.codehaus.org/browse/MSHARED-92
Project: Maven Shared Components
Issue Type: Bug
Components: file-management
Affects Versions: file-management 1.2.1
Environment: any
Reporter: jerome creignou
Assignee: Petar Tahchiev
Attachments: file-management.patch
I'm trying to use file name mappers inside a maven plugin with the
file-management shared project.
I've added a fileset definition in the plugin's configuration as follow :
plugin
groupIdinfo.flex-mojos/groupId
artifactIdflex-compiler-mojo/artifactId
extensionstrue/extensions
version2.0M11-SNAPSHOT/version
configuration
includeSources
param${basedir}/src/param
/includeSources
targetPlayer9.0.28/targetPlayer
fileset
directory${basedir}/src/directory
includes
include**/*.mxml/include
/includes
mapper
typeflatten/type
/mapper
/fileset
/configuration
/plugin
Unfortunately, I get a NPE while trying to retrieve my mapper :
java.lang.NullPointerException
at
org.apache.maven.shared.model.fileset.mappers.MapperUtil.getFileNameMapper(MapperUtil.java:114)
at
info.rvin.mojo.flexmojo.compiler.ApplicationMojo.setUp(ApplicationMojo.java:194)
at
info.rvin.mojo.flexmojo.AbstractIrvinMojo.execute(AbstractIrvinMojo.java:178)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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: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)
I've checked current trunk on shared/file-management, it seems that the
initializeBuiltIns call should initialize implementations but it does not.
I have enclosed a trivial patch which should fix 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] Work stopped: (MSHARED-92) Cannot retreive FileNameMapper with MapperUtil
[
http://jira.codehaus.org/browse/MSHARED-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MSHARED-92 stopped by Petar Tahchiev.
Cannot retreive FileNameMapper with MapperUtil
--
Key: MSHARED-92
URL: http://jira.codehaus.org/browse/MSHARED-92
Project: Maven Shared Components
Issue Type: Bug
Components: file-management
Affects Versions: file-management 1.2.1
Environment: any
Reporter: jerome creignou
Assignee: Petar Tahchiev
Attachments: file-management.patch
I'm trying to use file name mappers inside a maven plugin with the
file-management shared project.
I've added a fileset definition in the plugin's configuration as follow :
plugin
groupIdinfo.flex-mojos/groupId
artifactIdflex-compiler-mojo/artifactId
extensionstrue/extensions
version2.0M11-SNAPSHOT/version
configuration
includeSources
param${basedir}/src/param
/includeSources
targetPlayer9.0.28/targetPlayer
fileset
directory${basedir}/src/directory
includes
include**/*.mxml/include
/includes
mapper
typeflatten/type
/mapper
/fileset
/configuration
/plugin
Unfortunately, I get a NPE while trying to retrieve my mapper :
java.lang.NullPointerException
at
org.apache.maven.shared.model.fileset.mappers.MapperUtil.getFileNameMapper(MapperUtil.java:114)
at
info.rvin.mojo.flexmojo.compiler.ApplicationMojo.setUp(ApplicationMojo.java:194)
at
info.rvin.mojo.flexmojo.AbstractIrvinMojo.execute(AbstractIrvinMojo.java:178)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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: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)
I've checked current trunk on shared/file-management, it seems that the
initializeBuiltIns call should initialize implementations but it does not.
I have enclosed a trivial patch which should fix 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: (MSHARED-92) Cannot retreive FileNameMapper with MapperUtil
[
http://jira.codehaus.org/browse/MSHARED-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petar Tahchiev closed MSHARED-92.
-
Resolution: Fixed
Fix Version/s: fiile-managment 1.2.2
The patch is applied in the trunk. Once again thanks.
Cannot retreive FileNameMapper with MapperUtil
--
Key: MSHARED-92
URL: http://jira.codehaus.org/browse/MSHARED-92
Project: Maven Shared Components
Issue Type: Bug
Components: file-management
Affects Versions: file-management 1.2.1
Environment: any
Reporter: jerome creignou
Assignee: Petar Tahchiev
Fix For: fiile-managment 1.2.2
Attachments: file-management.patch
I'm trying to use file name mappers inside a maven plugin with the
file-management shared project.
I've added a fileset definition in the plugin's configuration as follow :
plugin
groupIdinfo.flex-mojos/groupId
artifactIdflex-compiler-mojo/artifactId
extensionstrue/extensions
version2.0M11-SNAPSHOT/version
configuration
includeSources
param${basedir}/src/param
/includeSources
targetPlayer9.0.28/targetPlayer
fileset
directory${basedir}/src/directory
includes
include**/*.mxml/include
/includes
mapper
typeflatten/type
/mapper
/fileset
/configuration
/plugin
Unfortunately, I get a NPE while trying to retrieve my mapper :
java.lang.NullPointerException
at
org.apache.maven.shared.model.fileset.mappers.MapperUtil.getFileNameMapper(MapperUtil.java:114)
at
info.rvin.mojo.flexmojo.compiler.ApplicationMojo.setUp(ApplicationMojo.java:194)
at
info.rvin.mojo.flexmojo.AbstractIrvinMojo.execute(AbstractIrvinMojo.java:178)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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: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)
I've checked current trunk on shared/file-management, it seems that the
initializeBuiltIns call should initialize implementations but it does not.
I have enclosed a trivial patch which should fix 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: (MNG-3832) Allow wildcards in dependency exclusions
[
http://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163978#action_163978
]
Kyle Lebel commented on MNG-3832:
-
I would like to see this as well, any news on this topic?
Allow wildcards in dependency exclusions
Key: MNG-3832
URL: http://jira.codehaus.org/browse/MNG-3832
Project: Maven 2
Issue Type: New Feature
Components: Dependencies
Reporter: Paul Gier
Fix For: 2.x
I would like to be able to exclude all transitive dependencies from a certain
dependencies. This is especially useful when depending on an artifact with a
classifier that may not have the same dependencies as the main artifact.
Currently the only way to do this is by excluding each dependency
individually which requires significant effort and is prone to becoming out
of date. The following syntax is one possibility.
Exclude all transitive dependencies
{code}
exclusion
groupId*/groupId
/exclusion
{code}
Exclude transitive dependencies with the groupId org.company
{code}
exclusion
groupIdorg.company/groupId
artifactId*/artifactId
/exclusion
{code}
--
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: (MASSEMBLY-115) Should avoid modifying assembly if none of the underlying files have changed.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163982#action_163982 ] Petar Tahchiev commented on MASSEMBLY-115: -- All of the plexus archivers implement the Archiver interface, which has the setForce method defined. We simply call the delegate.setForced(forced); method on the delegate Archiver interface object. I think update functionality should work for all the archivers, since they implement the setForce method. And if it doesn't work for any of those then it should be a problem of the given archiver. And in this case we will fallback and support only forced (non-update) creation of archives for that archiver. Should avoid modifying assembly if none of the underlying files have changed. - Key: MASSEMBLY-115 URL: http://jira.codehaus.org/browse/MASSEMBLY-115 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: David Boden Assignee: Petar Tahchiev Fix For: 2.3-beta-1 Attachments: massembly-115.patch At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed. This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a clean has taken place. It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed. Adding an assembly to a build currently slows down the iterative install build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every 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: (MERCURY-84) repository does not write SN version into GA metadata
repository does not write SN version into GA metadata - Key: MERCURY-84 URL: http://jira.codehaus.org/browse/MERCURY-84 Project: Mercury Issue Type: Bug Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov write a TS or SN into a repository, it does not show up in GA-level metadata -- 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: (MASSEMBLY-115) Should avoid modifying assembly if none of the underlying files have changed.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163984#action_163984 ] John Casey commented on MASSEMBLY-115: -- Testing whether the forcing actually works on individual archivers (especially tar.gz, tar.bz2, tar, zip, jar, etcthe main ones in use) is exactly what I meant. I'm not at all certain or willing to bet that those archiver implementations are doing the right thing WRT forcing. We've had too many problems with features that are outside the mainstream in plexus-archiver historically for me to think they already work. Call me a skeptic, but I'd much rather see tests for those archivers before we claim that this is working for the assembly plugin. I've been bitten too many times doing that. Should avoid modifying assembly if none of the underlying files have changed. - Key: MASSEMBLY-115 URL: http://jira.codehaus.org/browse/MASSEMBLY-115 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: David Boden Assignee: Petar Tahchiev Fix For: 2.3-beta-1 Attachments: massembly-115.patch At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed. This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a clean has taken place. It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed. Adding an assembly to a build currently slows down the iterative install build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-225) The plugin should be able to generate a jar of the aggregated javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163987#action_163987 ] Todd Thiessen commented on MJAVADOC-225: You can jar the aggregated javadocs yourself. In your parent POM, declare the following descriptor file: assembly idaggregated-javadoc/id formats formatjar/format /formats includeBaseDirectoryfalse/includeBaseDirectory moduleSets moduleSet includeSubModulesfalse/includeSubModules /moduleSet /moduleSets fileSets fileSet directorytarget/site/apidocs/directory /fileSet /fileSets /assembly I saved this in src/assemble/assembleAggregatedJavadoc.xml Then add the assembly plugin to your POM with this configuration: plugin inheritedfalse/inherited groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.2-beta-3/version executions execution idjar-aggregated-javadoc/id phasepackage/phase configuration descriptors descriptorsrc/assemble/assembleAggregatedJavadoc.xml/descriptor /descriptors /configuration goals goalsingle/goal /goals /execution /executions /plugin The plugin should be able to generate a jar of the aggregated javadoc - Key: MJAVADOC-225 URL: http://jira.codehaus.org/browse/MJAVADOC-225 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Affects Versions: 2.5 Environment: Windows Reporter: Todd Thiessen Priority: Minor The javadoc:jar goal does not jar the aggregated java in a multi-module project. It would be really nice if it did. -- 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: (MJAVADOC-225) The plugin should be able to generate a jar of the aggregated javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163988#action_163988 ] Todd Thiessen commented on MJAVADOC-225: Note. The assembly plugin added to the parent pom of your multi-module project. The plugin should be able to generate a jar of the aggregated javadoc - Key: MJAVADOC-225 URL: http://jira.codehaus.org/browse/MJAVADOC-225 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Affects Versions: 2.5 Environment: Windows Reporter: Todd Thiessen Priority: Minor The javadoc:jar goal does not jar the aggregated java in a multi-module project. It would be really nice if it did. -- 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: (MERCURY-83) repository metadata should be excluded from signature generation and checks
[ http://jira.codehaus.org/browse/MERCURY-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-83: Fix Version/s: 1.0-alpha-5 repository metadata should be excluded from signature generation and checks --- Key: MERCURY-83 URL: http://jira.codehaus.org/browse/MERCURY-83 Project: Mercury Issue Type: Bug Components: Transport Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-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: (MNG-1957) jdk/jdk clause in the activation section has to provide more complex expressions.
[ http://jira.codehaus.org/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1957. - Assignee: Brett Porter Resolution: Fixed closing as done - we may need to revisit depending on current dev@ discussion about whether to support ranges, or MNG-1910's syntax of 1.4+ jdk/jdk clause in the activation section has to provide more complex expressions. - Key: MNG-1957 URL: http://jira.codehaus.org/browse/MNG-1957 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0, 2.0.1 Reporter: Trustin Lee Assignee: Brett Porter Fix For: 2.1.0-M2 Attachments: MNG-1957-maven-project.patch For now, jdk/jdk provides only one operator '!' which means negation, but it would be great if i can use '+' and ~ operator: jdk1.5+/jdk !-- this will be activated when the current JDK version is 1.5 or above (e.g. 1.6) -- jdk1.1 ~ 1.4/jdk !-- this will be activated when the current JDK version is between 1.1 and 1.4 -- jdk~ 1.3/jdk !-- this will be activated when the current JDK version is 1.3 or below -- jdk1.4 ~/jdk. !-- the same with 1.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: (MERCURY-85) VirtualRepo UTs depend on external URL
VirtualRepo UTs depend on external URL -- Key: MERCURY-85 URL: http://jira.codehaus.org/browse/MERCURY-85 Project: Mercury Issue Type: Bug Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 Bring it inside -- 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: (MERCURY-85) VirtualRepo UTs depend on external URL
[ http://jira.codehaus.org/browse/MERCURY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-85: Fix Version/s: 1.0-alpha-5 VirtualRepo UTs depend on external URL -- Key: MERCURY-85 URL: http://jira.codehaus.org/browse/MERCURY-85 Project: Mercury Issue Type: Bug Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 Bring it inside -- 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: (MERCURY-86) remote repository presumes GAV metadata to contain versions/ for all snapshots
[ http://jira.codehaus.org/browse/MERCURY-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-86: Fix Version/s: 1.0-alpha-5 remote repository presumes GAV metadata to contain versions/ for all snapshots Key: MERCURY-86 URL: http://jira.codehaus.org/browse/MERCURY-86 Project: Mercury Issue Type: Bug Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 This assumption is only valid for mercury-created metadata. Make it understand snapshot/ -- 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: (MERCURY-86) remote repository presumes GAV metadata to contain versions/ for all snapshots
remote repository presumes GAV metadata to contain versions/ for all snapshots Key: MERCURY-86 URL: http://jira.codehaus.org/browse/MERCURY-86 Project: Mercury Issue Type: Bug Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 This assumption is only valid for mercury-created metadata. Make it understand snapshot/ -- 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: (MERCURY-85) VirtualRepo UTs depend on external URL
[ http://jira.codehaus.org/browse/MERCURY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-85: Component/s: Repository VirtualRepo UTs depend on external URL -- Key: MERCURY-85 URL: http://jira.codehaus.org/browse/MERCURY-85 Project: Mercury Issue Type: Bug Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 Bring it inside -- 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: (MERCURY-61) ant tests fail on all grid nodes except for osx
[ http://jira.codehaus.org/browse/MERCURY-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-61: Component/s: Ant tasks ant tests fail on all grid nodes except for osx --- Key: MERCURY-61 URL: http://jira.codehaus.org/browse/MERCURY-61 Project: Mercury Issue Type: Bug Components: Ant tasks Reporter: Oleg Gusakov Assignee: Oleg Gusakov Priority: Blocker Fix For: 1.0-alpha-5 Attachments: ext-javac.patch, tools-jar.patch Original Estimate: 0 minutes Remaining Estimate: 0 minutes find out why ant test harness picks JRE instead of JDK and thus looses the compiler -- 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: (MERCURY-85) VirtualRepo UTs depend on external URL
[ http://jira.codehaus.org/browse/MERCURY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-85. --- Resolution: Fixed switched to embedded jetty VirtualRepo UTs depend on external URL -- Key: MERCURY-85 URL: http://jira.codehaus.org/browse/MERCURY-85 Project: Mercury Issue Type: Bug Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 Bring it inside -- 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: (MJAR-115) Provide Access to Undocumented Jarsigner -J Option for Increasing Heap
Provide Access to Undocumented Jarsigner -J Option for Increasing Heap -- Key: MJAR-115 URL: http://jira.codehaus.org/browse/MJAR-115 Project: Maven 2.x Jar Plugin Issue Type: Improvement Components: sign Affects Versions: 2.2 Environment: Mac 10.5.6, Windows XP SP3, Maven 2.0.9, Jar Plugin 2.2 Reporter: Matthew McCullough Priority: Minor Attachments: 0001-Adding-maximum-memory-option-to-jar-signing.patch I am signing very large JARs. I don't have the option (legally) of splitting the JAR into smaller pieces. One of them specifically is wl_fullclient.jar, the 64MB WebLogic JEE client JAR. I have found an undocumented option -J-Xmx to jarsigner that has accomplished what I need on Windows and Mac. It is used in the Ant equivalent jar signing task. The Ant Source can be viewed here on line 286 http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/AbstractJarSignerTask.java?view=markup -- 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-115) Provide Access to Undocumented Jarsigner -J Option for Increasing Heap
[ http://jira.codehaus.org/browse/MJAR-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew McCullough updated MJAR-115: Attachment: REVISED-0001-Adding-maximum-memory-option-to-jar-signing.patch Missed semicolon during creation of patch. Revised patch. Provide Access to Undocumented Jarsigner -J Option for Increasing Heap -- Key: MJAR-115 URL: http://jira.codehaus.org/browse/MJAR-115 Project: Maven 2.x Jar Plugin Issue Type: Improvement Components: sign Affects Versions: 2.2 Environment: Mac 10.5.6, Windows XP SP3, Maven 2.0.9, Jar Plugin 2.2 Reporter: Matthew McCullough Priority: Minor Attachments: 0001-Adding-maximum-memory-option-to-jar-signing.patch, REVISED-0001-Adding-maximum-memory-option-to-jar-signing.patch I am signing very large JARs. I don't have the option (legally) of splitting the JAR into smaller pieces. One of them specifically is wl_fullclient.jar, the 64MB WebLogic JEE client JAR. I have found an undocumented option -J-Xmx to jarsigner that has accomplished what I need on Windows and Mac. It is used in the Ant equivalent jar signing task. The Ant Source can be viewed here on line 286 http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/AbstractJarSignerTask.java?view=markup -- 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-4005) Throw Validation Error if pom contains a dependency with two different versions.
[ http://jira.codehaus.org/browse/MNG-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164051#action_164051 ] Shane Isbell commented on MNG-4005: --- Under the current implementation, this could only happen if the profiles is adding the dependency, the project builder itself will delete the second instance. Throw Validation Error if pom contains a dependency with two different versions. Key: MNG-4005 URL: http://jira.codehaus.org/browse/MNG-4005 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Affects Versions: 3.0-alpha-2 Reporter: Shane Isbell Assignee: Shane Isbell Fix For: 3.0-alpha-4 Throw a validation error if a pom contains the same dependency with two different versions. -- 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-3927) [regression] Configuration of custom plugin execution using default id pollutes configuration of default plugin executions introduced by packaging
[ http://jira.codehaus.org/browse/MNG-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell closed MNG-3927. - Resolution: Fixed [regression] Configuration of custom plugin execution using default id pollutes configuration of default plugin executions introduced by packaging -- Key: MNG-3927 URL: http://jira.codehaus.org/browse/MNG-3927 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 3.0-alpha-1 Reporter: Max Powers Assignee: Shane Isbell Fix For: 3.0-alpha-3 Attachments: pom.xml Seems that maven is allowing pom writers to define new values for parameters that a plugin has marked as readOnly. I have attached a pom that overrides the resources parameter in the maven-resources-plugin. This is allowed in 2.0.9, but fails (as it should) in 3.x (see line 89) I would've expected to see this error (as i do in 3.x) [ERROR] ERROR: Cannot override read-only parameter: resources in goal: resources:resources -- 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: (MERCURY-87) plexus test depends on external URL - convert to embedded Jetty
plexus test depends on external URL - convert to embedded Jetty --- Key: MERCURY-87 URL: http://jira.codehaus.org/browse/MERCURY-87 Project: Mercury Issue Type: Task Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-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] Updated: (MERCURY-87) plexus test depends on external URL - convert to embedded Jetty
[ http://jira.codehaus.org/browse/MERCURY-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-87: Fix Version/s: 1.0-alpha-5 plexus test depends on external URL - convert to embedded Jetty --- Key: MERCURY-87 URL: http://jira.codehaus.org/browse/MERCURY-87 Project: Mercury Issue Type: Task Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-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] Commented: (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ http://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164052#action_164052 ] Paul Benedict commented on MWAR-33: --- Alex, the workaround described above works. Simply exclude WEB-INF/lib and WEB-INF/classes from the war building. However, I concede this is a hack and expected the plugin to know better. jars with differents versions can be in WEB-INF/lib with war as dependencies Key: MWAR-33 URL: http://jira.codehaus.org/browse/MWAR-33 Project: Maven 2.x War Plugin Issue Type: Bug Environment: all Reporter: Olivier Lamy Assignee: Stephane Nicoll Fix For: 2.1 Attachments: MWAR-33-example.zip, MWAR-33-workaround.zip Original Estimate: 15 minutes Time Spent: 30 minutes Remaining Estimate: 0 minutes My pom has the following dependencies : - log4j:log4j:1.2.13 - a war with log4j:log4j:1.2.11 included Result the two jars are in WEB-INF/lib. -- 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: (MERCURY-87) plexus test depends on external URL - convert to embedded Jetty
[ http://jira.codehaus.org/browse/MERCURY-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-87. --- Resolution: Fixed fixed - replaced with embedded Jetty plexus test depends on external URL - convert to embedded Jetty --- Key: MERCURY-87 URL: http://jira.codehaus.org/browse/MERCURY-87 Project: Mercury Issue Type: Task Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-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] Reopened: (MERCURY-85) VirtualRepo UTs depend on external URL
[ http://jira.codehaus.org/browse/MERCURY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov reopened MERCURY-85: - UTs fail under Windows - looks like the same problem as with other tests: cannot clean repository between tests. Insert a delay? VirtualRepo UTs depend on external URL -- Key: MERCURY-85 URL: http://jira.codehaus.org/browse/MERCURY-85 Project: Mercury Issue Type: Bug Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 Bring it inside -- 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
