Re: [compress] [Poll Non Result] Dealing with uncaught RuntimeExceptions

> >> That certainly doesn't prevent anybody else from trying to find a > >> compromise :-) > > > It feels like Optionals could be a compromise. > > I must admit I've lost track of the later discussion threads. If you > mean that we'd return Optional<> results, this would become an entirely >

Re: [compress] [Poll Non Result] Dealing with uncaught RuntimeExceptions

> That certainly doesn't prevent anybody else from trying to find a > compromise :-) > It feels like Optionals could be a compromise.

Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions

> > So IllegalArgumentException is not from the early Java days? > > It is, so what? > It's the exception I use 99% of the time (to signal failed precondition)? > It's a runtime exception. > When I quote standard exceptions you said: "if you quote design decisions that date back from the early

Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions

> I'm not sure what you refer to exactly, The various links from https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html or even https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html > but I noted already that not all > references are equal, especially if you

Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions

> > "If there is runtime exception there is a bug in the code" > > I don't think that's correct because IllegalArgumentException is a > RuntimeException. I have a hard time following that causality. The way I've seen this exception used mainly is in case of program errors, not in case of input

Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions

> > It is not the job of commons-compress to stop you from using a > corrupt archive. If you choose to do so, then ... > I don't think that's what it is. That would be more like getting an exception and continuing walking through the archive. If there is a parse exception there is a bug in the

Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions

> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a > subclass) and throw the IOException > +0 > (2) catch only a subset of all RuntimeExceptions, wrap them in an > IOException (possibly a subclass) and throw the IOException - allow > the remaining

Re: [compress] Dealing with uncaught RuntimeExceptions (again)

> Recovery may not be possible for a single archive, but the caller may > want to process multiple archives. > (Or potentially try again, if the error was caused by a transient error > [1]) > > So ideally Compress will return a CE for parsing errors, and that CE > should give some context to the

Re: [compress] Dealing with uncaught RuntimeExceptions (again)

> > > Based on that premise we could also just forget about checked exceptions > > altogether. > > As Gary said (as Joshua Bloch said, as many people said), checked > exceptions are for recoverable errors. > Maybe it boils down to the definition of "recoverable". > Parsing an archive I

Re: [compress] Dealing with uncaught RuntimeExceptions (again)

> Can you expand on that - I don't understand the horror or the futility. > > The futility is because it is wrong for the caller to expect that no > runtime exception can be thrown. > Based on that premise we could also just forget about checked exceptions altogether. I think the distinction is

Re: [compress] Dealing with uncaught RuntimeExceptions (again)

> feels like both a horror show and an exercise in futility Can you expand on that - I don't understand the horror or the futility. It certainly is a bit of code smell - but only because there is no quick way to harden the implementations. But I rather have a clear and stable API and fix the

Re: [compress] Dealing with uncaught RuntimeExceptions (again)

I personally think that we should look at it from the point of view of the API consumer. What would they want to happen in case of an error reading an archive? IMO an IOException. How we get to that exception on the implementation side is another matter. If we could check all conditions and

Re: [COMPRESS] OSS-Fuzz integration

> At least for Compress I see value in Fuzz testing. > Any other opniions? > I totally see the value and it should go to a private list.

Re: [all] When to update dependencies?

> > They’re not the same class and that’s the problem. It’s similar to loading > two versions of the same library in OSGi Let's say you are dealing with org.vafer.Foo the library relocates this as org.apache.commons.compress.internal.org.vafer.Foo The library only deals with

Re: [all] When to update dependencies?

> > > - library L1 shades library ShadedA-1.0 and ShadedB-1.1. > >> - library L2 shades library ShadedA-1.1 and ShadedB-1.0. > >> - An app wants to use L1, L2, ShadedA-1.1, and ShadedB-1.1 but it can't > no > >> matter what classpath ordering it uses. > >> - An app wants to use L1, L2,

Re: [all] When to update dependencies?

