On 2011-09-14, Emmanuel Bourg wrote:
Le 14/09/2011 17:16, Stefan Bodewig a écrit :
Emmanuel, is the Pack200Utils.normalize method I've just committed what
you've been looking for?
Yes that's what I had in mind, thank you.
You might also want to support repacking a file to itself, that's
On 2011-09-15, Emmanuel Bourg wrote:
Le 15/09/2011 11:46, Stefan Bodewig a écrit :
BTW, I've added pack200 support to the Compress Antlib (tasks and a
pack200resource) and will push for a release once CC 1.3 is out.
Pack200 tasks available out of the box with Ant would be really nice
On 2011-09-22, Simone Tripodi wrote:
sorry for the silly question but I lost the svn location place where
[functor] gump metadata are configured
https://svn.apache.org/repos/asf/gump/metadata/project/commons-proper.xml
... how I can update it?
You probably don't need to. Sebb had changed
On 2011-09-27, simonetrip...@apache.org wrote:
fixed broken tests notified by Gump (broken on Java5, worked on Java6...)
Gump is running on OpenJDK 6 right now, so it probably is not a version
but maybe an implementation (Apple, IBM or Oracle vs OpenJDK)
difference?
Stefan
On 2011-09-27, Bill Speirs wrote:
So the issue has been fixed?
If not, can we get the output of
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports?
I'll make sure Gump publishes them on subsequent runs.
Stefan
Hi all,
its been quite some time since I finished the Zip64 stuff and I think we
are at the point we discussed three month ago or so: release Compress
1.3 even if it doesn't have many big changes when compared to 1.2. In
addition to Zip64 we have read-only support for Unix dump and also
Pack200
On 2011-10-11, Gary Gregory wrote:
On Tue, Oct 11, 2011 at 10:20 AM, Stefan Bodewig bode...@apache.org wrote:
Hi all,
its been quite some time since I finished the Zip64 stuff and I think we
are at the point we discussed three month ago or so: release Compress
1.3 even if it doesn't have
On 2011-10-11, sebb wrote:
On 11 October 2011 15:20, Stefan Bodewig bode...@apache.org wrote:
One thing that we may or may not want to address are the integration
tests for Zip64 which are currently only run when the run-it profile is
enabled. These tests need some zips generated by other
On 2011-10-11, Gary Gregory wrote:
On Tue, Oct 11, 2011 at 11:21 AM, Stefan Bodewig bode...@apache.org wrote:
On 2011-10-11, Gary Gregory wrote:
On Tue, Oct 11, 2011 at 10:20 AM, Stefan Bodewig bode...@apache.org
wrote:
One thing that we may or may not want to address are the integration
On 2011-10-17, Gary Gregory wrote:
On Mon, Oct 17, 2011 at 10:16 AM, Stefan Bodewig bode...@apache.org wrote:
On 2011-10-11, Gary Gregory wrote:
On Tue, Oct 11, 2011 at 11:21 AM, Stefan Bodewig bode...@apache.org
wrote:
On 2011-10-11, Gary Gregory wrote:
On Tue, Oct 11, 2011 at 10:20 AM
Hi all,
I've added a tar.bz2 holding the eleven zips needed to run all tests in
Zip64SupportIT to svn trunk and use the antrun plugin to trigger Ant's
untar task to extract them before running the tests.
The may be better ways to do it. I thought the depedency plugin might
be able to help but
Hi all,
I'd like to get a clean RAT report which means excluding some of the
test resources as RAT doesn't recognize ARs and CPIOs as binaries. The
RAT version used by parent version 20 doesn't support excludes, RAT 0.7
used by parent 22 does.
I've modified the POM locally, ran the tests and
Hi all,
XZ for Java has landed in Maven Central[1] (thanks, Lasse!) and together
with COMPRESS-156 it would be pretty easy to add support for XZ
compression.
The patch in COMPRESS-156 comes without tests or docs but either are
very easy to create as clones of the GZip counterparts.
Do we want
On 2011-10-24, Torsten Curdt wrote:
Do we want to add XZ support now or wait until after 1.3 has been
released?
In either case I'd intend to call for a vote on a first RC for Compress
1.3 no later than next week.
I would skip it for this release.
This seems to be consensus, expect an RC1
On 2011-10-25, sebb wrote:
On 25 October 2011 09:50, Torsten Curdt tcu...@vafer.org wrote:
So I would only release the shaded jar.
IIRC sebb objected to shading.
Why was that, sebb?
I don't recall saying that I objected; I did wonder what advantage it
would give.
Probably I read more
Compress 1.3 RC1 is available for review here:
http://people.apache.org/~bodewig/commons-compress/
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-101/org/apache/commons/commons-compress/1.3/
Details of changes since 1.1 are in the
On 2011-10-26, Stefan Bodewig wrote:
Compress 1.3 RC1 is available for review here:
http://people.apache.org/~bodewig/commons-compress/
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-101/org/apache/commons/commons-compress/1.3
On 2011-10-26, Emmanuel Bourg wrote:
The test coverage of Pack200CompressorInputStream is a bit low, the
read methods do not seem to be tested.
Only the three-arg version is used, this is true.
I'll look into getting more coverage in trunk so it will improve with
the next release (or the next
On 2011-10-26, Stefan Bodewig wrote:
On 2011-10-26, Emmanuel Bourg wrote:
The test coverage of Pack200CompressorInputStream is a bit low, the
read methods do not seem to be tested.
Only the three-arg version is used, this is true.
I'll look into getting more coverage in trunk so
Hi all,
Michael Kuß' request to get his name fixed is important enough to me to
roll a new RC.
I'll also address the points raised by Gary, please don't stop pointing
out other flaws I may be able to fix at the same time as I dont expect
to be able to cut the next RC before in about 36 hours.
On 2011-10-26, Gary Gregory wrote:
On Wed, Oct 26, 2011 at 9:18 AM, Gary Gregory garydgreg...@gmail.comwrote:
On Wed, Oct 26, 2011 at 8:55 AM, Simone Tripodi
simonetrip...@apache.orgwrote:
Hi Gary!
OK so it is expected because revision number neither SCM branch can be
determined since
On 2011-10-25, sebb wrote:
On 25 October 2011 16:41, Stefan Bodewig bode...@apache.org wrote:
That would be easiest but at the same time force an additional
dependency for people who don't use XZ at all. One they could
explicitly exclude in their POM or ivy.xml or whatever, of course.
Can
On 2011-10-25, Jörg Schaible wrote:
Stefan Bodewig wrote:
From the POV of the Compress Antlib for example I now need to tell
people to fetch Common Compress and in the future Id have to tell them
to fetch XZ as well. Then again this is a problem I should solve over
there.
Couldn't you
On 2011-10-26, Gary Gregory wrote:
in trunk now, the following have 0% code coverage according to
Cobertura:
- Lister
really only a demo-class.
- DumpArchiveConstants: How can it have 0% when it is used? Does Cobertura
know how to deal with enums?
It outer class doesn't have any methods,
On 2011-10-26, Gary Gregory wrote:
I would also remove or add comments as to why these are needed in
org.apache.commons.compress.archivers.jar.JarArchiveEntry:
@Override
public boolean equals(Object o) {
return super.equals(o);
}
@Override
public int
On 2011-10-26, Gary Gregory wrote:
Also should be fixed but not show stoppers:
[snip those fixed in trunk now]
DescriptionResourcePathLocationType
Unnecessary cast from byte to longDumpArchiveUtil.java
Hi all,
compared to RC1 Michael Kuss' name has been fixed and he's been added as
contributor. A bunch of additional tests increased coverage (still some
areas are not covered but coverage is better than it has been for any
prior release). A few plugins have been upgraded.
Compress 1.3 RC2 is
On 2011-10-28, Stefan Bodewig wrote:
Compress 1.3 RC2 is available for review here:
http://people.apache.org/~bodewig/compress-1.3-RC2/
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-111/org/apache/commons/commons-compress/1.3
On 2011-10-31, Bear Giles wrote:
I found a few issues (1330) with Fortify. As anyone who's used it knows the
vast majority of those are of the but that's what I intended variety, but
there were 180 cases of unclosed resource streams and 354 cases of
potential denial of service.
In the first
Hi all,
the vote has passed with four +1s by Emmanuel, Jörg, Gary and myself. I
will now proceed with the publish, wait for mirrors, update site, send
announcement process.
Thanks to all who checked the release
Stefan
Compress, including instructions
on how to submit bug reports, patches, or suggestions for improvement,
see the Apache Commons Compress website:
http://commons.apache.org/compress/
Stefan Bodewig, on behalf of the Apache Commons community
On 2011-11-09, sebb wrote:
Test output says:
java.lang.NoClassDefFoundError:
org/apache/mina/filter/executor/OrderedThreadPoolExecutor
I assume Gump needs to be told about the dependency.
That would be a dependency on MINA, it seems. I've added it but I don't
expect it to help. It seems
On 2011-11-10, Gary Gregory wrote:
Hm... how do I tell Gump about the new deps?
edit the project's descriptor which happens to be
http://svn.apache.org/repos/asf/gump/metadata/project/commons-proper.xml
See http://gump.apache.org/metadata/ for more details.
Stefan
On 2011-11-13, Gary Gregory wrote:
On Thu, Nov 10, 2011 at 4:16 AM, Stefan Bodewig bode...@apache.org wrote:
It seems as if VFS was already picking up Mina built from trunk and
this version is not compatible with the one VFS2 expects (i.e. it
doesn't provide the oa.mina.filter package
The Mina issue is resolved, tests now fail for a different reason.
See for example
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/gump_file/org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase.txt.html
Stefan
On 2011-11-15, Gary Gregory wrote:
Well, that's better, one step closer, to look at this positively.
I suppose debugging Gump remotely is as impossible as debugging
Continuum remotely.
Probably.
Before you invest more time into this let me try to build VFS2 on vmgump
but outside of Gump so
Hi Oliver,
On 2011-12-02, ohe...@apache.org wrote:
Another attempt to fix the GUMP build using an ugly cast.
Seeing you jumping through these hoops I wonder whether it wouldn't be
better to look at the core issue. If configuration's compilation only
fails in Gump this means there is an API
On 2011-12-03, Oliver Heger wrote:
Is configuration's dependency on Digester new or why have we started to
see this error just now? You may want to upgrade to Digester 2.0 or 2.1
to start with (or even Digester3?) if it is new. If it isn't then
obviously 2.x isn't compatible enough to 1.x
On 2011-12-03, William Speirs wrote:
I also added my fingerprint to LDAP and I've created a RDF file as
well, but again I don't yet see my info here:
http://people.apache.org/committers.html Again, I'm guessing/hoping
that it just takes a while to perform the sync.
There are a bunch of shell
On 2011-12-02, henrib wrote:
It seems to me we have a hard time allowing both stability and usability.
Stability of APIs does not contradict usability of the library, at least
should not.
I'm glad you say that right at the beginning as the versus in the
subject line seems to imply something
On 2011-12-04, henrib wrote:
When trying to release JEXL 2.1, the API was disrupted and the clirr report
was outputing lots of clutter.
As the dev, it became very hard to understand whether the change was
actually breaking the intended stable API or just some internal methods or
class.
On 2011-12-21, Mark Thomas wrote:
The Tomcat project is cleaning up Gump and removing old, unsupported
Tomcat versions (that also probably have security vulnerabilities).
JCS currently has an optional dependency on jakarta-tomcat (Tomcat
3.3.x). Since I will be removing jakarta-tomcat from
On 2011-12-26, Konstantin Kolinko wrote:
2011/12/26 Oliver Heger oliver.he...@oliver-heger.de:
Which version of JUnit is used by GUMP? According to the Javadocs for
version 4.10, there should be a method TemporaryFolder.newFile() with an
empty argument list.
On 2012-02-28, sebb wrote:
On 28 February 2012 05:00, bode...@apache.org wrote:
protected void setName(String name) {
+ if (name != null getPlatform() == PLATFORM_FAT
+ name.indexOf(/) == -1) {
+ name = name.replace('\\', '/');
+ }
On 2012-03-05, sebb wrote:
The tests also fail in Gump.
vmgump.ao, gump.zones.ao and adam.ao run JDK 6 (vmgump uses OpenJDK, the
FreeBSD zone the FreeBSD port and adam the MacOS X version by Apple).
So it likely is not a Java7 issue.
Gump uses mvn2 to run the tests if that causes any
On 2010-12-01, Henri Yandell wrote:
I've fixed this in r1040879.
I can confirm it is fixed for Gump as well. I removed all awt.headless
settings from the Gump descriptor and the build still passes on adam.
Thanks!
Stefan
-
Hi,
This - and most other mvn built projects - fail during the current Gump
run because the Maven repo returns an HTML page indicating a 404 error
for the SHA1 checksums.
http://repo1.maven.org/maven2/org/apache/commons/commons-parent/17/commons-parent-17.sha1
Maven seems to ignore the HTTP
On 2010-12-02, sebb wrote:
On 2 December 2010 11:10, Stefan Bodewig bode...@apache.org wrote:
This - and most other mvn built projects - fail during the current Gump
run because the Maven repo returns an HTML page indicating a 404 error
for the SHA1 checksums.
http://repo1.maven.org/maven2
On 2010-12-08, Gump wrote:
/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchTransformer.java:[68,38]
invalid inferred types for T; actual arguments do not conforms to inferred
formal arguments
required:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-jci-core has an issue affecting its community integration.
This
On 2011-02-11, Gump wrote:
[javac]
/srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:245:
incompatible types
[javac] found : com.thoughtworks.qdox.model.JavaPackage
[javac] required:
On 2011-03-03, Gump wrote:
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/commons-vfs-1.x/examples/src/main/java/org/apache/commons/vfs/libcheck/FtpCheck.java:[75,46]
cannot find symbol
symbol : method
Hi,
the recent Gump failures occur because commons-net has removed a
deprecated method that VFS uses. The recommended replacement of the
method is not available in commons-net 2.0 (which trunk depends on) so
in order to adapt to the changes VFS would need to upgdare to
commons-net 2.2.
Would
On 2011-03-04, Jörg Schaible wrote:
Stefan Bodewig wrote:
the recent Gump failures occur because commons-net has removed a
deprecated method that VFS uses. The recommended replacement of the
method is not available in commons-net 2.0 (which trunk depends on) so
in order to adapt
Hi Jörg,
On 2011-03-04, Jörg Schaible wrote:
Since gump messages came in: vfs-1 will not be updated anyway ...
As in vfs-1 is no longer under any kind of development? If so, we
should probably remove it from Gump anyway.
Stefan
On 2011-03-04, Jörg Schaible wrote:
Stefan Bodewig wrote:
On 2011-03-04, Jörg Schaible wrote:
Since gump messages came in: vfs-1 will not be updated anyway ...
As in vfs-1 is no longer under any kind of development?
Yes.
If so, we should probably remove it from Gump anyway.
Could
On 2011-03-04, Ralph Goers wrote:
On Mar 4, 2011, at 1:44 AM, Jörg Schaible wrote:
Actually the usage of net 2.2 would be better then, but Ralph should
agree in the current vfs stage.
OK - if 2.2 is released then I have no problem in changing the
dependency and changing whatever code is
On 2011-03-04, Matt Benson wrote:
Another interesting concept mentioned in this article is the
summarized by the statement Another way of formalizing tuples is as
nested ordered pairs. I would argue that this is the only efficient
way to formally represent an n-tuple using Java generics
On 2011-03-04, Jörg Schaible wrote:
Stefan Bodewig wrote:
* for the Ant built projects that depend on vfs (Ivy, log4j-chainsaw and
vfs2-sandbox) I'll make the 1.0 jar available.
When all of them require normally the release, it's fine.
Ivy seems to build fine, the chainsaw build hasn't
On 2011-04-10, Gary Gregory wrote:
Will that break gump?
It would have, yes. The current metadata tell Gump to use Ant for
building discovery. Given that discovery doesn't have too many
dependencies switching Gump to use mvn instead wouldn't be a big issue.
Using mvn for something as high up
On 2011-04-18, Adrian Crum wrote:
A suggestion: if the library has logging capability, then log a
warning saying that the archive was closed in the finalize
method. That will serve as a clue to the library user that they forgot
to close the archive.
You are right, but commons-compress
On 2011-04-18, Phil Steitz wrote:
The problem is that without logging in to vmbuild, there does not
appear to be a way to get to /target and see all the little
surefire-reports files that maven creates so you can see which test
case failed. Does anyone know of a way to get to /target online?
On 2011-04-19, sebb wrote:
On 19 April 2011 06:39, bode...@apache.org wrote:
URL:
http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1094857r1=1094856r2=1094857view=diff
On 2011-04-19, sebb wrote:
On 19 April 2011 06:35, bode...@apache.org wrote:
// this flag is only written here and read in finalize() which
// can never be run in parallel.
// no synchronization needed.
Are you sure?
At least as long as finalize is not called by
this is the digester = digester3 move.
I'll take care of renaming the project in Gump an all that.
Meanwhile I assume digester3 won't be binary or even source code
compatible with 2.x so we'll need to provide Digester 2.x for the
projects depending on it.
Are you expecting to ever do a 2.x
On 2011-06-16, Rahul Akolkar wrote:
As Jakarta winds down, we are looking for sustainable homes for couple
of Java libraries -- BCEL [1] and JCS [2]. These aren't very different
from many Commons libraries in size, number of developers, list
traffic etc. Would Commons be interested in
On 2011-06-26, Rahul Akolkar wrote:
This is half a dozen related votes in one thread (for convenience), namely:
1. Accept BCEL [1] as Commons component
1a. Grant Commons karma to Dave Brosius (dbrosius)
2. Accept JCS [2] as Commons component
2a. Grant Commons karma to Aaron Smuts (asmuts)
On 2011-07-18, Torsten Curdt wrote:
I'm all for it.
I say what I've said all this time when questions like this came up.
We need testers! There has been quite few changes. Just releasing
without some people spending some time ...or telling us yes, trunk
works for me! I am still not
On 2011-07-19, Torsten Curdt wrote:
I say what I've said all this time when questions like this came up.
We need testers! There has been quite few changes. Just releasing
without some people spending some time ...or telling us yes, trunk
works for me! I am still not comfortable with.
trunk
Hi,
I was looking through some old stuff we postponed last year when we
released Compress 1.1. One of them is COMPRESS-18 where I provided a
patch but didn't commit it.
Our JAR package doesn't provide the stuff java.util.jar does and is
actually pretty useless - there isn't anything in it not
On 2011-07-20, Torsten Curdt wrote:
Personally I don't expect anybody to use the JAR package at all today
so I'd do with a warning, apply the patch and keep 1.2 as the version
number for the next release. Other options would be the convoluted
implementation, just don't fix it or a bump to
On 2011-07-20, Gary Gregory wrote:
On Wed, Jul 20, 2011 at 5:30 PM, Torsten Curdt tcu...@vafer.org wrote:
Personally I don't expect anybody to use the JAR package at all today
so I'd do with a warning, apply the patch and keep 1.2 as the version
number for the next release. Other options
Hi,
no, this is not about generics or enums or ...
This time it is methods added in the classlib, in particular
java.util.zip.Inflater#getBytesRead and friends which return longs
rather than ints that are returned by getTotalIn.
Since ZIP entry size is an unsigned four byte int even without
On 2011-07-21, Christian Grobmeier wrote:
If we lift up to 1.5 as a minimum what about lifting to compress 2.0?
Depends on what we want to do. If we want to break BWC by introducing
genrics, then let's do that. I am currently withholding some work I
started to get the permissions stuff
On 2011-07-21, luc.maison...@free.fr wrote:
The problem seems to come from reading resource test files, see
http://vmgump.apache.org/gump/public/apache-commons/commons-math/gump_file/TEST-org.apache.commons.math.linear.SingularValueDecompositionImplTest.txt.html.
Is there something specific
On 2011-07-21, Christian Grobmeier wrote:
On Thu, Jul 21, 2011 at 10:44 AM, Stefan Bodewig bode...@apache.org wrote:
On 2011-07-21, Christian Grobmeier wrote:
If we lift up to 1.5 as a minimum what about lifting to compress 2.0?
Depends on what we want to do. If we want to break BWC
Hi all,
From the responses in the Java5 thread I propose the following.
(1) Release current trunk minus a few lines of code I already added for
initial Zip64 support plus some minor changes ASAP as 1.2
(2) Require Java5, use minimal Java5 language features to make compiler
warnings go
On 2011-07-21, sebb wrote:
On 21 July 2011 09:48, Stefan Bodewig bode...@apache.org wrote:
Done with http://svn.apache.org/viewvc?view=revisionrevision=1149079
unless I managed to get the path wrong.
Although that may fix the issue for Gump, I think that's the wrong
place to fix
Hi,
for reference https://issues.apache.org/jira/browse/COMPRESS-128
The bzip2 inputstream checks whether its wrapped input stream is
System.in before closing it. Do we want to add the same behavior to all
other implementations or do we want to remove it from the bzip2 one and
leave it to the
Hi,
I've moved some JIRA issues that are clear they'll need to break the API
to 2.0 and assigned a few JIRAs where a patch is available or I would
know how to implement them to 1.2 and 1.3.
Please review
On 2011-07-23, Simone Tripodi wrote:
I personally like more the NoCloseStream approach, it would help
avoiding code redundancies (having the Sysout check pattern repeated
doesn't look nice IMHO)
Yes, that would be my preference as well.
Stefan
On 2011-07-23, Simone Tripodi wrote:
I think it would be nice having also s pure Java implementation of the
Snappy[1] compression (the Google's compression),
Absolutely, it is just a matter of getting it coded 8-)
I found a Java implementation[2] but it's JNI wrapper :/
Well, that could be
Hi,
in Compress we have quite a few classes that use constants that deal
with Unix permission flags, those are most naturally expressed as octals
so I'd like to modify the basic ruleset to exclude the
AvoidUsingOctalValues rule.
I'm not familiar with the PMD plugin but think the easiest way to
On 2011-07-23, Phil Steitz wrote:
On 7/23/11 5:48 AM, Stefan Bodewig wrote:
I'm not familiar with the PMD plugin but think the easiest way to do
that is by adding a rules file of my own that refs the basic ruleset
excluding the octal rule. Is there some sort of standard location in
mvn
Hi all,
some components keep the Javadocs for older versions online in addition
to the ones of the current release. In our case the Javadocs for 1.2
won't be too different from the ones of 1.1, so I don't think it is
worthwhile, but still I'd like to double check.
Does anybody want the Javadocs
Hi all,
given that most discussion has only been started late last week, it has
been a bit unorganized and some things have moved during the weekend
I'll give it a bit more time to settle.
IMHO svn trunk is ready to be released and likely won't change except
for release notes, version numbers
On 2011-07-25, luc.maison...@free.fr wrote:
If the URL do include the version, then it would be better to keep old
version online, to avoid dangling links from external web pages, mail
archives or documentation.
Good point, thanks Luc. The Javadoc URLs for Compress currently don't
contain a
On 2011-07-21, sebb wrote:
However just doing that without adding @Override and minimal generics
will result in compilation warnings; it seems wromg to release source
that does not compile cleanly.
The zip64 branch now requires Java5 but I'm having a hard time seeing
any compiler warnings.
Hi,
ZIP64 is all about supporting archives with entries bigger than 4GB and
archives with more than 65355 entries so it comes as no surprise that
test archives for ZIP64 are big.
Right now I'm working with two archives, one contains a single file that
consists of 5e9 zeros, the InfoZIP generated
On 2011-07-26, Gary Gregory wrote:
For small files I would not worry, the [sanselan] test data
directory is 80MB and no one is complaining.
Really? My DSL provider still cannot offer me more than 3MBit/s and
this is close to the city center in a town 250k citizens in Germany, I
could imagine
Hi,
I just did a mvn release:prepare for Compress and it failed in the
tagging stage.
Since I live in Germany I access our EU svn mirror and the revision that
I had created for the non-SNAPSHOT POM had not been replicated back to
the mirror so it failed with no such revision. This is something
Tag:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.2_RC1/
Site:
http://people.apache.org/~bodewig/commons-compress-1.2RC1/site/
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecommons-004/org/apache/commons/commons-compress/1.2/
On 2011-07-27, Konstantin Kolinko wrote:
2011/7/27 Stefan Bodewig bode...@apache.org:
Hi,
I just did a mvn release:prepare for Compress and it failed in the
tagging stage.
Since I live in Germany I access our EU svn mirror and the revision that
I had created for the non-SNAPSHOT POM had
On 2011-07-26, Ted Dunning wrote:
On Tue, Jul 26, 2011 at 5:31 AM, Stefan Bodewig bode...@apache.org wrote:
Perhaps the large test files could be generated on the fly if absent
in the user's temp directory?
This would require 5 GB of disk space in temp and a working ZIP64
implementation
On 2011-07-27, Jörg Schaible wrote:
Different approach: Create out of them separate Maven artifacts.
This probably is what I had in mind when I suggested to move them -
along with the testcases - somewhere outside of trunk. I just didn't
know the proper nomenclature and likely don't know how
On 2011-07-27, sebb wrote:
On 27 July 2011 06:03, Stefan Bodewig bode...@apache.org wrote:
Tarballs/ZIPs:
http://people.apache.org/~bodewig/commons-compress-1.2RC1/
[ ] +1 release it
[ ] +0 go ahead I don't care
[X] -1 no, do not release it because
The source archives contain
On 2011-07-27, Torsten Curdt wrote:
But to be clear: this is quite some work just to safe some disk space
for people who check out the whole of commons but do not care about
compress.
Actually my main concern was/is the size of the source distribution and
network bandwidth rather than disk
Tag:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.2_RC2/
Site:
http://people.apache.org/~bodewig/commons-compress-1.2RC2/site/
Tarballs/ZIPs:
http://people.apache.org/~bodewig/commons-compress-1.2RC2/
Maven artifacts:
On 2011-07-27, sebb wrote:
Aside:
Seems wrong that site plugin creates output under src/site - surely it
should be created under target?
Is there a bug in the POM or the Commons Parent POM - or is it a bug
in the site plugin?
Apart from the obvious fact that I don't know what I do when I
Hi all,
at least for Compress mvn -Prc package (or any variation I have tried)
does not create the tarballs/zips and for the last two RCs I've created
them manually with assembly:single and a bash one-liner to create the
checksums/PGP sigs.
Am I doing anything wrong or is there anything wrong in
101 - 200 of 1182 matches
Mail list logo
