RE: dependency:unpack unzipping .tgz files after HTTP downloads

["Brian E. Fox" <br...@reply.infinity.nu>]

Steinar,
Putting explicit versions should force it. The only caveat is that it
seems that once maven picks a version in a multi-module build, it uses
that throughout the build, regardless of individual poms.

Looking over the change log[1], I don't see anything that would affect
this between the builds. Certainly alpha-2,3,4 are identical with
regards to the copy/unpack mojos as the only difference in 3&4 where new
analyze mojos.

[1]
http://jira.codehaus.org/browse/MDEP?report=com.atlassian.jira.plugin.sy
stem.project:changelog-panel

--Brian

-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Steinar Bang
Sent: Saturday, March 31, 2007 3:26 PM
To: users@maven.apache.org
Subject: dependency:unpack unzipping .tgz files after HTTP downloads

Platform: Win32, 
	  maven-2.0.4,
	  maven-dependency-plugin 2.0-alpha-3 and 2.0-alpha-4

People at work, following my development environment setup howtos,
have started complaining to me that dependency:unpack of .tgz files
fails. 

What seems to be happening is that responses with these headers
 Content-Type: application/x-tar
 Content-Encoding: gzip
causes the file to be ungzipped after download (what's in the users'
maven repos are files of 42MB instead of the expected 8MB, and that
are actually tar files, in spite of the .tgz extension).

I've had the people who've had the problem look at the contents of
their 
 
%HOMEDRIVE%%HOMEPATH%/.m2/repository/org/apache/maven/plugins/maven-depe
ndency-plugin/
directories.

One reported 2.0-alpha-3, and one reported 2.0-alpha-4.  I seem to
have 2.0-alpha-1, and haven't seen the issue on neither Win32 nor
linux. 

I asked the person with 2.0-alpha-3 to put
<version>2.0-alpha-1</version> in the <plugin> configs, but that
didn't help the issue for him.

I haven't reported this as a Jira issue, since I haven't seen it
myself (and am reluctant to break my setup to try to reproduce
it...:-) ).

Is there a way I can upgrade, and then safely downgrade?  Putting in
explicit <version> tags didn't seem to be enough.

Thanx!


- Steinar


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: dependency:unpack unzipping .tgz files after HTTP downloads

[Steinar Bang <sb...@dod.no>]

>>>>> "Brian E. Fox" <br...@reply.infinity.nu>:

> Putting explicit versions should force it. The only caveat is that
> it seems that once maven picks a version in a multi-module build, it
> uses that throughout the build, regardless of individual poms.

> Looking over the change log[1], I don't see anything that would
> affect this between the builds.

Neither did I.  Turns out the problem is with maven-2.0.5, that others
had been installing, since had become the default maven release.

If I build with maven-2.0.5 I see the issue, if I build with
maven-2.0.4 (without any local repo changes, except deleting the
offending ungzipped .tgz files), it goes away.

So my guess is that the issue is with the built-in HTTP support of
maven, rather than in any plugins.

Since 2.0.6 seems to be the current maven release, I tried it as
well.  But 2.0.6 got a null pointer exception trying to build our
maven project.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org