[
https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Pugh updated SANDBOX-183:
--
I fixed the style concerns, but did not fix the allocation size issue yet.
Should not be hard to do
[
https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Pugh updated SANDBOX-183:
--
Attachment: myzip2.zip
Fixed most of Mario's style concerns.
Did not address the memory issu
[
https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Pugh updated SANDBOX-183:
--
Attachment: myzip.zip
> Compress should allow for writing to Zip Fi
: Compress
Affects Versions: Nightly Builds
Reporter: Will Pugh
Fix For: Nightly Builds
Attachments: myzip.zip
Compress should be able to modify existing ZipFiles.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact
Since, MethodUtils is not going to be in the same package as whatever
class you are calling a method on, I don't think you going to be allowed
to call a package, protected or private methods in that class?
--Will
Henri Yandell wrote:
JIRA reports are good - we've a big backlog in BeanUtils
Torsten Curdt wrote:
On 10/25/06, James Carman <[EMAIL PROTECTED]> wrote:
For someone who uses Commons Collections a lot in their applications,
this
is going to be quite a pain if I want to upgrade. Yes, I realize that
there's such a thing as find and replace, but the fact that I have to do
th
Stephen Colebourne wrote:
The problem is erasure. The JDK wipes all knowledge of the type that you
connect to the collection. Thus
List list = new ArrayList();
if (list instanceof List) {
}
fails to compile as the String type is erased.
In order to preserve backwards compatability, Sun had to
I'm not sure we're optimizing for the right thing by changing the
package names and creating parralel forks for Generic Collections.
Generics have done a pretty good job of dealing with backwards
compatibility. It feels like we will make the upgrade path for the vast
majority of people more d
We could also mash together collections and generics to get
"commons-collagen"
I'm sure there are some great puns we could pull out of that. . .
--Will
Mario Ivankovits wrote:
Hi!
collections5 ? (don't like collgenerics)
I think we should try not to put the technology into the na
[ http://issues.apache.org/jira/browse/LANG-268?page=all ]
Will Pugh updated LANG-268:
---
Attachment: addRangeToJoin.patch
A patch with the new methods as well as new unit tests
> StringUtils.join should allow you to pass a range for it (so it only join
Lang
Type: Improvement
Reporter: Will Pugh
Attachments: addRangeToJoin.patch
Currently join, takes an array of objects, adn joins them using a character or
string as a separator.
The problem is that there are many instances where I have an array, but I only
want to join part of it
Factories, e.g.
ArchiverFactory.ZIP
--Will
Sandy McArthur wrote:
On 5/12/06, will pugh <[EMAIL PROTECTED]> wrote:
Hmm.
Factories have always seemed most useful to me when they are
encapsulating the creation of some configurable resource. In practice,
it seems like "configurable&q
Hmm.
Factories have always seemed most useful to me when they are
encapsulating the creation of some configurable resource. In practice,
it seems like "configurable" most often means pulling a string from some
attribute or properties file, and using that to choose implementation.
If the typ
he purpose of the ArchiverType? I'm assuming this is meant
to help people build their own factories? but the common case for
creating an Archiver is still to create using 'new'. Is this right?
--Will
Sandy McArthur wrote:
On 5/1/06, will pugh <[EMAIL PROTECTED]> wrote
ea is
that this helps folks build factories, but that it is perfectly
acceptable and encouraged to create any of the archivers via 'new'. Is
that correct?
Thanks,
--Will
Sandy McArthur wrote:
On 5/1/06, will pugh <[EMAIL PROTECTED]> wrote:
Sandy McArthur wrote
Sandy McArthur wrote:
On 4/30/06, will pugh <[EMAIL PROTECTED]> wrote:
1) You often change method names based on the parameter types, e.g.
Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
setUnpackDestinationFile, etc. It seems more conventional and less
chaotic t
design and parameter conventions from
some of the commons-io methods I use alot.
--Will
will pugh wrote:
Overall, I like the interfaces, but I've got a few issues:
0) Update is mentioned in the Javadoc at the beginning of Archiver,
but is not implemented.
1) You often change met
Overall, I like the interfaces, but I've got a few issues:
0) Update is mentioned in the Javadoc at the beginning of Archiver, but
is not implemented.
1) You often change method names based on the parameter types, e.g.
Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
set
Yeah. Probably should have documented a little more to start off with.
I sent it off early because I wanted to see if folks were interested in
the functionality first. I wrote up a bunch of JavaDoc for some of the
bigger classes. It's not perfect, but hopefully it will make it much
easier t
Cool.
I'd love to see your code, although I don't think we should merge until
we get the code contributed. It looks like contributing code gets a bit
harder when there are more than one person involved in writing it.
--Will
C. Grobmeier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: S
I think the appropriate processes for getting contributed code are the
ones outlined:
http://incubator.apache.org/ip-clearance/index.html
Using some of the forms linked to from:
http://www.apache.org/licenses/#grants
This process is predicated on there being a community for the code to go
Hi All,
I am interested in contributing code to commons. I wrote a
ModifiableZip class, that basically implements all the methods on
ZipFile, but provides new methods for adding, removing and modifying
entries in an existing zip file.
The basics work, but it is still a bit rough around the ed
22 matches
Mail list logo
