[jira] (MDEPLOY-154) Rewrite page 'deploy with classifier'
Robert Scholte created MDEPLOY-154: -- Summary: Rewrite page 'deploy with classifier' Key: MDEPLOY-154 URL: https://jira.codehaus.org/browse/MDEPLOY-154 Project: Maven 2.x and 3.x Deploy Plugin Issue Type: Improvement Affects Versions: 2.7 Reporter: Robert Scholte http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html is a bad example on how to use classifiers. Is should describe at least that they share the pom.xml with the 'main'-artifact. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-398) release:prepare: endlessly asking for the next development version on a multi-module project when not entering the expected value
[
https://jira.codehaus.org/browse/MRELEASE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-398:
Fix Version/s: 2.4
For MRELEASE-511 this part of the code will be refactored, so this issue should
be fixed as well.
release:prepare: endlessly asking for the next development version on a
multi-module project when not entering the expected value
-
Key: MRELEASE-398
URL: https://jira.codehaus.org/browse/MRELEASE-398
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-8
Environment: Maven 2.0.9
Windows XP SP3
JDK 1.6.0_11
Reporter: Thorsten Heit
Fix For: 2.4
Attachments: release-prepare-patch.txt
I'm working on a multi-module project that has dependencies to other modules
which were released recently. When trying to release my project,
release:prepare doesn't stop asking me for a dependency's next development
version as long as I'm entering a version string that doesn't equal the
expected one:
\\
{code}(...)
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve
them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project
Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
Resolve Project Dependency Snapshots.: 'de.ukv.verbund.base:verbund-base' set
to release? (yes/no) yes: :
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
2.0.0-SNAPSHOT
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
2.0.0-SNAPSHOT
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
2.0.0-SNAPSHOT
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
1.2.0-SNAPSHOT
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
'de.ukv.verbund.form:verbund-form' set to release? (yes/no) yes: :
(...){code}
(see also bugs MRELEASE-158 and MRELEASE-269)
The solution for that behaviour is quite easy; see attached patch.
Note: I've seen this only when the release plugin asks for new versions of
snapshot dependencies, not when asking for the new version of the project
itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-734) When releaseVersion and developmentVersion are passed in command-line but are empty should be treated as not-defined
[
https://jira.codehaus.org/browse/MRELEASE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-734:
Fix Version/s: 2.4
Assignee: Robert Scholte
For MRELEASE-511 this part of the code will be refactored, so this issue should
be fixed as well.
When releaseVersion and developmentVersion are passed in command-line but are
empty should be treated as not-defined
Key: MRELEASE-734
URL: https://jira.codehaus.org/browse/MRELEASE-734
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Affects Versions: 2.2.2
Reporter: Dmitry Katsubo
Assignee: Robert Scholte
Fix For: 2.4
In my case I would like to pass {{releaseVersion}} and {{developmentVersion}}
taken from user input, e.g. from [Hudson Release
Plugin|http://wiki.hudson-ci.org/display/HUDSON/Release+Plugin]:
{code}
release:prepare release:perform -DreleaseVersion=${RELEASE_VERSION}
-DdevelopmentVersion=${DEVELOPMENT_VERSION}
{code}
however if user leaves input fields empty it would be nice if
maven-release-plugin would treat empty values as non-defined and fallback to
default behaviour: inherit the next version from pom. Currently it breaks
down with message 'Unable to parse the version string '.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-511) release:prepare Error parsing version, cannot determine next version: Unable to parse the version string when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307113#comment-307113
]
Robert Scholte commented on MRELEASE-511:
-
Part one is done in
[r1377520|http://svn.apache.org/viewvc?rev=1377520view=rev]. I'll have to
check the comments on this issue and maybe add additional tests before closing
this issue.
release:prepare Error parsing version, cannot determine next version: Unable
to parse the version string when running in batch mode.
--
Key: MRELEASE-511
URL: https://jira.codehaus.org/browse/MRELEASE-511
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9
Environment: Win Xp Pro 64bit Java 1.6
Reporter: David Cloutier
Assignee: Robert Scholte
Priority: Critical
Attachments: patch_release_version_patterns.txt
When I try to run release:prepare in batch mode, I get the error below (can't
parse version string) even though I supply the version number by argument. If
I do the same thing with the same versions in interactive mode, it works fine.
Here is the output:
{noformat}
C:\workspaces\head\MyClientmvn -B -e -Dresume=false -Dtag=PPX
-DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
release:perform
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
[INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
[INFO]
Downloading:
http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
Downloading:
http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases-local
(http://myrepo.int.mycie.com/artifactory/libs-releases-local)
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository central (http://repo1.maven.org/maven2)
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C cvs -z3 -f -t -d
:pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d
[INFO] Working directory: C:\workspaces\head\MyClient
[INFO] Checking dependencies and plugins for snapshots ...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing version, cannot determine next version: Unable to parse
the version string: MYB_200909-SNAPSHOT
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
version, cannot determine next version: Unable to parse the version string:
MYB_200909-SNAPSHOT
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MCOMPILER-21: -- Assignee: Mark Struberg compiler smarts --- Key: MCOMPILER-21 URL: https://jira.codehaus.org/browse/MCOMPILER-21 Project: Maven 2.x Compiler Plugin Issue Type: Bug Reporter: Brett Porter Assignee: Mark Struberg Priority: Minor Fix For: backlog there are probably other ways we can make the compiler stale check smarter. List them out here if you think of them. 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MCOMPILER-21: --- Priority: Major (was: Minor) compiler smarts --- Key: MCOMPILER-21 URL: https://jira.codehaus.org/browse/MCOMPILER-21 Project: Maven 2.x Compiler Plugin Issue Type: Bug Reporter: Brett Porter Assignee: Mark Struberg Fix For: backlog there are probably other ways we can make the compiler stale check smarter. List them out here if you think of them. 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MCOMPILER-21: --- Attachment: MCOMPILER-21.patch started with some ugly hacks for now. Doing proper incremental build support actually contains of 2 steps. The first one mainly kicks in if someone invokes a phase package. In this case the Artifact of the other module is a directory. In this case we check whether the depending module is a path and if so, we check whether it contains newer files. - recompile all. The second trick will be on the reactor level. We might check the md5 of the dependencies and compare them with the md5 previously used. - invoke clean if something changed. compiler smarts --- Key: MCOMPILER-21 URL: https://jira.codehaus.org/browse/MCOMPILER-21 Project: Maven 2.x Compiler Plugin Issue Type: Bug Reporter: Brett Porter Assignee: Mark Struberg Fix For: backlog Attachments: MCOMPILER-21.patch there are probably other ways we can make the compiler stale check smarter. List them out here if you think of them. 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307117#comment-307117 ] Mark Struberg commented on MCOMPILER-21: PS: the code above currently only builds with skipping the tests. I'll need to move all the tests to the invoker-plugin first. The old plugin-test-harness doesn't work with sisu... compiler smarts --- Key: MCOMPILER-21 URL: https://jira.codehaus.org/browse/MCOMPILER-21 Project: Maven 2.x Compiler Plugin Issue Type: Bug Reporter: Brett Porter Assignee: Mark Struberg Fix For: backlog Attachments: MCOMPILER-21.patch there are probably other ways we can make the compiler stale check smarter. List them out here if you think of them. 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-66) sidebar and content class configurable
Olivier Lamy created MSKINS-66: -- Summary: sidebar and content class configurable Key: MSKINS-66 URL: https://jira.codehaus.org/browse/MSKINS-66 Project: Maven Skins Issue Type: Bug Reporter: Olivier Lamy sidebar use span3 and content span9. We must make that configurable for users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-66) sidebar and content class configurable
[ https://jira.codehaus.org/browse/MSKINS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSKINS-66: --- Fix Version/s: fluido-1.3.0 Assignee: Olivier Lamy sidebar and content class configurable -- Key: MSKINS-66 URL: https://jira.codehaus.org/browse/MSKINS-66 Project: Maven Skins Issue Type: Bug Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: fluido-1.3.0 sidebar use span3 and content span9. We must make that configurable for users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Halovanic updated MEAR-146: Attachment: ear-general-librarydirectory.patch Patch to try to cover all library-directory scenarios from this and MEAR-151. Expose parameter to not write library-directory element in application.xml -- Key: MEAR-146 URL: https://jira.codehaus.org/browse/MEAR-146 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.7 Environment: Oracle WebLogic Reporter: Alex Halovanic Priority: Minor Fix For: 2.8 Attachments: ear-general-librarydirectory.patch, ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch, ear-remove-librarydirectory.patch The current handling of defaultLibBundleDir leads to some issues on Oracle Weblogic 10+. The Ear plugin currently sets library-directory to the value of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's classloading features break (specifically Generic File Loading) when this element is set. defaultLibBundleDir has to be set to APP-INF/lib since this is the magic library folder for WebLogic. The patch adds a parameter to prevent setting library-directory for cases like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307120#comment-307120 ] Alex Halovanic commented on MEAR-146: - I don't want to make this any more confusing, but I've now uploaded a patch with a general string parameter to cover any possible required scenarios for library-directory, rather than having to do this in 2 or more boolean parameters. This defaults to the existing behavior of writing the same value as defaultLibBundleDir, should that be set. It can also be overriden to cover the empty string of MEAR-151, the not set of MEAR-146, and the as-yet hypothetical scenario where it has to be some other value. The use of special magic values is necessary because Mojo parameters unfortunately combine the empty, null and default scenarios for strings. Hopefully it's relatively clear in the generated site doc. Expose parameter to not write library-directory element in application.xml -- Key: MEAR-146 URL: https://jira.codehaus.org/browse/MEAR-146 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.7 Environment: Oracle WebLogic Reporter: Alex Halovanic Priority: Minor Fix For: 2.8 Attachments: ear-general-librarydirectory.patch, ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch, ear-remove-librarydirectory.patch The current handling of defaultLibBundleDir leads to some issues on Oracle Weblogic 10+. The Ear plugin currently sets library-directory to the value of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's classloading features break (specifically Generic File Loading) when this element is set. defaultLibBundleDir has to be set to APP-INF/lib since this is the magic library folder for WebLogic. The patch adds a parameter to prevent setting library-directory for cases like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-614) site plugin failure when forking a lifecycle
[ https://jira.codehaus.org/browse/MSITE-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307121#comment-307121 ] Andreas Pieber commented on MSITE-614: -- fair enough; still the question persists: is it a regression then or something we need to change in our configuration? site plugin failure when forking a lifecycle Key: MSITE-614 URL: https://jira.codehaus.org/browse/MSITE-614 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.0 Reporter: Andreas Pieber Attachments: 5ebbfe13_maven-test.tar.gz If you execute mvn site in the attached test project it fails because of the forked cycles. The test project could therefore not be resolved in the maven plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
