Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/3#issuecomment-151607463
Oops, this looks bigger than intended :-)
It seems as if out migration to git has made the wrong branch the default
branch. I'll ask the ASF infra team
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/3#issuecomment-151728703
Don't feel forced to create a pull request just because we are using git
now. The established workflow of attaching a patch to JIRA is still in place
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/4#issuecomment-155670599
Thanks a lot!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/5#issuecomment-164276454
Thanks
I've merged you patch have a few questions - and would like to see tests
:-) Not sure whether you'd prefer to discuss this here, inside a new PR
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/8#issuecomment-188288771
merged, many thanks.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/11#issuecomment-197788653
I had naively assumed `InflaterInputStream#close` would free up the
resources. Come to think of it, if we pass in the `Inflater` ourselves it makes
sense
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/10#issuecomment-192735255
Thanks a lot Matt, this makes things quite a bit more consistent.
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
For starters, https://github.com/bodewig/commons-compress-benchmarks -
right now I'm not sure where it'll end up.
---
If your project is set up for it, you can reply to this email and have
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/16
True, a unit-test wouldn't hurt.
I'm afraid I can't close the PR myself.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
I'm planning to set up a JMH based benchmark soonish and would like to get
some statistical information before merging this.
---
If your project is set up for it, you can reply
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/16
Hmm, the no-arg `read` returns the byte read. So when reading an `'A'` your
code would count 65 bytes rather than 1, wouldn't it?
---
If your project is set up for it, you can reply
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
@thomasmey I've made some minor changes and pushed it to the branch PR13
My benchmarks at
https://github.com/bodewig/commons-compress-benchmarks/wiki/PR13 sees the
changed code
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
Sorry, I didn't realize you had updated the PR, will have a look later.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/commit/56e82da90f1064c23dd630cf0066231567da3ed6#commitcomment-20502548
In
src/main/java/org/apache/commons/compress/compressors/lz4/BlockLZ4CompressorInputStream.java:
In
src/main/java
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/commit/56e82da90f1064c23dd630cf0066231567da3ed6#commitcomment-20498632
In
src/main/java/org/apache/commons/compress/compressors/lz4/BlockLZ4CompressorInputStream.java:
In
src/main/java
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
Some rough comparisons for larger files would be a good indicator.
The existing code is pretty ugly because this seemed to be necessary for
acceptable performance back then. "
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/15
Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/14
Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/12
Don't worry about Coveralls, I see the same behaviour for other projects as
well.
I think this is related to our Travis CI setup using different JDKs and
Coveralls picks whichever
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/17
Great, many thanks,
I've just found
https://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt states
> The CRC format is identical to the new ASCII format descri
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838584
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -,14 +1122,11 @@ public int read() throws IOException
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r112810573
--- Diff:
src/test/java/org/apache/commons/compress/compressors/DetectCompressorTestCase.java
---
@@ -167,6 +171,26 @@ private String detect
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
I just realized I had benchmarked compression rather than decompression,
I've now updated
https://github.com/bodewig/commons-compress-benchmarks/wiki/PR13
Fortunately the result
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
@kvr000 what do you think about
https://github.com/apache/commons-compress/commit/620196621e15a87cdd5e3382504bd8a9829f4698
?
---
If your project is set up for it, you can reply
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/27
Thanks, do you think you could re-create the PR without the commits that
belong to #26 ?
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/26
Sorry, I'm currently swamped and won't find time to look into this for the
coming days. @sesuncedu there is a discussion going on on the dev mailing list
that you may want to join ->
ht
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/28#discussion_r122244704
--- Diff:
src/main/java/org/apache/commons/compress/utils/FixedLengthBlockOutputStream.java
---
@@ -0,0 +1,227 @@
+/*
+ * Licensed
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/32
Thanks, Simon. I didn't know this feature.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/33
Thanks a lot.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/33#discussion_r122573708
--- Diff:
src/test/java/org/apache/commons/compress/compressors/xz/XZCompressorOutputStreamTest.java
---
@@ -0,0 +1,51 @@
+/*
+ * Licensed
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/35
Thanks, I had to cherry pick 6f37913 but I think I've got everything merged.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/33
Fortunately I'm not the only one who could merge this :-)
More seriously, it may take a bit of time until I get there, but I will.
---
If your project is set up for it, you can
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/33
Thanks @TheRealHaui
I agree with your comment on
`ChecksumCalculatingInputStreamTest#testGetValueThrowsNullPointerException`
this looks like a bug. So I'd rather remove the test
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/23#discussion_r114257946
--- Diff: pom.xml ---
@@ -68,6 +68,12 @@ jar, tar, zip, dump, 7z, arj.
test
+ org.brotli
+ dec
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/23
Many thanks Philippe
see my comments on the test.
Also I haven't checked whether the brotli lib is an OSGi bundle, we may
need to update the bundle-plugin configuration
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/23#discussion_r114257473
--- Diff: pom.xml ---
@@ -85,6 +91,13 @@ jar, tar, zip, dump, 7z, arj.
${powermock.version}
test
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
Many thanks @kvr000
Have you thought about adding a class implementing `ZipExtraField` for
padding? You could add that to the entry if you detect padding is necessary and
could
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
I don't see a chance of making it independent of `ZipArchiveOutputStream`,
you are certainly correct.
I was thinking along the lines of `ZipArchiveOutputStream` calculates
GitHub user bodewig opened a pull request:
https://github.com/apache/commons-io/pull/52
IO-559 verify hostname part of suspected UNC paths in FileNameUtils
https://issues.apache.org/jira/browse/IO-559
I'm not 100% sure how/if Windows deals with percent encoded hostnames
This is Gump running on commons-graph for the first time it has
re-entered the Sandbox.
I've set it up to run mvn2's install goal on trunk of commons-graph.
vmgump runs openjdk6.
Stefan
-
To unsubscribe, e-mail:
Hi all,
I've been working on COMPRESS-183 which is a more general version of
COMPRESS-114 we fixed a while ago. It asks for support of non-ASCII
file names in tar archives by using an explicit encoding (COMPRESS-114
made things work for ISO-8859-1 and any other encoding that creates the
same
objects. In order to incorporate feedback before I
create the RC I've built the site for review at
http://people.apache.org/~bodewig/commons-compress/
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
On 2012-03-31, sebb wrote:
There are a few places where the default charset is being used.
It's not clear whether these are intentional or not, so I have marked
them with TODOs.
Thanks (and thanks for the other fixes as well).
We should either document that the default is OK, or use a fixed
On 2012-03-31, Christian Grobmeier wrote:
Before ages when I wrote the ChangeSet stuff I have marked them as
experimental. Have not heard any complains yet... we should discuss
if we remove that label or if need some more tweaks there. Probably
after 1.4?
I must admit I've never used that
On 2012-03-31, Gary Gregory wrote:
The trunk looks good now IMO. I'll let others decide about the change set
docs.
The only item that stick out but could wait for another release:
- the large code dup in BZip2CompressorInputStream as noted by CPD.
I've seen that but must admit I didn't see
On 2012-04-01, Ralph Goers wrote:
I have real problems with Gump. I find it very difficult to determine
what the problem actually is much less diagnose it. Other than that I
know it is supposed to be using the latest source in trunk it is tough
to figure out how to reproduce a problem as it
On 2012-04-01, Ralph Goers wrote:
From the vfs2 log it looks like it is running into a binary
incompatibility with SLF4J. vfs2 is specifying SLF4J 1.5.5 but mvn
dependency:tree is showing me that Jackrabbit is referencing
jcl-over-slf4j and is using 1.5.3. I've added that to the vfs2 pom in
On 2012-04-01, Christian Grobmeier wrote:
On Sun, Apr 1, 2012 at 7:01 AM, Stefan Bodewig bode...@apache.org wrote:
On 2012-03-31, Christian Grobmeier wrote:
Before ages when I wrote the ChangeSet stuff I have marked them as
experimental. Have not heard any complains yet... we should discuss
Hi all,
as indicated last weekend Compress' trunk has accumulated so much new
goodness it requires a new release.
Tarballs of Compress 1.4 RC1 are available here
http://people.apache.org/~bodewig/commons-compress-1.4RC1/
Maven artifacts are here:
https://repository.apache.org
On 2012-04-05, sebb wrote:
On 4 April 2012 21:00, Stefan Bodewig bode...@apache.org wrote:
http://people.apache.org/~luckyrm/foo-1.2-RC1/site/
Does not exist; looks like a left-over from an e-mail template.
*blush* - sorry. A bit too much copy-paste 8-)
Stefan
On 2012-04-05, Emmanuel Bourg wrote:
The new Charsets class in the utils package is not used by the code. I
think it should be removed from the API. I'd would also argue that
CharsetNames has not its place in [compress], I would rather stick to
strings and rely on [io] or [lang] to provide an
On 2012-04-05, Emmanuel Bourg wrote:
The new Charsets class in the utils package is not used by the code. I
think it should be removed from the API. I'd would also argue that
CharsetNames has not its place in [compress], I would rather stick to
strings and rely on [io] or [lang] to provide an
Oops, I never voted explicitly.
On 2012-04-04, Stefan Bodewig wrote:
as indicated last weekend Compress' trunk has accumulated so much new
goodness it requires a new release.
Tarballs of Compress 1.4 RC1 are available here
http://people.apache.org/~bodewig/commons-compress-1.4RC1
Hi all,
the vote has passed with six +1s (sebb, Gary, Oliver, Torsten, Jörg and
myself) and no other votes. I'll now proceed with the release process.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
.
For complete information on Commons 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
[1] http
On 2012-04-16, ggreg...@apache.org wrote:
[IO-324] Add Charset sister APIs to method that take a String charset name.
The new methods cause problems for people who pass in null for the
charset as they want the platform's system default. The compiler
doesn't know which of the writeStringToFile
On 2012-05-21, sebb wrote:
FIxed
Thanks!
When merging the changes to Ant I ran into conflicts and resolved one
hunk the wrong way around by accident (and didn't realize I was changing
more than the comments on the subsequent commit).
For some reason I also missed the Continuum build failure.
Hi all,
I'd like to release Compress 1.4.1.
Compress 1.4.1 RC1 is available for review here:
http://people.apache.org/~bodewig/cc/
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-111/org/apache/commons/commons-compress/1.4.1/
Details
On 2012-05-22, Stefan Bodewig wrote:
I'd like to release Compress 1.4.1.
Compress 1.4.1 RC1 is available for review here:
http://people.apache.org/~bodewig/cc/
The tag is here:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.4.1_RC1/
Votes, please
On 2012-05-22, Gary Gregory wrote:
[X] -0 OK, but really should fix...
- The logo is missing its TM per Apache branding requirements.
The commons compress logo in the upper right corner? It is the same
logo as the one that's currently online.
Anyway, we can fix the site independent of any
On 2012-05-22, Gary Gregory wrote:
I fixed the logo in SVN ;)
Great, thanks
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi all,
the vote has passed with +1s by Luc, Christian, Oliver and myself.
I'll now go ahead and publish the tarballs.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
On 2012-07-08, sebb wrote:
On 7 July 2012 20:34, bode...@apache.org wrote:
Modified:
commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/ArchiveStreamFactory.java
+private String entryEncoding = null;
The class is currently tagged as:
* @Immutable
This
Hi all,
COMPRESS-202 and COMPRESS-206 only talk about TAR but something similar
aplies at least to ZIP as well: once we detect that an archive doesn't
contain any more entries, we stop reading the input stream, even if it
contains more stuff that is part of the archive. This causes problems
for
Hi Julius,
can you please record the changes in src/chanhes/changes.xml as well -
and add yourself as developer to the POM if you feel like it?
Thanks
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
On 2013-01-08, Gump wrote:
at java.lang.Short.parseShort(Short.java:143)
at
org.powermock.modules.junit4.common.internal.impl.VersionCompatibility.getJUnitVersion(VersionCompatibility.java:40)
...
initializationError(org.apache.commons.mail.MultiPartEmailTest): Value out
of
On 2013-01-08, Thomas Neidhart wrote:
I would like to keep powermock, but we could disable the tests in question
until the version format changes?
We can split the commons-email build into two - one that builds and one
that runs the tests - and disable nagging for the test build until the
On 2013-01-09, Julius Davies wrote:
On Mon, Jan 7, 2013 at 9:16 PM, Stefan Bodewig bode...@apache.org wrote:
can you please record the changes in src/chanhes/changes.xml as well -
and add yourself as developer to the POM if you feel like it?
Thanks for the tip. Done!
Great, thanks
On 2013-01-10, Gary Gregory wrote:
The new HDFS provider only works on Linux and it works for me on Ubuntu
(via VirtualBox on Win7). How can Gump be fixed?
vmgump is Ubuntu 10.04 which may be too old, we also have FreeBSD and
MacOS nodes.
One option may be to Check for the proper environment
On 2013-01-10, Julius Davies wrote:
This is one my unit tests that I recently added that's failing.
They fail on my machine as well (GMT+1 right now) and create times one
hour different from vmgump which runs in GMT.
The times that are different from the expected times are the times taken
On 2013-01-11, Stefan Bodewig wrote:
On 2013-01-10, Julius Davies wrote:
This is one my unit tests that I recently added that's failing.
They fail on my machine as well (GMT+1 right now) and create times one
hour different from vmgump which runs in GMT.
The times that are different from
On 2013-01-11, Stefan Bodewig wrote:
In particular I didn't try a system where DST is active on new years
day - the test likely needs to take this into account as well.
I've modified the test further so I think it should now work for
regions with DST in January as well.
Stefan
On 2013-01-17, Torsten Curdt wrote:
If we see `getNextEntry` return null we should position the stream at
the end of the archive. I think that's your (1). Sounds simpler and
more straight forward from an API POV. IIUC that reading should only
be a few bytes. A second EOF marker for TAR for
On 2013-01-17, Bear Giles wrote:
I think a number of applications use a concatenation of a standard archive
format and custom data.
Absolutely, and I think we should support that use-case.
I'll try to free up some coding time this weekend.
Stefan
Hi all,
I've just published the compress site using mvn site-deploy.
The process failed to commit the modified site since it couldn't
authenticate itself. This is likely due to the fact that svn doesn't
store my password - is there any way to tell the
maven-scm-publish-plugin that it should
On 2013-03-03, Stefan Bodewig wrote:
I've then committed the changes manually (in fact, the process is still
going on) - is there anything the plugin would do after that or is the
process finished?
at least the site looks OK to me now.
Stefan
Hi all,
Compress has about 25 fixed JIRAs since the last release, most of which
are bug fixes - some of them pretty serious.
I'd like to cut a 1.5.0 release sometime this coming week.
Any objections, anything anybody is working on that I should wait for?
Cheers
Stefan
On 2013-03-03, sebb wrote:
On 3 March 2013 17:20, Stefan Bodewig bode...@apache.org wrote:
I'd like to cut a 1.5.0 release sometime this coming week.
OK by me, but note that the dist/ deployment process is currently
changing ...
Yes, thanks, I'll be looking out for it. The migration
Hi all,
[took me a few days longer since I wanted to incorporate fixes for the
two issues that popped up last week. So here we go.]
With 30 JIRA issues fixed it is about time to cut a new release of
Commons Compress.
Tarballs:
http://people.apache.org/~bodewig/cc-1.5/
Maven artifacts
http://svn.apache.org/viewvc/commons/proper/compress/tags/COMPRESS-1.5_RC1/
On 2013-03-11, Gary Gregory wrote:
The tag is wrong, it is:
http://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.5_RC1
Right. I copy-pasted the example vote mail from the compress site and
it also
On 2013-03-11, sebb wrote:
Minor nit: the addition of implements Serializable to ZipLong,
ZipShort and ZipEightBightInteger is not documented in the Javadoc.
Is there a formal way to document implements Foo since 1.5 other than
free form text in a class level comment? I'd like to add it in
On 2013-03-11, Gary Gregory wrote:
- Some (maybe not all) of the PMD/CPD issues seems easy to fix
At least the CPD one looks easier than it is - it uses a lot of
variables that are mutated and used outside of the block.
Many of the PMDs have reasons as well like overriding equals when not
On 2013-03-11, Benedikt Ritter wrote:
I've noticed, that the src archives differ from the RC tag. The following
files are missing:
.gitattributes
.gitignore
doap_compress.rdf
PROPOSAL.txt
Is this intended?
In a way, yes. They are not listed inside the assembly descriptor. The
.git
On 2013-03-11, sebb wrote:
On 11 March 2013 06:10, bode...@apache.org wrote:
Author: bodewig
Date: Mon Mar 11 06:10:51 2013
New Revision: 1455005
URL: http://svn.apache.org/r1455005
Log:
Tagging first RC for Compress 1.5
Please don't recreate a tag with the same name.
If you need
On 2013-03-12, sebb wrote:
The DOAP files are currently held under
/commons/proper/component/trunk/doap_component.rdf
This is sort of convenient for editting, but means the doap file gets
included in tags and branches and may get included in source.
If included in source, the release date
The vote has passed with +1s by Gary, Sebb, Benedict, Jörg and myself
(which I didn't cast expplicitly, sorry) - four of which are binding.
I'll promote the staging and copy over the tarballs now. I'll update
the site and send out the announcement later today once the mirrors have
picked up the
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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlFCA
On 2013-03-14, Gary Gregory wrote:
In the past, I've have felt (disgusted is too strong a word) discouraged
from releasing often by the our release process, and it's a 'process' all
right. First, I had started to follow:
https://commons.apache.org/releases/index.html
but finding it
Hi all,
I've started to update the releasing page in the staging area - not
much, yet, will take time - and stumbld over the commons.rc.version
property.
I've set it by adhering to our guidelines but never asked myself why I
was doing so. Now that I try to update the docs I'm trying to
On 2013-03-17, sebb wrote:
a name=Manual Methodh4Manual Method/h4/a
Surely names are normally lower-case only and no spaces?
I think spaces make the links look odd (and awkward to type).
Uses the same syntax as the mvn site plugin created for subsection now
(with s/h3/h4/), i.e.
On 2013-03-18, William Speirs wrote:
On Sun, Mar 17, 2013 at 5:34 PM, sebb seb...@gmail.com wrote:
Maven artifacts are here:
http://people.apache.org/~wspeirs/commons-dbutils-2.0-RC1/maven
Maven artifacts must be uploaded to Nexus.
How do I do this? I was following the directions here:
On 2013-03-21, Gary Gregory wrote:
Some links are broken like:
https://commons.apache.org/proper/releases/index.html
Does anyone else see this?
Where is this page linked from? Releases from the main nav points to
https://commons.apache.org/downloads/index.html
Stefan
On 2013-03-22, sebb wrote:
On 19 March 2013 17:05, sebb seb...@gmail.com wrote:
Commons is currently still publishing mon-Maven releases from
people.a.o dist/commons.
There is an outstanding JIRA issue for this to be changed to svnpubsub:
https://issues.apache.org/jira/browse/INFRA-5929
On 2013-03-22, sebb wrote:
I don't know whether you want to mention the dist/dev tree - that can
be used for staging releases instead of a user's home directory.
Yes, that's what we do in Ant and I wanted to mirror that experience.
I'm not sure where I'd recommend to put the staging website,
Hi,
I've just updated the releasing guide up to the point in time where the
release vote happens. It covers publishing via Nexus and svnpubsub for
releases. This has not been published, yet:
http://commons.staging.apache.org/releases/prepare.html
Feedback and corrections more than welcome.
On 2013-03-23, Phil Steitz wrote:
I have one question: I have not cut a release in a while and was
always able before to avoid Nexus and the maven release plugin. I
understand now there is no way around using these. First, that is
correct, right?
There is no way around Nexus. I haven't
On 2013-03-23, Stefan Bodewig wrote:
I'll start working on the follow-up document soonish.
Now also done: http://commons.staging.apache.org/releases/release.html
Please review it and correct my mistakes before the site gets published.
Stefan
On 2013-03-28, Emmanuel Bourg wrote:
Hi,
I just noticed that for the recent releases the source and binary
packages have been published in the Maven repository. I saw that with
fileupload 1.3 and daemon = 1.0.11.
Is this a standard practice?
I would hope it is not. When I released
On 2013-04-04, Mladen Turk wrote:
So it seems the gpg-sign plugin in #28 uses gpg differently. And it
seems running gpg-agent is needed and sloves the issue. Just in case
someone else bumps into that.
Could you add this piece of knowledge to
On 2013-04-23, sebb wrote:
As to the (non-Maven) tarballs: another approach would be to create them in
Nexus as per usual, but move them (copy/delete) to the svnpubsub staging
area [1] before the vote starts.
It would make the reviewers job slighly harder - one extra URL to download
and
1 - 100 of 1221 matches
Mail list logo