> > The key phrase is "which would be stupid" which you as a consumer have zero > control over. People do stupid things all the time. > If people use a package that is called "internal" or something - there is nothing anyone can do. And really beyond the point. > > To be more explicit. I am

Re: [all] When to update dependencies?

> > Unless I'm mistaken, there is one drawback to shading: Since > it creates new classes, there will be less shared code, hence > one could imagine a potential hit on performance (?). > Of course it means some code duplication in the final artifact. This means slightly bigger artifacts - but

Re: [all] When to update dependencies?

> > You can imagine all manner of jar-hell created by shading. For instance: > - library L1 shades library ShadedA-1.0 and ShadedB-1.1. > - library L2 shades library ShadedA-1.1 and ShadedB-1.0. > - An app wants to use L1, L2, ShadedA-1.1, and ShadedB-1.1 but it can't no > matter what classpath

Re: [all] When to update dependencies?

It still needs a person to decide to merge a PR for a new version. So this indeed is just about the dependency upgrade policies. But isn't that what the version definition is for? I'd argue that 1.12.4 <-> 1.12.6 should be a compatible upgrade AND downgrade, 1.12.4 -> 1.20.0 not so much. But to

Re: [all] Dependabot PRs

On Thu, Jul 23, 2020 at 4:40 AM Rob Tompkins wrote: > Guys...let’s not argue like this. It gets us nowhere. > You are right. I can see that it is indeed pointless and will not waste more time on it. Sorry, about adding to the noise.

Re: [ALL] CI builds

> > > I realize that a local build seems to be your gold standard. > > Not mine. "Commons". > You are arguing for it. I would just call it a current policy or practice. > > That's a very debatable point of view. > > There was no debate. Yet it is a debatable point of view :) > I don't see

Re: [all] Dependabot PRs

> > > > TBH not in terms of your "you act, and I must react" argument. > > It was not an argument, but a statement of fact. > Well, it "must react" feels a bit loaded. And I see two possible actions here: 1. A person of another project doing a release, triggering a bot to notify us and even

Re: [VOTE] Create additional mailing lists for automated posts

also a -0 from me ...and a +1 to all what Gary said

Re: [all] Dependabot PRs

On Thu, Jul 23, 2020 at 12:51 AM Gilles Sadowski wrote: > 2020-07-23 0:14 UTC+02:00, Torsten Curdt : > >> > >> You act, and I must react? > >> Do I really have to spell it in even more words than > >> above? > >> > > > > You just s

Re: [ALL] CI builds

> > > It does not mean that a source distribution goes away. > > Nor did I mean that it would. > I commented on the remark that one's own computer > supposedly did not matter. > Ah, then it was only the "(that one does not really count.)" that didn't sit well with you. Misunderstood. > > We

Re: [all] Dependabot PRs

> > You act, and I must react? > Do I really have to spell it in even more words than > above? > You just sent me a message I didn't want - and I need to delete it now ;) But tongue in cheek aside. We are on a dev list. Commits, issues all generate traffic that are caused by other people. If you

Re: [ALL] CI builds

> > I don't agree: a source distribution assumes that one's own > computing resources is essential. > This project never discussed departing from the assumption > that a contributor should be able to build locally and primarily > check that the reports generated comply with the level of > quality

Re: [all] Dependabot PRs

> > > > >> You can ignore those > > > > > > How can I ignore stuff that gets pushed into my mailbox? > > > Spammers could argue in the same way. > > > I've had to click on each of these automated messages to > > > delete them. IMHO, the consequences of new settings > > > should be tested on a

Re: [Compress]New PRs on github need reviews

I've added some comments/questions to the PR for Tar. cheers, Torsten On Tue, Nov 26, 2019 at 4:46 AM Peter Lee wrote: > Hi all, > > I'm Lee and I'm new to commons-compress. I'm a amateur in compression > algorithms. I like commons-compress cause it supports so many > specifications. I'd like

Re: [compress][POLL] High Level API

