[jira] Created: (MNG-3502) Reword description of "provided" scope
Reword description of "provided" scope -- Key: MNG-3502 URL: http://jira.codehaus.org/browse/MNG-3502 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Environment: http://maven.apache.org/pom.html Reporter: Chad La Joie Priority: Minor The current description, in the POM reference, for the "provided" dependency scope is a bit misleading. It currently states: "This scope ... is only available for the test compilation and execution phases." When I read this I thought that meant the dependency would only be available in the test-compile and execution phases. What I needed was a scope that was available during the compilation, test, and execution phase. Searching the user-list showed a couple other people were tripped up by this as well. I'd like to recommend a change of wording then to make this more clear: "This scope ... is available in the compilation, test compilation, and execution phases." -- 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: (MEAR-43) add ability to do filtering (i.e. template var replacement) for files in src/main/application/
[ http://jira.codehaus.org/browse/MEAR-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129878#action_129878 ] Martin Buechler commented on MEAR-43: - The maven-ear-plugin-2.3.2-SNAPSHOT includes datasources into jboss-app.xml. Thats great, but without the ability to filter a template DS file in src/main/application there is no chance to configure another datassource target, than the one that has to be hardcoded into src/main/application/whatever-ds.xml. But Database-Connection Parameters usually differ in local, development, integration, staging and live environments. I herebey vote for filtering capabilities of the ear plugin. > add ability to do filtering (i.e. template var replacement) for files in > src/main/application/ > -- > > Key: MEAR-43 > URL: http://jira.codehaus.org/browse/MEAR-43 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ian Springer >Assignee: Stephane Nicoll >Priority: Minor > Fix For: 2.3.2 > > > I need to do some template var replacements in files in > src/main/application/. It would be great if the ear plugin could provide a > filtering configuration in a similar manner to the war plugin. That is, > something along the lines of: > > ... > > true > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDOCCK-10) Use proper file encoding when checking site descriptor
Use proper file encoding when checking site descriptor
--
Key: MDOCCK-10
URL: http://jira.codehaus.org/browse/MDOCCK-10
Project: Maven 2.x DOCCK Plugin
Issue Type: Bug
Affects Versions: 1.0-beta-2
Reporter: Benjamin Bentmann
This is not working reliably:
{code:java}
String siteHtml = FileUtils.fileRead( siteXml.getAbsolutePath()
);
{code}
See also [Common
Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html#a15919795].
--
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: (MPIR-94) Change optional label in dependencies site
Change optional label in dependencies site -- Key: MPIR-94 URL: http://jira.codehaus.org/browse/MPIR-94 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Affects Versions: 2.0.1 Reporter: Michael Osipov Priority: Minor If you check the project dependencies page, the table says for an aoptional dependency "(optional)". This is actually not really intuitive. A "yes" would be much more help full or even more, let the user configure a term for both states. -- 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-3502) Reword description of "provided" scope
[
http://jira.codehaus.org/browse/MNG-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-3502.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: Documentation Deficit
Fixed in [r645089|http://svn.apache.org/viewvc?view=rev&revision=645089].
bq. "This scope ... is only available for the test compilation and execution
phases."
The current docs (2008-04-04) say this only about the {{test}} scope, the
{{provided}} scope is already mentioned to be available during compilation.
However, the docs did not mention it to be available during testing.
> Reword description of "provided" scope
> --
>
> Key: MNG-3502
> URL: http://jira.codehaus.org/browse/MNG-3502
> Project: Maven 2
> Issue Type: Improvement
> Components: Documentation: General
> Environment: http://maven.apache.org/pom.html
>Reporter: Chad La Joie
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: Documentation Deficit
>
>
> The current description, in the POM reference, for the "provided" dependency
> scope is a bit misleading. It currently states:
> "This scope ... is only available for the test compilation and execution
> phases."
> When I read this I thought that meant the dependency would only be available
> in the test-compile and execution phases. What I needed was a scope that was
> available during the compilation, test, and execution phase. Searching the
> user-list showed a couple other people were tripped up by this as well.
> I'd like to recommend a change of wording then to make this more clear:
> "This scope ... is available in the compilation, test compilation, and
> execution phases."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Leggett updated MRELEASE-261:
--
Attachment: PrepareReleaseMojo.patch
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
org.apache.maven.plugins
maven-release-plugin
2.0-beta-7-PATCHED
${basedir}/..
clean verify -f ${artifactId}/pom.xml
scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}
clean deploy
${artifactId}/pom.xml
-f ${artifactId}/pom.xml
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
#hello-world/hello-world-parent> mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
Hope this is useful.
Adam
> release:prepare shouls support flat directory multimodule projects
> --
>
> Key: MRELEASE-261
> URL: http://jira.codehaus.org/browse/MRELEASE-261
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Environment: linux / maven2 / svn
>Reporter: [EMAIL PROTECTED]
> Attachments: PrepareReleaseMojo.patch
>
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
>
> ../module1
> ../module2
> .
> .
> .
> ../module15
>
> When i release:prepare only the parent project is tagged the modules
> projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here
> http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
> each submodule of the projects but it would be so nice to have the release
> plugin do this for me.
> forgive my english.
--
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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129890#action_129890
]
aleggett edited comment on MRELEASE-261 at 4/5/08 8:36 AM:
---
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
{noformat}
org.apache.maven.plugins
maven-release-plugin
2.0-beta-7-PATCHED
${basedir}/..
clean verify -f ${artifactId}/pom.xml
scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}
clean deploy
${artifactId}/pom.xml
-f ${artifactId}/pom.xml
{noformat}
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
{noformat}
#hello-world/hello-world-parent> mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
{noformat}
Hope this is useful.
Adam
was (Author: aleggett):
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
org.apache.maven.plugins
maven-release-plugin
2.0-beta-7-PATCHED
${basedir}/..
clean verify -f ${artifactId}/pom.xml
scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}
clean deploy
${artifactId}/pom.xml
-f ${artifactId}/pom.xml
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
#hello-world/hello-world-parent> mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
Hope this is useful.
Adam
> release:prepare shouls support flat directory multimodule projects
> --
>
> Key: MRELEASE-261
> URL: http://jira.codehaus.org/browse/MRELEASE-261
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Environment: linux / maven2 / svn
>Reporter: [EMAIL PROTECTED]
> Attachments: PrepareReleaseMojo.patch
>
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
>
> ../module1
> ../module2
> .
> .
> .
> ../module15
>
> When i release:prepare only the parent project is tagged the modules
> projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here
> http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
> each submodule of the projects but it would be so nice to have the release
> plugin do this for me.
> forgive my english.
--
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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129890#action_129890
]
aleggett edited comment on MRELEASE-261 at 4/5/08 8:39 AM:
---
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
{noformat}
org.apache.maven.plugins
maven-release-plugin
2.0-beta-7-PATCHED
${basedir}/..
clean verify -f ${artifactId}/pom.xml
scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}
clean deploy
${artifactId}/pom.xml
-f ${artifactId}/pom.xml
{noformat}
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
{noformat}
#hello-world/hello-world-parent> mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
{noformat}
Hope this is useful.
Adam
was (Author: aleggett):
Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo.
Then in your relative parent pom you can configure like this:
{noformat}
org.apache.maven.plugins
maven-release-plugin
2.0-beta-7-PATCHED
${basedir}/..
clean verify -f ${artifactId}/pom.xml
scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}
clean deploy
${artifactId}/pom.xml
-f ${artifactId}/pom.xml
{noformat}
The additional config is to ensure the parent pom gets found for the forked
lifecycles in release:prepare and release:perform. In addition, due to the
release manager now putting the release descriptor (release.properties) in
$[basedir}/.. you need to specify the connectionUrl for release:perform. I
guess you could write some script to move it or, as above, fill in the url
apart from the release version e.g.
{noformat}
#hello-world/hello-world-parent> mvn release:prepare release:perform
-Drelease.version=1.7 --batch-mode
{noformat}
Hope this is useful.
Adam
> release:prepare shouls support flat directory multimodule projects
> --
>
> Key: MRELEASE-261
> URL: http://jira.codehaus.org/browse/MRELEASE-261
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Environment: linux / maven2 / svn
>Reporter: [EMAIL PROTECTED]
> Attachments: PrepareReleaseMojo.patch
>
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
>
> ../module1
> ../module2
> .
> .
> .
> ../module15
>
> When i release:prepare only the parent project is tagged the modules
> projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here
> http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
> each submodule of the projects but it would be so nice to have the release
> plugin do this for me.
> forgive my english.
--
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: (MAVENUPLOAD-1995) Please sync javassist groupId
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof reopened MAVENUPLOAD-1995: -- Content from people.apache.org/x1/home/nicolas/rsync-to-central/javassist isn't copied to repo1.maven.org/maven2/javassist I've added versions 3.6.0.GA and 3.7.1.GA and see nothing on central. > Please sync javassist groupId > - > > Key: MAVENUPLOAD-1995 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1995 > Project: maven-upload-requests > Issue Type: Task >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > This is only a copy of http://repository.jboss.com/maven2/javassist/ > If there is a better way to sync some artifacts from > http://repository.jboss.com to central please let me know -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2006) Validator.nu HTML parser 1.0.7 to Maven repo
Validator.nu HTML parser 1.0.7 to Maven repo Key: MAVENUPLOAD-2006 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2006 Project: maven-upload-requests Issue Type: Improvement Reporter: Henri Sivonen Attachments: htmlparser-1.0.7-bundle.jar For reference, the previous version was MAVENUPLOAD-1900. Changes * Adds optional support for heuristic encoding sniffing using the ICU4J sniffer, jchardet or both. * Adds support for rewinding and reparsing when becoming confident about the character encoding and the tentative encoding was wrong. * Performs encoding name matching per spec instead of using the JDK mechanism. * Implements spec changes up until just before SVG and MathML support. (Those will merit 1.1 or something.) * Warning: The semantics of the doctype token have changed in case you have your own token handler (unlikely). -- 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-1995) Please sync javassist groupId
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129892#action_129892 ] nicolas de loof commented on MAVENUPLOAD-1995: -- according to maven-meeper CSV file, there is an unexpecetd trailing " " for javassist groupId "javassist ","[EMAIL PROTECTED]:/home/nicolas/rsync-to-central","rsync_ssh","Nicolas De Loof","[EMAIL PROTECTED]",," " > Please sync javassist groupId > - > > Key: MAVENUPLOAD-1995 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1995 > Project: maven-upload-requests > Issue Type: Task >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > This is only a copy of http://repository.jboss.com/maven2/javassist/ > If there is a better way to sync some artifacts from > http://repository.jboss.com to central please let me know -- 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-3503) Shade MX* classes from plexus-utils
Shade MX* classes from plexus-utils
---
Key: MNG-3503
URL: http://jira.codehaus.org/browse/MNG-3503
Project: Maven 2
Issue Type: Improvement
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Priority: Minor
Attachments: shade-mx-classes.patch
The Maven uber JAR currently ships with unshaded {{MXParser}} and
{{MXSerializer}}, preventing plugins from using their recent implementations
from plexus-utils. My initial question on the [dev
list|http://www.nabble.com/Shade-MX*-classes-from-plexus-utils--tc16080800s177.html]
showed now immediate objections and the core ITs also smile so here we go with
the proposed patch.
--
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: (MNGSITE-46) Specify file encoding to be employed for sources
Specify file encoding to be employed for sources Key: MNGSITE-46 URL: http://jira.codehaus.org/browse/MNGSITE-46 Project: Maven 2 Project Web Site Issue Type: Improvement Reporter: Benjamin Bentmann Priority: Minor The article [Committer Environment|http://maven.apache.org/developers/committer-environment.html] does not mention which file encoding developers should use when editing/patching the sources. I am not aware of any other doc that would state this right now. -- 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-2759) Resolving transitive dependencies of artefacts with classifiers fails
[ http://jira.codehaus.org/browse/MNG-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129907#action_129907 ] Libor Kramolis commented on MNG-2759: - Artifacts with classier are not deployed with its pom.xml. It means that projectC does not know what projectB depends on. :-( > Resolving transitive dependencies of artefacts with classifiers fails > - > > Key: MNG-2759 > URL: http://jira.codehaus.org/browse/MNG-2759 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP, Maven 2.0.4 >Reporter: Fabian Bauschulte > Fix For: Reviewed Pending Version Assignment > > Attachments: project.zip > > > I have the following projects with subprojects projectA, projectB and > projectC. projectA depends on projectB, projectC depends on projectB. All > projects use classifiers: > ... > projectB > > > > org.apache.maven.plugins > maven-jar-plugin > > someclassifier > > > > > > > test > projectB > 1.0.0 > someclassifier > > > When running "mvn clean install" on the the parent works fine. But running > "mvn install" only in projectC fails: > C:\Data\maven-test\projectC>mvn clean install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - test:projectC:jar:1.0.0 > [INFO]task-segment: [clean, install] > [INFO] > > [INFO] [clean:clean] > [INFO] Deleting directory C:\Data\maven-test\projectC\target > [INFO] Deleting directory C:\Data\maven-test\projectC\target\classes > [INFO] Deleting directory C:\Data\maven-test\projectC\target\test-classes > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > Downloading: > http://repo1.maven.org/maven2/test/projectB/1.0.0/projectB-1.0.0.pom > [WARNING] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > [INFO] [compiler:compile] > Compiling 1 source file to C:\Daten\maven-test\projectC\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > C:\Data\maven-test\projectC\src\main\java\ClassC.java:[3,12] cannot find > symbol > symbol : class ClassA > location: package test > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben Giesselmann updated MRELEASE-128:
Attachment: MNG-128-maven-release-manager.patch
Here's a patch which fixes the problems for pom.xml.next and pom.xml.tag.
Branching is not (yet) supported.
It works like this: instead of using {{scm.getConnection()}} and
{{scm.getDeveloperConnection()}} (which both contain the resolved variables),
it uses the original text contained in pom.xml (using the XML element).
HOWEVER ... the tests for {{RewritePomsForDevelopmentPhase}} fail. I don't know
exactly what's going on, but ... hmm, could the tests be wrong? (This is a
silly assumption, I know, but ... well, I just don't know.)
Still, after patching you can install {{maven-release-manager}} with
{{mvn -Dmaven.test.skip=true clean install}}
and see if it works for you, too.
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Emmanuel Venisse
>Priority: Critical
> Fix For: 2.0
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
> MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
> original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
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: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129909#action_129909
]
torbengee edited comment on MRELEASE-128 at 4/5/08 2:56 PM:
-
Here's a patch which fixes the problems for pom.xml.next and pom.xml.tag:
[^MNG-128-maven-release-manager.patch]
Branching is not (yet) supported.
It works like this: instead of using {{scm.getConnection()}} and
{{scm.getDeveloperConnection()}} (which both contain the resolved variables),
it uses the original text contained in pom.xml (using the XML element).
HOWEVER ... the tests for {{RewritePomsForDevelopmentPhase}} fail. I don't know
exactly what's going on, but ... hmm, could the tests be wrong? (This is a
silly assumption, I know, but ... well, I just don't know.)
Still, after patching you can install {{maven-release-manager}} with
{{mvn -Dmaven.test.skip=true clean install}}
and see if it works for you, too.
was (Author: torbengee):
Here's a patch which fixes the problems for pom.xml.next and pom.xml.tag.
Branching is not (yet) supported.
It works like this: instead of using {{scm.getConnection()}} and
{{scm.getDeveloperConnection()}} (which both contain the resolved variables),
it uses the original text contained in pom.xml (using the XML element).
HOWEVER ... the tests for {{RewritePomsForDevelopmentPhase}} fail. I don't know
exactly what's going on, but ... hmm, could the tests be wrong? (This is a
silly assumption, I know, but ... well, I just don't know.)
Still, after patching you can install {{maven-release-manager}} with
{{mvn -Dmaven.test.skip=true clean install}}
and see if it works for you, too.
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Emmanuel Venisse
>Priority: Critical
> Fix For: 2.0
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
> MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
> original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2007) Please sync net.sourceforge.nekohtml
Please sync net.sourceforge.nekohtml Key: MAVENUPLOAD-2007 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2007 Project: maven-upload-requests Issue Type: Wish Reporter: Marc Guillemot "net.sourceforge.nekohtml","[EMAIL PROTECTED]:/home/groups/n/ne/nekohtml/htdocs/m2-repo","rsync_ssh","Marc Guillemot","[EMAIL PROTECTED]",, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-182) git provider
[
http://jira.codehaus.org/browse/SCM-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed SCM-182.
-
Resolution: Fixed
I've committed this to trunk.
> git provider
>
>
> Key: SCM-182
> URL: http://jira.codehaus.org/browse/SCM-182
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-provider-git
> Environment: Developed on Mac OS X 10.3.9 with git 1.2.4
>Reporter: Dominik Winter
>Assignee: Jason van Zyl
> Fix For: future
>
> Attachments: git.patch, git.tar.bz2, SCM-182.patch, update1.patch.bz2
>
>
> Please find the git provider as attachment.
> Usefulness:
> I used the git provider together with
> [http://maven.apache.org/plugins/maven-release-plugin|maven-release-plugin],
> it works fine for that use case.
> Open issues:
> - the JUnit tests are "proprietary", not yet TCK. I'll fix that.
> If you want to run the tests, you must have git installed and it must be in
> your {{PATH}}.
> To run git:
> - on *Windows*: use [Cygwin|http://www.cygwin.com] and install the binutils,
> openssh, openssl, rsync, curl
> than you are able to compile and install git
> - on Linux: there are packages somewhere
> - on Mac OS X: use the [DarwinPorts|http://www.darwinports.org/]
--
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-3504) Very slow dependency resolution with disabled proxy IP
Very slow dependency resolution with disabled proxy IP -- Key: MNG-3504 URL: http://jira.codehaus.org/browse/MNG-3504 Project: Maven 2 Issue Type: Bug Components: Performance Affects Versions: 2.0.8 Environment: Windows Vista x64 Reporter: Paul Dillon Priority: Minor I have a proxy defined in my settings.xml as follows: false http 192.168.1.223 8080 192.168.* This proxy lives on my office network. It is inactive because I am currently working from home. However, although the proxy is inactive, during dependency resolution maven pauses for 15 seconds per dependency per repository. Tracing the network showed multiple ARP requests for 192.168.1.223. After commenting out the inactive proxy performance returned to normal. This issue is causing a 2 minute build to take over 1 hour. Using a DNS name for the proxy address would also resolve the issue, but this is not allowed on my work network. -- 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-2007) Please sync net.sourceforge.nekohtml
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2007. --- Assignee: Carlos Sanchez Resolution: Fixed > Please sync net.sourceforge.nekohtml > > > Key: MAVENUPLOAD-2007 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2007 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Marc Guillemot >Assignee: Carlos Sanchez > > "net.sourceforge.nekohtml","[EMAIL > PROTECTED]:/home/groups/n/ne/nekohtml/htdocs/m2-repo","rsync_ssh","Marc > Guillemot","[EMAIL PROTECTED]",, -- 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-1995) Please sync javassist groupId
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1995. --- Resolution: Fixed > Please sync javassist groupId > - > > Key: MAVENUPLOAD-1995 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1995 > Project: maven-upload-requests > Issue Type: Task >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > This is only a copy of http://repository.jboss.com/maven2/javassist/ > If there is a better way to sync some artifacts from > http://repository.jboss.com to central please let me know -- 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
