[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297096#comment-297096
]
Lukas Theussl commented on MSITE-604:
-
I have [added an
IT|http://svn.apache.org/viewvc?view=revision&revision=1329606], following the
original description of the problem. It passes without your patch applied. What
am I missing?
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: 3.1
>
> Attachments: MSITE-604-maven3-2.patch, MSITE-604-maven3.patch,
> MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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-640) Maven searches only central repository for imported dependencies
Markus Tippmann created MSITE-640: - Summary: Maven searches only central repository for imported dependencies Key: MSITE-640 URL: https://jira.codehaus.org/browse/MSITE-640 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0 Environment: Windows 7 Reporter: Markus Tippmann Attachments: stacktrace.txt We are using dependencyManagement with "import" scope like described here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies Problem occurs only at site generation, not at build time, where it works perfectly. The site plugin tries to find the imported artifacts, but searches only the central repository and ignores the repositories in settings.xml configuration. Mirror settings work, if "central" is mirrored, but dependencies need to be resolved from two repositories, so one mirror does not help here. I try to attach the relevant parts of the stacktrace. -- 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] (ARCHETYPE-319) Created Archetype can't be found
[
https://jira.codehaus.org/browse/ARCHETYPE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roland Asmann closed ARCHETYPE-319.
---
Resolution: Cannot Reproduce
Haven't checked back on this for quite some time, because we didn't need an
archetype anymore.
However, the last time I created an archetype, I couldn't reproduce this
anymore.
> Created Archetype can't be found
>
>
> Key: ARCHETYPE-319
> URL: https://jira.codehaus.org/browse/ARCHETYPE-319
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 2.0-alpha-5
> Environment: Windows 7 64-bit
> JDK 1.5.0_22 (64-bit)
> Maven 2.0.9
>Reporter: Roland Asmann
>
> I followed all steps in the tutorial that creates an archetype from an
> existing projects
> (http://maven.apache.org/archetype/maven-archetype-plugin/advanced-usage.html)
> and everything works fine but for the last step: creating a new project.
> Maven's output is as follows:
> {noformat}D:\workspaces\ws-itsv>mvn archetype:generate
> -DarchetypeCatalog=local
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO]
>
> [INFO] Building Maven Default Project
> [INFO]task-segment: [archetype:generate] (aggregator-style)
> [INFO]
>
> [INFO] Preparing archetype:generate
> [INFO] No goals needed for project - skipping
> [INFO] [archetype:generate]
> [INFO] Generating project in Interactive mode
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: local -> ApplicationSearchModule-archetype
> (ApplicationSearchModule-archetype)
> Choose a number: : 1
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] The desired archetype does not exist
> (at.itsv.application.search:ApplicationSearchModule-archetype:1.0.0-SNAPSHOT)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 4 seconds
> [INFO] Finished at: Tue Jun 29 15:46:13 CEST 2010
> [INFO] Final Memory: 19M/250M
> [INFO]
> {noformat}
--
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] (ARCHETYPE-407) Generate with 'goals' dies when the goals include multiple profiles
Roland Asmann created ARCHETYPE-407: --- Summary: Generate with 'goals' dies when the goals include multiple profiles Key: ARCHETYPE-407 URL: https://jira.codehaus.org/browse/ARCHETYPE-407 Project: Maven Archetype Issue Type: Improvement Affects Versions: 2.2 Reporter: Roland Asmann I have an archetype that I use for testing inside some of my projects. I want the plugin to generate and then build the project. The problem here is that when I want to activate more than one profile, the plugin splits the goals-string on the comma and therefor kills my call! Example of plugin-configuration: ... myGroupId myArchetypeId myVersion process-resources -Pibm,dev false It would be really helpful if the goals-parameter could just be used as-is, or at least not split on the comma. -- 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] (MSHADE-115) Runtime dependency-reduced-pom.xml causes problems within shared build trees
Seth Gransky created MSHADE-115: --- Summary: Runtime dependency-reduced-pom.xml causes problems within shared build trees Key: MSHADE-115 URL: https://jira.codehaus.org/browse/MSHADE-115 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.6 Reporter: Seth Gransky The runtime dependency-reduced-pom.xml (not the one in outputDirectory) causes problems within a build tree that is shared across multiple machines/builds. This file is cleaned up after it is no longer needed and if more than one build is running shade and the subsequent goals within the same subdirectory at around the same time, the dependency-reduced-pom.xml file can be wiped out by one process while another process still requires it. -- 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] (MSHADE-115) Runtime dependency-reduced-pom.xml causes problems within shared build trees
[ https://jira.codehaus.org/browse/MSHADE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297110#comment-297110 ] Benson Margulies commented on MSHADE-115: - And while here, note that the d-r-p doesn't get along so well if you try to have multiple shade executions, since the name conflicts. > Runtime dependency-reduced-pom.xml causes problems within shared build trees > > > Key: MSHADE-115 > URL: https://jira.codehaus.org/browse/MSHADE-115 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Seth Gransky > > The runtime dependency-reduced-pom.xml (not the one in outputDirectory) > causes problems within a build tree that is shared across multiple > machines/builds. This file is cleaned up after it is no longer needed and if > more than one build is running shade and the subsequent goals within the same > subdirectory at around the same time, the dependency-reduced-pom.xml file can > be wiped out by one process while another process still requires it. -- 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] (SCM-670) Support Jazz SCM
[ https://jira.codehaus.org/browse/SCM-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-670. Resolution: Fixed second patch fixed r1329765. Thanks! > Support Jazz SCM > > > Key: SCM-670 > URL: https://jira.codehaus.org/browse/SCM-670 > Project: Maven SCM > Issue Type: New Feature >Affects Versions: 1.7 > Environment: Win XP >Reporter: Chris Graham >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: FlowDiagram.png, FlowDiagramWithMultipleStreams.png, > jazz-site-xml-update.patch, maven-scm-1.7-snapshot-r1328783-jazz.patch, > WorkspaceOnly.png, WorkspaceWithStream.png > > > This issue, and it's associated patch, adds support for Jazz SCM, the SCM > component of the Jazz/IBM RTC platform. > The four attached images (don't get put into the .patch file!) so they are > attached here. > They need to be saved into the src/site/resources/images folder of the > maven-scm-provider-jazz folder. -- 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] (SCM-584) Checkout branch with Git uses unfamiliar command sequence which leads to errors during checkout
[
https://jira.codehaus.org/browse/SCM-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297115#comment-297115
]
Olivier Lamy commented on SCM-584:
--
Having a look at the code and that looks to be fixed (but issue not closed).
@Ancoron Luciferis: can you try with last SNAPSHOT ?
> Checkout branch with Git uses unfamiliar command sequence which leads to
> errors during checkout
> ---
>
> Key: SCM-584
> URL: https://jira.codehaus.org/browse/SCM-584
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.4
>Reporter: Daniel Strassenburg
>Priority: Critical
> Attachments: SCM-584.patch, SCM-584-test-prj.zip
>
>
> I want to checkout a specific branch from my git repo using the
> maven-scm-plugin. The plugin first clones the repo and gets the default
> branch as selected in gitorious. After that the plugin executes git pull ...
> mybranch which works fine as long as there are no merge conflicts between
> current branch and branch to checkout. In the case of any conflict an error
> occurs.
> The git checkout -b command should be used instead.
> {noformat}
> [INFO] Working directory:
> [INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
> git fetch git://gitorious/<...>/my-proj.git
> [INFO] Working directory:
> [INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
> git checkout HEAD
> [INFO] Working directory:
> [INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
> git ls-files
> [INFO] Working directory:
> [INFO]
> [INFO] --- maven-scm-plugin:1.4:update (switch-branch)
> [INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
> git pull git://gitorious/<..>/deploy.git mysql55
> [WARNING] failed to update git, return code 1
> [ERROR] Provider message:
> [ERROR] The git-pull origin master command failed.
> [ERROR] Command output:
> [ERROR] From git://gitorious/<...>/deploy
> * branchmysql55-> FETCH_HEAD
> {noformat}
--
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-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
https://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297118#comment-297118
]
Vedavyas Panneershelvam commented on MRELEASE-679:
--
Robert,
The content of tag is
scm:svn:svn://repo/trunk/
scm:svn:svn://repo/trunk/
and yes, did try it with version 2.2.2 as well.
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: https://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Assignee: Brett Porter
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
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-640) Maven searches only central repository for imported dependencies
[ https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297125#comment-297125 ] Richard Eggert commented on MSITE-640: -- This problem also manifests itself for parent poms that don't exist in the build tree (i.e., not accessible via the relativePath) or in central (deployed to a repository other than central), as well as for build extensions that do not reside in central. It seems as if the maven-site-plugin ignores all repositories except central when resolving these. > Maven searches only central repository for imported dependencies > > > Key: MSITE-640 > URL: https://jira.codehaus.org/browse/MSITE-640 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: Maven 3 >Affects Versions: 3.0 > Environment: Windows 7 >Reporter: Markus Tippmann > Attachments: stacktrace.txt > > > We are using dependencyManagement with "import" scope like described here: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies > Problem occurs only at site generation, not at build time, where it works > perfectly. > The site plugin tries to find the imported artifacts, but searches only the > central repository and ignores the repositories in settings.xml > configuration. Mirror settings work, if "central" is mirrored, but > dependencies need to be resolved from two repositories, so one mirror does > not help here. > I try to attach the relevant parts of the stacktrace. -- 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-640) Maven searches only central repository for imported dependencies
[ https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297128#comment-297128 ] Richard Eggert commented on MSITE-640: -- I'll try to put together an example that I can attach here when I find some time, but here's how to reproduce the problem for the parent POM use case: In your active profile in settings.xml, configure a remote repository that points to a location in your local file system. Make sure that the central repository is independently reachable (either directly or via a configured mirror). Create a new Maven project with packaging type "pom". Configure the distributionManagement section such that "mvn deploy" will target the "remote" repository on your file system that you configured in settings.xml. Run "mvn deploy" on this project, then delete your local repository (but not the "remote" one that you deployed to). Create a second Maven project with packaging type "pom". Use the first project configured above as the "parent" POM, but set the relativePath element to be empty (forcing it to be resolved via repository). In the "modules" section of the POM, specify a sub-module. Within the second Maven project, create the sub-module project that you specified in the POM, using the containing project's POM as the parent (set relativePath to ".."). >From within the second Maven project (the container of the sub-module), run >"mvn package". This should work perfectly. Then run "mvn site". This will >fail, being unable to resolve the dependency to the parent POM (the first >project that you deployed) against the central repository (apparently ignoring >the "remote" repository on the local filesystem, as well as the fact that the >parent POM was already downloaded into the local repository during "mvn >package"). Something similar will happen if you specify a build extension in the sub-module POM. > Maven searches only central repository for imported dependencies > > > Key: MSITE-640 > URL: https://jira.codehaus.org/browse/MSITE-640 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: Maven 3 >Affects Versions: 3.0 > Environment: Windows 7 >Reporter: Markus Tippmann > Attachments: stacktrace.txt > > > We are using dependencyManagement with "import" scope like described here: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies > Problem occurs only at site generation, not at build time, where it works > perfectly. > The site plugin tries to find the imported artifacts, but searches only the > central repository and ignores the repositories in settings.xml > configuration. Mirror settings work, if "central" is mirrored, but > dependencies need to be resolved from two repositories, so one mirror does > not help here. > I try to attach the relevant parts of the stacktrace. -- 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-150) [patch] support new 'no-version-for-ejbs' file name mapping
Philippe Marschall created MEAR-150: --- Summary: [patch] support new 'no-version-for-ejbs' file name mapping Key: MEAR-150 URL: https://jira.codehaus.org/browse/MEAR-150 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.7 Reporter: Philippe Marschall Priority: Minor Attachments: maven-ear-plugin.patch JBoss 7 has a new [remote lookup naming stragety|https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI?_sscc=t]. The name of the ejb-jar is not part of remote name. If that includes the version this is obviously going to cause problems. Using 'no-version' would fix this but I would like to keep version of the library jars as a quick way of verifying the ears contents. What this name mapping does is essentially 'no-version' for ejb-jars, 'standard' for library jars. -- 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-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
https://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297140#comment-297140
]
Robert Scholte commented on MRELEASE-679:
-
I know this works for the http-protocol, so my first guess would be that the
svn-protocol is misinterpreted. I'm still unsure if this is caused by the
release-plugin or by the svn-scm-provider. Could you analyze the tag command
executed when running Maven in debug mode?
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: https://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Assignee: Brett Porter
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
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-698) Inconsistent documentation for 'generate release pom'
[ https://jira.codehaus.org/browse/MRELEASE-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-698. --- Resolution: Fixed Fix Version/s: 2.3 Assignee: Robert Scholte Fixed in [r1329985|http://svn.apache.org/viewvc?rev=1329985&view=rev] > Inconsistent documentation for 'generate release pom' > - > > Key: MRELEASE-698 > URL: https://jira.codehaus.org/browse/MRELEASE-698 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: documentation >Affects Versions: 2.2 >Reporter: Benson Margulies >Assignee: Robert Scholte > Fix For: 2.3 > > > http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html > disagrees with > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#generateReleasePoms, > which describes the former technique as deprecated. -- 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] (WAGON-373) wagon-http fails to deploy files larger than 2GB
Scott Glajch created WAGON-373: -- Summary: wagon-http fails to deploy files larger than 2GB Key: WAGON-373 URL: https://jira.codehaus.org/browse/WAGON-373 Project: Maven Wagon Issue Type: Bug Components: wagon-http Affects Versions: 2.2, 2.1, 2.0 Environment: Our repository server is "Sonatype Nexus Professional Edition, Version: 1.9.2.4" We are using maven 3.0.3. Reporter: Scott Glajch Attachments: wagon-http-1.0-beta-7_stacktrace.txt, wagon-http-2.0_stacktrace.txt Our build produces a vm template that we upload to the repository. Recently this grew to be just over 2GB and the build started failing to deploy. We were using vesrion 1.0-beta-7 of wagon-http-lightweight. I created a small isolated project to exhibit the behavior and tried changing the versions around. We tried upgrading to wagon-http 2.2 but this failed because that version is broken. There's an incompatibility between the two jars wagon-http-shared4 and wagon-provider-api both of version 2.2. I'm going to log a separate bug for that version. Then we tried 2.0 and that got further. The error from wagon-http version-1.0-beta-7 is: "Write failed: Broken pipe" The error from wagon-http version 2.0 is: "The target server failed to respond" My isolated project was created like this. I have three resource files, testfile1 and testfile2 are just over 1GB each. testfile3 is 900MB. To show the problem, I have the pom.xml file exclude testfile3, and the resulting jar file that's built is about 2.1GB. To ensure that everything works correctly right before the 2GB limit, I then change the pom.xml file to exclude testfile2, and the resultant jar file is 1.9GB. The 1.9GB file deploys correctly but the 2.1GB file does not. To create these files, I used the linux command "dd if=/dev/urandom of=testfile1 bs=1095761920 count=1". That long number for "bs" is 1024*1024*1045. To create the smaller 900MB file I used 1024*1024*900. Full stack traces are attached. -- 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] (SCM-671) Perforce provider Edit command incorrectly ignores working Directory
[ https://jira.codehaus.org/browse/SCM-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-671. Resolution: Fixed > Perforce provider Edit command incorrectly ignores working Directory > > > Key: SCM-671 > URL: https://jira.codehaus.org/browse/SCM-671 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.6 > Environment: maven 3.0.3 >Reporter: Don Walling >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: patch, PerforceEditCommandTest.java > > > When the working directory is something other than "." the perforce edit > command does not include the relative path to the files actually being > edited. For instance in the case where the directory structure is: > pom.xml > a/pom.xml > a/foo.xml > The command > mvn scm:edit -f a/pom.xml -Dincludes=foo.xml > will result in a failure because the method > PerforceEditCommand.createCommandLine is assembling the path as if foo/.xml > were at the top level. > > A second instance is the case where the directory structure is: > pom.xml > a/pom.xml > a/b/pom.xml > a/b/c/pom.xml > The command > mvn scm:edit -f a/pom.xml -Dincludes=**/pom.xml > will result in only the top-level pom.xml being opened for editing, when it > should open b/pom.xml and b/c/pom.xml -- 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-150) [patch] support new 'no-version-for-ejbs' file name mapping
[ https://jira.codehaus.org/browse/MEAR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297167#comment-297167 ] Stéphane Nicoll commented on MEAR-150: -- thanks for the patch! > [patch] support new 'no-version-for-ejbs' file name mapping > --- > > Key: MEAR-150 > URL: https://jira.codehaus.org/browse/MEAR-150 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.7 >Reporter: Philippe Marschall >Priority: Minor > Fix For: 2.8 > > Attachments: maven-ear-plugin.patch > > > JBoss 7 has a new [remote lookup naming > stragety|https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI?_sscc=t]. > The name of the ejb-jar is not part of remote name. If that includes the > version this is obviously going to cause problems. Using 'no-version' would > fix this but I would like to keep version of the library jars as a quick way > of verifying the ears contents. What this name mapping does is essentially > 'no-version' for ejb-jars, 'standard' for library jars. -- 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-150) [patch] support new 'no-version-for-ejbs' file name mapping
[ https://jira.codehaus.org/browse/MEAR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll updated MEAR-150: - Fix Version/s: 2.8 > [patch] support new 'no-version-for-ejbs' file name mapping > --- > > Key: MEAR-150 > URL: https://jira.codehaus.org/browse/MEAR-150 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.7 >Reporter: Philippe Marschall >Priority: Minor > Fix For: 2.8 > > Attachments: maven-ear-plugin.patch > > > JBoss 7 has a new [remote lookup naming > stragety|https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI?_sscc=t]. > The name of the ejb-jar is not part of remote name. If that includes the > version this is obviously going to cause problems. Using 'no-version' would > fix this but I would like to keep version of the library jars as a quick way > of verifying the ears contents. What this name mapping does is essentially > 'no-version' for ejb-jars, 'standard' for library jars. -- 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