> > > Given that you are currently the main person working on Compress I'd say > - > > whatever you are OK with. > > But you don't really sound super confident/happy about the API - > > otherwise you might not have written this email :) > > TBH I've written this email because my compass for which

Re: [compress] High Level API for Archives

> > > That said - optional dependencies are also not really my favorite thing. > > I am myself a big fan of shading dependencies in libraries (if the > license > > allows), > > which also forces one to re-evaluate the modularity vs inclusiveness of > > (even transitive) dependencies. > > > > I'm

Re: [compress] High Level API for Archives

> > > Just one question: Why? > > > > The implementation jars for compress would be tiny and would have close > to > > none dependencies. > > > > As an end user, I'd prefer to only have to manage a single maven coordinate > (e.g., commons-vfs-ssh) instead of multiple ones depending on my use case

Re: [compress][io] Avoid InputStream#skip?

+1 On Tue, May 1, 2018 at 12:59 PM, sebb wrote: > On 1 May 2018 at 11:24, Stefan Bodewig wrote: > > Hi all > > > > as skip throwing exception is uncommon enough that it hasn't been > > reported before in Compress and only seems to happen if you use streams

Re: [compress][POLL] High Level API

https://github.com/apache/commons-compress/blob/master/ src/main/java/org/apache/commons/compress/archivers/Archiver.java Is tiny compared the whole lots of https://github.com/apache/commons-compress/tree/master/ src/main/java/org/apache/commons/compress/archivers/examples and while the later

Re: [compress] High Level API for Archives

> > > As in one module/jar per implementation. One module for a zipfs, one for > an > > sshfs, etc., instead of just "commons-vfs" as a monolith with optional > > dependencies. > Just one question: Why? The implementation jars for compress would be tiny and would have close to none dependencies.

Re: [compress] High Level API for Archives

TBH I am not such super big fan of adding and maintaining a high level API at this stage. You will never find the right abstraction that everyone is happy with. If you would - well, then that should be the real API afterall. Honestly - I would just add example code for now. Maybe that can turn

Re: [compress] TarArchiveEntry and Windows drive letter

> > This is what I suggested. Change the meaning of "preserveLeadingSlashes" > > to "preserveAbsolutePath" and use it to keep the drive letter on > > Windows. > > > > The current code will always strip the drive letter spec. > > In that case, I agree with you. > > Also as a name,

Re: [compress] TarArchiveEntry and Windows drive letter

> >TarArchiveEntry("C:\foo\bar") -> "/foo/bar" > >TarArchiveEntry("D:\foo\bar") -> "/foo/bar" > > "strip the drive letter" predates preserveLeadingSlashes > Might be but I guess the only question is how to fix it without breaking too many things. I am not such a big fan of

Re: [compress] AR docs confusion

Thanks - that was quick :) On Wed, Jan 3, 2018 at 5:20 PM, Stefan Bodewig <bode...@apache.org> wrote: > On 2018-01-03, Torsten Curdt wrote: > > > I think I'd just add a little table. OK? > > I've gone ahead and added a table, just not regenera

[compress] TarArchiveEntry and Windows drive letter

I just found a new issue with compress. It's the "normalizeFileName" in TarArchiveEntry again. On Windows it just strips the drive letter https://github.com/apache/commons-compress/blob/master/src/ main/java/org/apache/commons/compress/archivers/tar/ TarArchiveEntry.java#L1337 which I think is

Re: [compress] AR docs confusion

> > https://github.com/tcurdt/jdeb/issues/241 > > [WRT to that issue, LONGFILE_POSIX should be the preferred option if it > works in debs. LONGFILE_GNU is considered deprecated even by GNU tar.] > Thanks! I will give that a try. > and I have to say I was a little confused about the docs on

[compress] AR docs confusion

Someone raised an issue over at jdeb https://github.com/tcurdt/jdeb/issues/241 and I have to say I was a little confused about the docs on the AR support in compress https://commons.apache.org/proper/commons-compress/examples.html Commons Compress 1.0 to 1.2 can only read archives using

