[jira] Created: (MRELEASE-683) maven:perform will not release projects unless the pom file is in the top directory in the SCM repo
maven:perform will not release projects unless the pom file is in the top directory in the SCM repo --- Key: MRELEASE-683 URL: http://jira.codehaus.org/browse/MRELEASE-683 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.1 Environment: linux/mac Reporter: Lee Thompson Playing around with the MOJO project hosted in GIT. I can't release a plugin unless all the MOJO projects are split into their own GIT repos. If you want to put all plugins in one GIT repo, checkout the code, jump into a plugin project and release just that one plugin... release:perform will not jump into the right sub-directory of the GIT repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-457) Non sparse-checkout SCM support
[
http://jira.codehaus.org/browse/MRELEASE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=270210#comment-270210
]
Lee Thompson commented on MRELEASE-457:
---
Trying to catch up on this as I'm hitting it to. Don't think the patch will
work if there is no pom in the top directory of the source repo. In line with
what Benjamin stated, I think its better to inject rather than discover.
Injection of something like pomSubDirectory as a parameter into the
release:perform mojo would be very unobtrusize. The release descriptor already
has ScmRelativePathProjectDirectory. Not sure if that is the right variable,
but if it was, it would be a very simple non-intrusive fix of
PerformReleaseMojo.java ...
{code:title=Bar.java|borderStyle=solid}
/**
* If the POM for the project you are releasing is not in the top directory
of your checked
* out source repository, then you will need to specicify this parameter.
It almost never
* occurs with Subversion since you can specify a checkout of any directory
in the
* repository. This is not the case for SCM systems like Git and Mercurial
as you check
* out the whole repository and frequently, the project you want to release
is not in
* the top directory. If your pom is in the top directory of your source,
this parameter
* is not needed.
*
* @parameter expression=${pomSubDirectory}
* @since 2.2
*/
private String pomSubDirectory;
if (pomSubDirectory != null )
{
releaseDescriptor.setScmRelativePathProjectDirectory(
pomSubDirectory );
}
{code}
Non sparse-checkout SCM support
---
Key: MRELEASE-457
URL: http://jira.codehaus.org/browse/MRELEASE-457
Project: Maven 2.x Release Plugin
Issue Type: New Feature
Components: perform, scm
Affects Versions: 2.0
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 2.2
Attachments: MRELEASE-457.2.patch, MRELEASE-457.patch
Some SCMs like GIT, Mercurial, Bazaar, BitKeeper, Darcs, and Monotone doesn't
support sparse checkouts (checkout of a single subdirectory).
So while doing a mvn release:perform in a sub-module, we will always get the
_whole_ project checked out into target/checkout!
For doing the clean build from this checkout, we have to implement a
functionality to find the right submodule first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-683) maven:perform will not release projects unless the pom file is in the top directory in the SCM repo
[ http://jira.codehaus.org/browse/MRELEASE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=270225#comment-270225 ] Lee Thompson commented on MRELEASE-683: --- Thanks! maven:perform will not release projects unless the pom file is in the top directory in the SCM repo --- Key: MRELEASE-683 URL: http://jira.codehaus.org/browse/MRELEASE-683 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.1 Environment: linux/mac Reporter: Lee Thompson Assignee: Mark Struberg Fix For: 2.2 Playing around with the MOJO project hosted in GIT. I can't release a plugin unless all the MOJO projects are split into their own GIT repos. If you want to put all plugins in one GIT repo, checkout the code, jump into a plugin project and release just that one plugin... release:perform will not jump into the right sub-directory of the GIT repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-247) Partially resolved artifacts in local repo trip up go-offline
Partially resolved artifacts in local repo trip up go-offline
-
Key: MDEP-247
URL: http://jira.codehaus.org/browse/MDEP-247
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies, go-offline, resolve, resolve-plugins
Affects Versions: 2.1
Environment: Mac/Linux
Reporter: Lee Thompson
Assignee: Brian Fox
Sometime ins my local repo, I get an artifact POM downloaded, but not the JAR.
This happens frequently enough that when I do go offline, my development work
comes to a halt.
The latest partial in my local repo is this...
{code:title=RepoListing|borderStyle=solid}
$ ls ~/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.1
plexus-utils-1.4.1.pom plexus-utils-1.4.1.pom.sha1
{code}
Notice the plexus-utils jar file is not in the repo. The issue is go-offline
should detect that the packaged artifact is missing and resolve it, not just
the 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] Created: (MINVOKER-87) Invoker install goal fails when used in eclipse
Invoker install goal fails when used in eclipse
---
Key: MINVOKER-87
URL: http://jira.codehaus.org/browse/MINVOKER-87
Project: Maven 2.x Invoker Plugin
Issue Type: Bug
Affects Versions: 1.3
Reporter: Lee Thompson
Using maven-invoker-plugin works great on the command line.
When used with eclipse, the install goal will fail to install a previous
module's jar file into localRepositoryPath. A workaround is to use
maven-install-plugin instead.
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-invoker-plugin:1.3:install' --
[DEBUG] (f) localRepository =
Repository[local|file:///Users/Lee/.m2/repository]
[DEBUG] (f) localRepositoryPath =
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo
[DEBUG] (f) project = MavenProject:
org.codehaus.mojo:patch-maven-plugin:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/pom.xml
[DEBUG] (f) reactorProjects = [MavenProject:
org.codehaus.mojo:cbuild-parent:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/pom.xml, MavenProject:
org.codehaus.mojo:cbuild-tool-parent:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/downloader/pom.xml, MavenProject:
org.codehaus.mojo:cbuild-utils:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/cbuild-utils/pom.xml, MavenProject:
org.codehaus.mojo:cbuild-plugin-parent:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/plugins/pom.xml, MavenProject:
org.codehaus.mojo:cbuild-lifecycles:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/plugins/cbuild-lifecycles/pom.xml,
MavenProject: org.codehaus.mojo:rpm-cbuild-maven-plugin:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/plugins/rpm-cbuild-maven-plugin/pom.xml,
MavenProject: org.codehaus.mojo:patch-maven-plugin:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/pom.xml,
MavenProject: org.codehaus.mojo:make-maven-plugin:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/plugins/make-maven-plugin/pom.xml,
MavenProject: org.codehaus.mojo:shell-maven-plugin:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/plugins/shell-maven-plugin/pom.xml,
MavenProject:
org.codehaus.mojo:build-on-demand-maven-plugin:1.0-beta-1-SNAPSHOT @
/Users/Lee/Documents/workspace/c-builds/plugins/build-on-demand-maven-plugin/pom.xml]
[DEBUG] -- end configuration --
[INFO] [invoker:install {execution: integration-test}]
[DEBUG] On Install: Using artifact file for POM:
org.codehaus.mojo:patch-maven-plugin:pom:1.0-beta-1-SNAPSHOT
[DEBUG] WARNING: Artifact:
org.codehaus.mojo:patch-maven-plugin:pom:1.0-beta-1-SNAPSHOT does not have
project-builder metadata (ProjectBuilderConfiguration) associated with it.
Cannot access CLI properties for version transformation.
[INFO] Installing
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/pom-transformed.xml
to
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo/org/codehaus/mojo/patch-maven-plugin/1.0-beta-1-SNAPSHOT/patch-maven-plugin-1.0-beta-1-SNAPSHOT.pom
[INFO] Installing
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/patch-maven-plugin-1.0-beta-1-SNAPSHOT.jar
to
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo/org/codehaus/mojo/patch-maven-plugin/1.0-beta-1-SNAPSHOT/patch-maven-plugin-1.0-beta-1-SNAPSHOT.jar
[DEBUG] On Install: Using artifact file for POM:
org.codehaus.mojo:cbuild-plugin-parent:pom:1.0-beta-1-SNAPSHOT
[INFO] Installing
/Users/Lee/Documents/workspace/c-builds/plugins/target/pom-transformed.xml to
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo/org/codehaus/mojo/cbuild-plugin-parent/1.0-beta-1-SNAPSHOT/cbuild-plugin-parent-1.0-beta-1-SNAPSHOT.pom
[DEBUG] On Install: Using artifact file for POM:
org.codehaus.mojo:cbuild-parent:pom:1.0-beta-1-SNAPSHOT
[INFO] Installing
/Users/Lee/Documents/workspace/c-builds/target/pom-transformed.xml to
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo/org/codehaus/mojo/cbuild-parent/1.0-beta-1-SNAPSHOT/cbuild-parent-1.0-beta-1-SNAPSHOT.pom
[DEBUG] On Install: Using artifact file for POM:
org.codehaus.mojo:cbuild-utils:pom:1.0-beta-1-SNAPSHOT
[DEBUG] WARNING: Artifact:
org.codehaus.mojo:cbuild-utils:pom:1.0-beta-1-SNAPSHOT does not have
project-builder metadata (ProjectBuilderConfiguration) associated with it.
Cannot access CLI properties for version transformation.
[INFO] Installing
/Users/Lee/Documents/workspace/c-builds/cbuild-utils/target/pom-transformed.xml
to
/Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo/org/codehaus/mojo/cbuild-utils/1.0-beta-1-SNAPSHOT/cbuild-utils-1.0-beta-1-SNAPSHOT.pom
[INFO]
[jira] Reopened: (WAGON-264) compressed tarball download problems
[ http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lee Thompson reopened WAGON-264: If its a server config issue, its a server config issue that http transport clients know how to deal with (except wagon...) I'll download expat with CURL, WGET, and Wagon. Two work, one doesn't. Same for openssl. Wagon corrupts compressed tarballs via http/https. $ mkdir curl wagon wget $ cd curl $ wget http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz--2009-05-05 10:02:00-- http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz Resolving softlayer.dl.sourceforge.net... 74.86.229.28 Connecting to softlayer.dl.sourceforge.net|74.86.229.28|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 318349 (311K) [application/x-gzip] Saving to: `expat-1.95.8.tar.gz' 100%[==] 318,349 539K/s in 0.6s 2009-05-05 10:02:00 (539 KB/s) - `expat-1.95.8.tar.gz' saved [318349/318349] $ cd ../wget $ wget http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz--2009-05-05 10:02:10-- http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz Resolving softlayer.dl.sourceforge.net... 74.86.229.28 Connecting to softlayer.dl.sourceforge.net|74.86.229.28|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 318349 (311K) [application/x-gzip] Saving to: `expat-1.95.8.tar.gz' 100%[==] 318,349 554K/s in 0.6s 2009-05-05 10:02:10 (554 KB/s) - `expat-1.95.8.tar.gz' saved [318349/318349] $ HTTP/1.1 200 OK -bash: HTTP/1.1: No such file or directory $ cd ../wagon/ $ mvn wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz -Dwagon.url=http://softlayer.dl.sourceforge.net/sourceforge/expat -Dwagon.toDir=./ [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'wagon'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [wagon:download-single] (aggregator-style) [INFO] [INFO] [wagon:download-single] [INFO] Downloading: http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.98.8.tar.gz to /Users/Lee/junk/downloads/wagon/expat-1.98.8.tar.gz [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue May 05 10:03:59 CDT 2009 [INFO] Final Memory: 4M/8M [INFO] $ $ $ cd .. $ ls -lR total 0 drwxr-xr-x 3 Lee Lee 102 May 5 10:02 curl drwxr-xr-x 3 Lee Lee 102 May 5 10:03 wagon drwxr-xr-x 3 Lee Lee 102 May 5 10:02 wget ./curl: total 624 -rw-r--r-- 1 Lee Lee 318349 Jul 24 2004 expat-1.95.8.tar.gz ./wagon: total 72 -rw-r--r-- 1 Lee Lee 34158 May 5 10:03 expat-1.98.8.tar.gz ./wget: total 624 -rw-r--r-- 1 Lee Lee 318349 Jul 24 2004 expat-1.95.8.tar.gz $ compressed tarball download problems Key: WAGON-264 URL: http://jira.codehaus.org/browse/WAGON-264 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0-beta-2, 1.0-beta-3, 1.0-beta-4, 1.0-beta-5 Reporter: Lee Thompson Assignee: John Casey Fix For: 1.0-beta-5 HTTP wagon will uncompress tarballs it downloads, sometimes badly. Downloading openssl results in an unpressed download $ mvn -X wagon:download-single -Dwagon.fromFile=openssl-0.9.8k.tar.gz -Dwagon.url=http://www.openssl.org/source -Dwagon.toDir=./ $ tar tzf openssl-0.9.8k.tar.gz gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error exit delayed from previous errors $ tar tf openssl-0.9.8k.tar.gz | more openssl-0.9.8k/apps/ openssl-0.9.8k/apps/app_rand.c Downloading expat results in a corrupted file mvn -X wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz -Dwagon.url=http://prdownloads.sourceforge.net/expat -Dwagon.toDir=./ $ tar tf expat-1.98.8.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Read 1943 bytes from expat-1.98.8.tar.gz tar: Error exit delayed from previous errors -- 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: (WAGON-264) compressed tarball download problems
[ http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=175191#action_175191 ] Lee Thompson commented on WAGON-264: I'm reading rfc2616 and indeed, I agree with you that the openssl webserver is misconfigured deviating from HTTP spec. The webserver in this case transmitted Content-Type of gzip with no Content-Encoding but declared in the reply Content-Encoding of gzip. Unfortunately, it looks to me like the openssl config is following the Apache documentation to the letter http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addencoding specifically -- To make this long story short, you should always use x-gzip and x-compress for these two specific encodings. The Apache docs are probably incorrect (or confusing at best) leading to this issue. I'd have to go back to the point that wget, and curl (and I just tested firefox) will all download from these sites and get the correct file. I'd also go back to my point that performance is worse when you ask for GZIP encoding for filetypes that are already compressed. The only typical maven uncompressed file types are the pom XML files and the SHA1 and MD5SUM hash files and these artifacts are so small that the benefit is negligible. While wagon might not have a bug in regards to rfc2616, it does have an issue dealing with sites who read the Apache configuration documentation. Wagon is the only http client I know of that can't download tarballs from sourceforge and openssl. (Lots of sourceforge mirrors have this config problem). The internet is a cooperative media and strict compliance is often compromised when interoperability concerns are brought in. Please make wagon defend itself from badly configured webservers. compressed tarball download problems Key: WAGON-264 URL: http://jira.codehaus.org/browse/WAGON-264 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0-beta-2, 1.0-beta-3, 1.0-beta-4, 1.0-beta-5 Reporter: Lee Thompson Assignee: John Casey Fix For: 1.0-beta-5 HTTP wagon will uncompress tarballs it downloads, sometimes badly. Downloading openssl results in an unpressed download $ mvn -X wagon:download-single -Dwagon.fromFile=openssl-0.9.8k.tar.gz -Dwagon.url=http://www.openssl.org/source -Dwagon.toDir=./ $ tar tzf openssl-0.9.8k.tar.gz gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error exit delayed from previous errors $ tar tf openssl-0.9.8k.tar.gz | more openssl-0.9.8k/apps/ openssl-0.9.8k/apps/app_rand.c Downloading expat results in a corrupted file mvn -X wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz -Dwagon.url=http://prdownloads.sourceforge.net/expat -Dwagon.toDir=./ $ tar tf expat-1.98.8.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Read 1943 bytes from expat-1.98.8.tar.gz tar: Error exit delayed from previous errors -- 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: (WAGON-264) compressed tarball download problems
[ http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=174975#action_174975 ] Lee Thompson commented on WAGON-264: I believe the problem is the wagon-http-lightweight is ignoring the DECLINED:FEXT_GZ status code returned by mod_gzip. When this error code is seen, mod_gzip passed on dynamic compresson since the request is for an already compressed gzip file. Wagon requesting mod_gzip on ZIP and JAR files doesn't seem to trigger this behavior. It would be an optimization to not ask for compression on JAR and ZIP files as these files are compressed but mod_gzip doesn't seem to know that. Double compressing consumes time on both the client and server with no decrease in download payload (download sometimes increases somewhat) compressed tarball download problems Key: WAGON-264 URL: http://jira.codehaus.org/browse/WAGON-264 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0-beta-2, 1.0-beta-3, 1.0-beta-4, 1.0-beta-5 Reporter: Lee Thompson HTTP wagon will uncompress tarballs it downloads, sometimes badly. Downloading openssl results in an unpressed download $ mvn -X wagon:download-single -Dwagon.fromFile=openssl-0.9.8k.tar.gz -Dwagon.url=http://www.openssl.org/source -Dwagon.toDir=./ $ tar tzf openssl-0.9.8k.tar.gz gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error exit delayed from previous errors $ tar tf openssl-0.9.8k.tar.gz | more openssl-0.9.8k/apps/ openssl-0.9.8k/apps/app_rand.c Downloading expat results in a corrupted file mvn -X wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz -Dwagon.url=http://prdownloads.sourceforge.net/expat -Dwagon.toDir=./ $ tar tf expat-1.98.8.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Read 1943 bytes from expat-1.98.8.tar.gz tar: Error exit delayed from previous errors -- 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: (WAGON-264) compressed tarball download problems
[ http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=174980#action_174980 ] Lee Thompson commented on WAGON-264: Looks like the client can not see the bypass behavior of mod_gzip. If you run this little groovy program, it will dump the request headers... URL url = new URL ( http://prdownloads.sourceforge.net/expat/expat-1.98.8.tar.gz; ); HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection(); urlConnection.setRequestProperty( Accept-Encoding, gzip ); int responseCode = urlConnection.getResponseCode(); println Response code is + responseCode MapString, ListString hdrFields = urlConnection.getHeaderFields() println hdrFields output... Response code is 200 [X-Powered-By:[PHP/5.2.8], Set-Cookie:[PHPSESSID=7f4eb0ee669a6363aa7c1e80b4980b0e; expires=Sunday, 17-May-09 13:23:42 GMT; path=/], X-SFX-Webhead:[sfs-web-7], null:[HTTP/1.1 200 OK], X-SFX-Revision:[release_20090417], Date:[Sun, 03 May 2009 13:23:42 GMT], Pragma:[no-cache], Content-type:[text/html], Cache-Control:[no-store, no-cache, must-revalidate, post-check=0, pre-check=0], Content-Encoding:[gzip], Expires:[Thu, 19 Nov 1981 08:52:00 GMT], Server:[lighttpd/1.4.19], Transfer-Encoding:[chunked], Vary:[Accept-Encoding, User-Agent]] Suggest a getCompressedFileExtension() method to Resource.java which checks the file extenstion for common internet compressed file types like jar, zip, gz, tgz, bz2 and if getCompressedFileExtension() is true, don't as for the gzip encoding and don't check for it either. This check would be needed fro http and https. compressed tarball download problems Key: WAGON-264 URL: http://jira.codehaus.org/browse/WAGON-264 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0-beta-2, 1.0-beta-3, 1.0-beta-4, 1.0-beta-5 Reporter: Lee Thompson HTTP wagon will uncompress tarballs it downloads, sometimes badly. Downloading openssl results in an unpressed download $ mvn -X wagon:download-single -Dwagon.fromFile=openssl-0.9.8k.tar.gz -Dwagon.url=http://www.openssl.org/source -Dwagon.toDir=./ $ tar tzf openssl-0.9.8k.tar.gz gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error exit delayed from previous errors $ tar tf openssl-0.9.8k.tar.gz | more openssl-0.9.8k/apps/ openssl-0.9.8k/apps/app_rand.c Downloading expat results in a corrupted file mvn -X wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz -Dwagon.url=http://prdownloads.sourceforge.net/expat -Dwagon.toDir=./ $ tar tf expat-1.98.8.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Read 1943 bytes from expat-1.98.8.tar.gz tar: Error exit delayed from previous errors -- 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: (WAGON-264) compressed tarball download problems
[ http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=174980#action_174980 ] Lee Thompson edited comment on WAGON-264 at 5/3/09 8:34 AM: Looks like the client can not see the bypass behavior of mod_gzip. If you run this little groovy program, it will dump the request headers... URL url = new URL ( http://prdownloads.sourceforge.net/expat/expat-1.98.8.tar.gz; ); HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection(); urlConnection.setRequestProperty( Accept-Encoding, gzip ); int responseCode = urlConnection.getResponseCode(); println Response code is + responseCode MapString, ListString hdrFields = urlConnection.getHeaderFields() println hdrFields output... Response code is 200 [X-Powered-By:[PHP/5.2.8], Set-Cookie:[PHPSESSID=7f4eb0ee669a6363aa7c1e80b4980b0e; expires=Sunday, 17-May-09 13:23:42 GMT; path=/], X-SFX-Webhead:[sfs-web-7], null:[HTTP/1.1 200 OK], X-SFX-Revision:[release_20090417], Date:[Sun, 03 May 2009 13:23:42 GMT], Pragma:[no-cache], Content-type:[text/html], Cache-Control:[no-store, no-cache, must-revalidate, post-check=0, pre-check=0], Content-Encoding:[gzip], Expires:[Thu, 19 Nov 1981 08:52:00 GMT], Server:[lighttpd/1.4.19], Transfer-Encoding:[chunked], Vary:[Accept-Encoding, User-Agent]] Suggest a getCompressedFileExtension() method to Resource.java which checks the file extenstion for common internet compressed file types like jar, zip, gz, tgz, bz2, mp3, etc. If getCompressedFileExtension() is true, don't ask for the gzip encoding and don't check for it either. This check would be needed for http and https. was (Author: stimpy): Looks like the client can not see the bypass behavior of mod_gzip. If you run this little groovy program, it will dump the request headers... URL url = new URL ( http://prdownloads.sourceforge.net/expat/expat-1.98.8.tar.gz; ); HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection(); urlConnection.setRequestProperty( Accept-Encoding, gzip ); int responseCode = urlConnection.getResponseCode(); println Response code is + responseCode MapString, ListString hdrFields = urlConnection.getHeaderFields() println hdrFields output... Response code is 200 [X-Powered-By:[PHP/5.2.8], Set-Cookie:[PHPSESSID=7f4eb0ee669a6363aa7c1e80b4980b0e; expires=Sunday, 17-May-09 13:23:42 GMT; path=/], X-SFX-Webhead:[sfs-web-7], null:[HTTP/1.1 200 OK], X-SFX-Revision:[release_20090417], Date:[Sun, 03 May 2009 13:23:42 GMT], Pragma:[no-cache], Content-type:[text/html], Cache-Control:[no-store, no-cache, must-revalidate, post-check=0, pre-check=0], Content-Encoding:[gzip], Expires:[Thu, 19 Nov 1981 08:52:00 GMT], Server:[lighttpd/1.4.19], Transfer-Encoding:[chunked], Vary:[Accept-Encoding, User-Agent]] Suggest a getCompressedFileExtension() method to Resource.java which checks the file extenstion for common internet compressed file types like jar, zip, gz, tgz, bz2 and if getCompressedFileExtension() is true, don't as for the gzip encoding and don't check for it either. This check would be needed fro http and https. compressed tarball download problems Key: WAGON-264 URL: http://jira.codehaus.org/browse/WAGON-264 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0-beta-2, 1.0-beta-3, 1.0-beta-4, 1.0-beta-5 Reporter: Lee Thompson HTTP wagon will uncompress tarballs it downloads, sometimes badly. Downloading openssl results in an unpressed download $ mvn -X wagon:download-single -Dwagon.fromFile=openssl-0.9.8k.tar.gz -Dwagon.url=http://www.openssl.org/source -Dwagon.toDir=./ $ tar tzf openssl-0.9.8k.tar.gz gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error exit delayed from previous errors $ tar tf openssl-0.9.8k.tar.gz | more openssl-0.9.8k/apps/ openssl-0.9.8k/apps/app_rand.c Downloading expat results in a corrupted file mvn -X wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz -Dwagon.url=http://prdownloads.sourceforge.net/expat -Dwagon.toDir=./ $ tar tf expat-1.98.8.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Read 1943 bytes from expat-1.98.8.tar.gz tar: Error exit delayed from previous errors -- 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: (WAGON-264) compressed tarball download problems
compressed tarball download problems Key: WAGON-264 URL: http://jira.codehaus.org/browse/WAGON-264 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0-beta-5, 1.0-beta-4, 1.0-beta-3, 1.0-beta-2 Reporter: Lee Thompson HTTP wagon will uncompress tarballs it downloads, sometimes badly. Downloading openssl results in an unpressed download $ mvn -X wagon:download-single -Dwagon.fromFile=openssl-0.9.8k.tar.gz -Dwagon.url=http://www.openssl.org/source -Dwagon.toDir=./ $ tar tzf openssl-0.9.8k.tar.gz gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error exit delayed from previous errors $ tar tf openssl-0.9.8k.tar.gz | more openssl-0.9.8k/apps/ openssl-0.9.8k/apps/app_rand.c Downloading expat results in a corrupted file mvn -X wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz -Dwagon.url=http://prdownloads.sourceforge.net/expat -Dwagon.toDir=./ $ tar tf expat-1.98.8.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Read 1943 bytes from expat-1.98.8.tar.gz tar: Error exit delayed from previous errors -- 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: (MCHANGES-138) Exception thrown when issueManagement section of pom is missing
[
http://jira.codehaus.org/browse/MCHANGES-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157431#action_157431
]
Lee Thompson commented on MCHANGES-138:
---
Even if you have issueManagement defined, %URL% and %ISSUE% won't expand in
maven-changes-plugin v2.1 downgrading gets your changes report working again.
Exception thrown when issueManagement section of pom is missing
---
Key: MCHANGES-138
URL: http://jira.codehaus.org/browse/MCHANGES-138
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: jira-report
Affects Versions: 2.1
Reporter: Mark Derricutt
Priority: Minor
When the issueManagement/ section of a pom is missing, the following
exception is thrown. The plugin should explain
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to extract
JIRA issues from the downloaded file
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:931)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:767)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:529)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
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:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to extract
JIRA issues from the downloaded file
at
org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:630)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.doJiraGenerate(AnnouncementMojo.java:578)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:335)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:397)
at
org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:612)
... 23 more
{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: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=149708#action_149708
]
Lee Thompson commented on MNG-3438:
---
Is this a bug in the plexus-archiver POM? Should a bug be logged on it?
IIncompatibleClassChangeError
-
Key: MNG-3438
URL: http://jira.codehaus.org/browse/MNG-3438
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.9
Reporter: Vincent Massol
Assignee: Vincent Massol
This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
{noformat}
[INFO]
[INFO] Building XWiki Platform - Applications - Selenium
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
[INFO] [remote-resources:process {execution: xwiki-license-resources}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING] Attempting to build MavenProject instance for Artifact
(com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
type: maven-plugin; constructing POM artifact instead.
[INFO] [xwiki-xar:xar]
[INFO] Generating package.xml descriptor at
[/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
[FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
(java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
realms:
[FATAL ERROR] Plugin realm =
app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
urls[0] =
file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
urls[1] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
urls[2] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
urls[3] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
urls[4] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
urls[5] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
urls[7] =
file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
[FATAL ERROR] Container realm = plexus.core
urls[0] =
file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
urls[1] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
urls[2] =
file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.IncompatibleClassChangeError
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:331)
at
[jira] Commented: (MCLEAN-28) maven-clean-plugin doesn't delete directories with symlinks in them
[ http://jira.codehaus.org/browse/MCLEAN-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148241#action_148241 ] Lee Thompson commented on MCLEAN-28: works! maven-clean-plugin doesn't delete directories with symlinks in them --- Key: MCLEAN-28 URL: http://jira.codehaus.org/browse/MCLEAN-28 Project: Maven 2.x Clean Plugin Issue Type: Bug Affects Versions: 2.2 Environment: maven 2.0.7, Ubuntu 7.10, Intel Pentium M Reporter: Steinar Bang Assignee: Benjamin Bentmann Fix For: 2.3 Note: this issue did not happen with maven-2.0.4 and maven-clean-plugin 2.1.1. I have a maven project for a JNI library wrapping several shared libs. For testing, the shared libs are unpacked into target/tmplib, and the maven-surefire-plugin gets a LD_LIBRARY_PATH enviroment variable setting pointing to this directory. The shared libs are unpacked in a manner that preserves their symbolic links, eg. lrwxrwxrwx 1 sb sb 17 Dec 23 22:00 libxml2.so - libxml2.so.2.6.23 lrwxrwxrwx 1 sb sb 17 Dec 23 22:00 libxml2.so.2 - libxml2.so.2.6.23 -rwxr-x--- 1 sb sb 3104024 Nov 28 13:23 libxml2.so.2.6.23 lrwxrwxrwx 1 sb sb 13 Dec 23 22:00 libz.so - libz.so.1.2.3 lrwxrwxrwx 1 sb sb 13 Dec 23 22:00 libz.so.1 - libz.so.1.2.3 -rwxr-x--- 1 sb sb 168053 Nov 28 13:08 libz.so.1.2.3 When doing mvn clean it refuses to delete target/tmplib (see the error message with stack trace below), and when I inspect the target/tmplib directory, it contains only symlinks. The files they point to have been removed. Using the example above, it now looks like: lrwxrwxrwx 1 sb sb 17 Dec 23 22:00 libxml2.so - libxml2.so.2.6.23 lrwxrwxrwx 1 sb sb 17 Dec 23 22:00 libxml2.so.2 - libxml2.so.2.6.23 lrwxrwxrwx 1 sb sb 13 Dec 23 22:00 libz.so - libz.so.1.2.3 lrwxrwxrwx 1 sb sb 13 Dec 23 22:00 libz.so.1 - libz.so.1.2.3 The error message with stack trace, looks like this: [INFO] [clean:clean] [INFO] Deleting directory /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to delete directory: /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target. Reason: Unable to delete directory /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target/tmplib [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to delete directory: /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target. Reason: Unable to delete directory /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target/tmplib at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to delete directory: /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target. Reason: Unable to delete directory /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target/tmplib at