Re: [BCEL] thread safety

It's been a looong time since I worked on BCEL and my memories might serve me wrong but I think thread safety is something that should not necessarily happen on the BCEL level. BCEL holds a lot of state. Making all that threadsafe - I'd like to see the use cases first as it might come at a cost.

Re: Best Home for Checksum Implementations?

> > > Maybe create a "checksum" package in codec? > > Alternatively, we could start a new component called Commons Checksum… > Depends on how many implementations we can gather I guess.

Re: Best Home for Checksum Implementations?

On Tue, Jan 24, 2017 at 10:08 AM, Stefan Bodewig wrote: > Hi > > inside of [compress] we've already got an implementation of CRC32C (used > by Snappy, "borrowed" from Hadoop) and will soonish have xxhash32 (used > by LZ4). > > I was wondering whether these implementations

Re: [compress] change behavior of bzip-output finalize?

> > AIUI finalize() is not guaranteed to be called, so any code that > relies on it is liable to be disappointed from time to time. > > IMO at best one can use finalize() - *if* indeed it gets called - to > warn users that they have not closed a resource. > +1

Re: [crypto] Logging dependency

On Sat, Jun 11, 2016 at 7:34 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > On Jun 10, 2016, at 2:56 PM, Torsten Curdt <tcu...@vafer.org> wrote: > > > >> Matt, there is a big difference between printing the stack trace and > >> walking it

Re: [crypto] Logging dependency

> > > As a side note: I personally think libraries should return errors - not > log > > them. The error logging should happen in the app - not the library. If > you > > have to log errors in the framework there is a good chance your API is > not > > how it should be. > > > > That's not a good

Re: [crypto] Logging dependency

> Now we are getting way off topic, but I would argue that a message that > contains no specific context information would still be a good message. > There is nothing wrong with a debug message of logger.debug(“User: {}, > userId); as this contains all the context information you need to determine

Re: [crypto] Logging dependency

> Matt, there is a big difference between printing the stack trace and > walking it to find the info. printing it on every debug call would be > insane. > Why would anyone want to do that? https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html And how do you think the

Re: [crypto] Logging dependency

> > > Exactly. It's so simple and it doesn't introduce any deps. > > Whether that's goal one can align with is another matter. > > But it means no logging framework discussions anymore ;) > > The disadvantage of this approach is that you loose the location > information - every log event will come

Re: [crypto] Logging dependency

> > But I guarantee that there will be other discussions: > Wouldn't you add an "error" method to "Console"? > And there we go again... Not quite the same discussions though. And I was just saying: it works for me. As a side note: I personally think libraries should return errors - not log

Re: [crypto] Logging dependency

On Fri, Jun 10, 2016 at 12:14 PM, sebb <seb...@gmail.com> wrote: > On 10 June 2016 at 10:46, Gilles <gil...@harfang.homelinux.org> wrote: > > Hi. > > > > On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote: > >> > >> FWIW > >> >

Re: [crypto] Logging dependency

FWIW I am not a fan of libraries and frameworks just logging away anyway. What I usually do this days: Have an interface in the library itself. Along the lines of public interface Console { void debug( String message ); } and then have the user of the library pass in an

Re: [compress] Preparing for 1.12

> > > You'll see that findbugs is unhappy about inconsistent synchronization > introduced when I made the finish method of BZip2CompressorOutputStream > synchronized due to COMPRESS-357 > > Yes, blockSorter is accessed unsynchronized in different places, but we > don't need to care as the class

Re: [BCEL] 5.3 is going to be messy

> > > So? What's your point there? > > Commons libraries are generally very low level, and are often embedded > deep within software stacks. > > So changes which require downstream changes are expensive when > considered as a whole. > > This is very different from many other ASF projects which can

Re: BCEL 6 API breakage

While I am a big fan of ASM it feels a bit strange to put it forth as a great example in this regard. Indeed some ASM API changes were simple - some weren't so much. And many required source level changes. Some changes are often just a quick refactor away. If we'd allow just that we'd be a good

Re: [BCEL] 5.3 is going to be messy

> > >> 1) I don't believe we should force users to migrate their code in > >> order to support java 7/8. > >> > > > > ...and that line of thinking is why it feels like commons projects are > > effectively stuck in the past. > > And maybe the ease of upgrade is why they are popular with users. >

Re: [BCEL] 5.3 is going to be messy

> > 1) I don't believe we should force users to migrate their code in > order to support java 7/8. > ...and that line of thinking is why it feels like commons projects are effectively stuck in the past. No one needs to upgrade. If your projects live in the past - there are bug fix releases. But

Re: Git not suitable for dist repo (was: Whatever happened to commons-io 2.5?)

Not completely true http://stackoverflow.com/questions/600079/is-there-any-way-to-clone-a-git-repositorys-sub-directory-only

Re: [VOTE] Release Compress 1.11 Based on RC2

+1 from me On Mon, Apr 4, 2016 at 6:00 AM, Stefan Bodewig wrote: > On 2016-04-03, Matt Sicker wrote: > > > I thought Infra disabled the ability to delete tags in git anyways unless > > they reverted that recently. > > Only tags under rel/ cannot get deleted, all others

Re: [VOTE] Release Compress 1.11 Based on RC1

+1 from me On Wed, Mar 30, 2016 at 3:56 PM, Stefan Bodewig wrote: > Hi all > > Foo 1.2 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/compress/ > (svn revision 12931) > > Maven artifacts are here: > >

Re: commons-compress git commit: Changes to allow byte-for-byte replication of Zip entries

Darn. OK. Will fix. Thanks! On Thu, Jan 28, 2016 at 4:10 PM, Stefan Bodewig wrote: > On 2016-01-27, wrote: > > > > http://git-wip-us.apache.org/repos/asf/commons-compress/blob/61db5ea7/RELEASE-NOTES.txt > > Changes to the RELEASE-NOTES will get lost as

Re: Eirik Bjørsnøs' notsoserial deserialization protection agent, for Commons?

> > 1) Is notsoserial a "great solution" or a "useful solution" in mitigating > the problem of promiscuous deserialization? > Useful? Certainly 2) Is it a "better" solution than IO-487? > Not sure - but does that really matter? It has a broader scope. 3) Is it in the interest of Commons and

Re: Eirik Bjørsnøs' notsoserial deserialization protection agent, for Commons?

> > > ...it feels a bit like putting a thumb into a hole to stop the water. > > People need to re-think their use of reflection and serialization - not > > cover up bad engineering practices... > > Absolutely - but depending on people's use of serialization it will > take a while until all holes

Re: Eirik Bjørsnøs' notsoserial deserialization protection agent, for Commons?

Using the agent in (and only in) whitelist mode is a pretty strong and quick security measure. Calling this a "great solution" still goes against my inner developer soul though. It's pragmatic and a good tool - that I am on board with. (Cool stuff, Eirik) Yet it feels a bit like putting a thumb

keep going

I am thrilled to see all that BCEL activity lately, folks. Would love to see the release being pulled across the finish line. Thanks to everyone involved. Sorry I don't have the time to contribute. Just wanted to give credit where credit is due. Thanks! Torsten

Re: [VOTE] Move COMPRESS to git

+1 from me On Sat, Aug 22, 2015 at 9:29 PM, Stefan Bodewig bode...@apache.org wrote: Hi all more thann half a year ago I promised to call for a vote for migrating to git as soon as 1.10 has been released. Well that took longer than expected :-) Anyway, here is the vote: +1 Move to git

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

But there will me much more in terms of discussion. That's why a TLP does make any sense for me. TLP just because of a noisy API discussion - that's just not how it works. I don't mind reading that discussion, or just deleting it, or creating a filter. I've subscribed to dev@commons.a.o

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

Members of the Commons community are expected to be subscribed to the dev mailing list. The impression I get from reading these messages is that the RDF community has little to no interest in interacting with the Commons community. At this point it looks to me like the incubator would be a

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

There are several ASF projects in the RDF space. They have been through the incubator. Please do talk to those projects if you have concerns. I am sorry - but how are those projects relevant in this case? And what's so bad about the incubator? You could (maybe) later on come to Commons.

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

As I see it, the Apache Commons has one partcular way of working. Every Apache project has its own unique ways of working within the Apache way. From my ASF experience (and that's shockingly 12+ years now) the implementation of Apache way is not that very different across projects. It varies -

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

On Tue, Jan 20, 2015 at 3:08 PM, Mark Thomas ma...@apache.org wrote: On 20/01/2015 13:07, Andy Seaborne wrote: On 20/01/15 08:49, Mark Thomas wrote: At this point it looks to me like the incubator would be a much better destination, particularly given the general impression I get of the RDF

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

know that for many email list == community == Apache project. But Apache Commons is special. As pointed out - not everyone here will be involved with all Commons components. Yet we consider this as one community that has cross pollination and shared responsibilities. As Peter points out,

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

Agree that maybe the the Incubator with a projected path to the Commons could be a workable middle ground while Commons-RDF is still incubating code-wise (but not community or Apache Way-wise). To me it comes across as if community/ASF wise is the more important part. This is really not meant

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

There is the build system for some, for some it's the people - be it just for oversight. And then there is the PMC and the board reports. Of course, there are some _administrative_ connections; it's very helpful to have a home for projects that by themselves wouldn't have the resources to

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

...and it's still the term we are using: http://commons.apache.org/components.html You miss my point(s): It's totally clear what a component is, as defined by Commons. The issue is how it relates to the Commons project management. That does not sound like totally clear to me. That sounds

Re: [DISCUSS][RDF] Separate mailing list for Commons RDF

Words without semantics... ...and it's still the term we are using: http://commons.apache.org/components.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail:

Re: [ALL] Too much traffic on the dev ML

Concerning [Math], when the possibility was raised, the majority thought that development within Commons had practical advantages (through shared burden of the development environment). I'm stating again the fact that nobody is involved in a Commons project programming-wise; hence it does

Re: [ALL] Too much traffic on the dev ML

Was it mentioned that anybody would be forbidden to subscribe to any ML they see fit? You missed my point - but never mind. That comparison is pretty flawed as those projects are not tiny components. I'm not talking about the size of components, but the size of the ML traffic. So just

Re: [ALL] Too much traffic on the dev ML

I would be in favour of total segregation, even including issues and commits, but I appreciate the latter two might be challenging to implement. Then let's ask the next question: Why be a Commons project? - To unsubscribe,

Re: [ALL] Too much traffic on the dev ML

Then let's ask the next question: Why be a Commons project? I gave one answer a few posts ago (several times). Guess I missed that in all that traffic :-p Sorry - I am done with this thread. - To unsubscribe, e-mail:

Re: Release Plugin (was Re: [All] Moving to git)

On Wed, Dec 31, 2014 at 11:34 AM, Stefan Bodewig bode...@apache.org wrote: On 2014-12-31, Jochen Wiedmann wrote: On Mon, Dec 29, 2014 at 3:16 PM, Stefan Bodewig bode...@apache.org wrote: Just as a letter of intent - I'd prefer to cut Compress 1.10 while we're still in svn (as I know how

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/j

You know that Java has no out variables (as it is call by value) and the final identifier does not make an object read only. So in fact having final modifiers would misslead you even more. The last sentence is a bit of theory. I don't see that to be true for me at least. Following some of

Re: [compress][imaging] generalise/publicise commons-compress LZW implementation?

I think it is a good idea make [imaging] depend on [compress]. Do you mean depend in general, or as opposed to the current use of the maven-shade-plugin to half-depend on it? I mean plain and simple depend. Using the maven-shade-plugin would be the better choice IMO. cheers,

Re: [VOTE] Release BCEL 6.0 based on RC1

Please review the release candidate and vote. This vote will close no sooner that 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [X] -1 I oppose this release because... What is referenced in the pom should also be

Re: [bcel] Next release

Go go go! Thanks for looking into this :) IIRC there is so much stuff fixed and changed from 5.2 - I think calling it 6.0 expresses this better than 5.3. Especially with the changes to the visitor interface. cheers, Torsten On Fri, Apr 25, 2014 at 12:30 PM, Emmanuel Bourg ebo...@apache.org

Re: [io][compress] Interest in Some Channel Classes?

The current [compress] codebase has already copied bigger chunks of IOUtils and some stream classes from [io]. Whether we intend to keep copying stuff around for [compress2] or simply make [io] a dependency is something I see as a separate issue. One that wants to get addressed, though. I

Re: [compress] 2.0: require Java7?

And the old 1.x releases are not going magically away with a 2.x release ;) +1 for not having Android influence the decision On Sat, Jan 25, 2014 at 9:58 AM, Benedikt Ritter brit...@apache.org wrote: 2014/1/25 Damjan Jovanovic dam...@apache.org On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig

Re: Expecting BCEL6.0 release for 3 months.

If there are people happy with the snapshot - maybe we should do the release. The release was but on hold ages ago because there was no testing feedback. Not sure what the state is terms of open tickets. cheers, Torsten On Wed, Dec 25, 2013 at 7:33 PM, Gary Gregory garydgreg...@gmail.comwrote:

Re: [compress] cutting 1.7?

Keep the release train moving... :) +1 Amen to that :)

Re: [cli] Moving to Git?

This in fact means: create a master branch which is stable. create a develop branch which is not so stable. create feature branches from develop where you work out your changes. We are just swapping the branch names here, in the end your model isn't very different from mine. Let's say

Re: [cli] Moving to Git?

Trying hard not to get sucked into the git debate again but I am almost offended to be offered this ridiculously simplified argument: For reminder, the argument was that it is quite easy to provide a contribution with Subversion: $ svn co URL $ cd trunk $ mvn test $ svn diff

Re: [VOTE] Release Compress 1.6 based on RC3

+1 let's release it! On Wed, Oct 23, 2013 at 6:56 AM, Stefan Bodewig bode...@apache.org wrote: Compress 1.6 RC3 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 3327) Maven artifacts are here:

Re: [VOTE] Move Apache Commons to Git for SCM...

Those who wanted to move to Git have given up several days ago, leaving this thread to be 'argued' by those who successfully squashed the action. James has already canceled the test project request in INFRA, and so it seems pointless for this thread to continue. You won, go off and have a

Re: [VOTE] Release Compress 1.6 based on RC2

+1 for the release from me

Re: [CHALLENGE] Move All of Commons to the Dormant

I monitor commits, rarely check JIRA, follow and sometimes answer mails and close to never develop code for that component anymore - maybe once or twice a year when I go through JIRAs. Now what? I appreciate the initiative but don't see this working too well for me. If this was all just one

Re: [DISCUSS] Moving to Git...

big +1 for the the move from me (I guess that does not come as a surprise) SCM isn't the biggest problem is certainly true but given my experience I am inclined to say it will help. But with so many hesitant people I think we need a good plan on how it will look like. We especially need to check

Re: [DISCUSS] Moving to Git...

Maybe for tiny fixes it's that easy - for longer contribution where you follow development it's not. How often does that happen (within Commons)? Not often enough because then we would have more people working on commons ;) How often will a new contributor embark in a long rewrite? [And

Re: [DISCUSS] Putting several unmaintained components to dormant

Every now and then I keep getting requests via private mail asking to release javaflow as it seems to be working for people. Yet I know there is still so much essential stuff to fix for a 1.0 release. Crossing over to the other thread: I know on github I would made a 0.x release already ages ago

  1   2   3   4   >