Henri Yandell wrote:
On 7/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:
Assemblies work except you only get a default manifest - not sure
where I got the attachment idea from, can't find any reference to that
- so I think we should keep it simple and stick to option #1
That has my +1
Henri Yandell wrote:
One area for discussion is the split between the optional Collections
component and the 'Core' beanutils. Do we maintain that, or should we
just fold the code back together?
1.7.0 shipped three versions:
commons-beanutils-1.7.0.jar
commons-beanutils-core-1.7.0.jar
[
https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512402
]
Stephen Colebourne commented on COLLECTIONS-259:
My preference would be to see the Predicate
[
https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511686
]
Stephen Colebourne commented on COLLECTIONS-259:
An interesting idea, however I sense
Jochen Wiedmann wrote:
when applying the fixes for IO-99 to commons-fileupload, I was
originally under the impression, that this would be easily possible
without any or at least with fully upward compliant API changes.
Until I detected that for reasons, which absolutely escape me, someone
made
[
https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509269
]
Stephen Colebourne commented on BEANUTILS-285:
--
Although I haven't followed the detail of this case
[
https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509270
]
Stephen Colebourne commented on LANG-326:
-
Personally, I would go with 2.4.
StringUtils: startsWith
[
https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509193
]
Stephen Colebourne commented on LANG-326:
-
I'm happy for these ignoreCase methods to be added. For collators
sebb wrote:
Licence and notice files
are present in all files (twice in sources.jar, but better twice than
none).
Not something I'm worried about. Nice to fix if there is another RC.
The RELEASE-NOTES.txt say:
- The FileCleaner is deprecated.
Unfortunate, but not something I'm too worried
I also would strongly prefer to use this opportunity to create a commits list
and an issues list.
Commons is big enough to need it, and it would increase the signal to noise on
the main list, especially when searching.
Stephen
- Original Message
From: Martin van den Bemt [EMAIL
Niall Pemberton wrote:
[ ] +1, don't let Rahul get away - lets try to get him to join the new PMC
[ ] -1, no leave him out
+1
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Niall Pemberton wrote:
[ ] +1, don't let Simon get away - lets try to get him to join the new PMC
[ ] -1, no leave him out
+1
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
What is a minor x.x.x release for?
Consider the recent modeler vote for 2.0.1. This will probably go
through very quickly, and that is because the change involved is tiny
and non controversial. That is what these releases are for IMHO - fixing
up release process mistakes and major bugs.
As a
I requested one of two remedies:
a) Release as 1.3.2, but undeprecate the static utility class FileCleaner
methods (they would be deprecated in 1.4). The static methods can have comments
added in 1.3.2 indicating the preferred alternative.
b) Release as 1.4.
I also have no recollection of a
[
https://issues.apache.org/jira/browse/IO-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506338
]
Stephen Colebourne commented on IO-123:
---
Unfortunately, if the block of code within the loop throws an exception
- Original Message
From: Phil Steitz [EMAIL PROTECTED]
I would like very much for us to agree
once and for all on some versioning/deprecation rules.
Exactly the thread I was about to start :-)
We seem to
have lost the old versioning guidelines (unless I am senile, we used
to have
- Original Message
From: Phil Steitz [EMAIL PROTECTED]
I would like very much for us to agree
once and for all on some versioning/deprecation rules.
Exactly the thread I was about to start :-)
We seem to
have lost the old versioning guidelines (unless I am senile, we used
to have
- Original Message
From: Henri Yandell [EMAIL PROTECTED]
Theres too much on the CLIRR report IMO for this to be a bug fix
release - I'm not that familiar with CLI but most (all?) don't seem
necessary for this 1.1 release
It is a minor, rather than bugfix. So I think it's fair to
Following subsequent discussions on other threads (and the new versioning
thread) I feel I must take a tougher line on this.
My vote for the release of 1.3.2 changes to -1.
Deprecating a class and adding a new one is inappropriate for a x.x.x release.
This should either be 1.4, or the
[
https://issues.apache.org/jira/browse/COLLECTIONS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502770
]
Stephen Colebourne commented on COLLECTIONS-255:
As a general rule, collections implementations
Jochen Wiedmann wrote:
Please cast your vote.
[ ] +1
[ ] =0
[ ] -1
Hmmm, I feel I'd like to vote -1, but that does seem a little unfair as
I obviously haven't been following that closely. Officially, my vote is
a -0.
I hadn't tracked the changes going into [io], but I was surprised to
I would normally consider a minor point release to be essential bug fix only
(in the numbering system we've been using).
Perhaps, rather than trying to release 1.3.2, we should release [io] v1.4
(still JDK1.3 compatible).
Stephen
- Original Message
From: Niall Pemberton [EMAIL
[
https://issues.apache.org/jira/browse/LANG-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497837
]
Stephen Colebourne commented on LANG-335:
-
Joda-Time, DateTimeComparator
Comparisons of Dates and Calendars
Torsten Curdt wrote:
On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
I suggest marking the offending methods as deprecated for the 1.x
series, and schedule them for removal in the 2.x series.
Well, then let's create a 2.x branch and do a release without the
classes *now*. No problem
I would expect a JDK change to be a major version number change.
Stephen
Gary Gregory wrote:
It seems like a nice coincidence that IO 1.3 is based on JRE 1.3, and we could
have IO 1.4 based on JRE 1.4, IO 1.5 on JRE 1.5 ;)
Thank you,
Gary
-Original Message-
From: Rahul Akolkar
My preference would be to support JDK1.3 and JDK1.5 versions, rather
than JDK1.4.
If desired, these calls can be implemented using reflection, so they
work on JDK1.4 but not on JDK1.3.
Stephen
Niall Pemberton wrote:
There are a couple of Jira tickets which require JDK 1.4
IO-74[1] -
Torsten Curdt wrote:
On 18.05.2007, at 13:57, Niall Pemberton wrote:
I wasn't part of the decision at the time, but (at least some if not
all) these classes are in the BeanUtils public API so changing the
package would have (and still will) broken binary compatibility (to
remove the dependency
[
https://issues.apache.org/jira/browse/COLLECTIONS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493501
]
Stephen Colebourne commented on COLLECTIONS-231:
This change cannot be made as changing
[
https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489332
]
Stephen Colebourne commented on LANG-326:
-
Is there a role for CaseInsensitiveStringUtils instead? How many
I am +1 to TLP so long as it specifies Java, possibly 'Java-focussed' to
cover [daemon]. As Phil says, thats not anti-other languages, just a
representation of community.
I also agree that 'small' isn't that useful.
Stephen
Phil Steitz wrote:
This may not be popular or a consensus view,
Henri Yandell wrote:
Personally I think we should only have the plugins defined if the
release jar itself needs them for stability. Otherwise we just deal
with whatever pain Maven is throwing everyone's way and yell at them
to fix.
Er why? It is not our job to be gump and test commons builds
Matt Benson wrote:
- was there a plan for breaking things apart into
functors, what else?
I would like to see a good discussion on what jars to produce.
- Does this really matter?--people can always use
tools to create subset jars if they can't deal with
the full-size version, no?
I
Stephen Colebourne wrote:
[X] +1 - Let him commit
[ ] 0
[ ] -1 - Perhaps not...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Stephen Kestle has been voted in as a new committer for Jakarta:
+1
Stephen Colebourne
Henri Yandell
Joerg Schaible
Simon Kitching
Niall Pemberton
Martin van dem Bemt
Phil Steitz
Oliver Heger
Oliver Zeigermann
Rahul Akolkar
Stephen K, please see
http://www.apache.org/dev/new-committers
Stephen has spent a considerable amount of effort in discussions and
chivying in the commons area, particularly on commons-collections.
In another life he has been heavily involved in one of the existing
generics ports of collections - http://collections.sf.net.
[ ] +1 - Let him commit
[ ]
Stephen Kestle wrote:
Does becoming a committer allow me to edit pages such as
http://wiki.apache.org/jakarta-commons/Collections? My first action
would be to update that so that people can figure out what we're
actually doing without trawling mailing lists.
You can do that now. Just create
[
https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne updated COLLECTIONS-243:
---
Component/s: Set
List
Bag
[
https://issues.apache.org/jira/browse/COLLECTIONS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481929
]
Stephen Colebourne commented on COLLECTIONS-110:
Note for the implementation of generics.
List
The collections tests were probably written before the concept of mocks
became widely known. I have no problems with the use of mocks for
testing in collections, provided that the license of the tool used is
compatible with Apache Software Foundation restrictions (no GPL or LGPL).
Stephen
, not ask). Should I create a
ticket to include this jar etc, or email straight to you?
Cheers
Stephen
Stephen Colebourne wrote:
The collections tests were probably written before the concept of
mocks became widely known. I have no problems with the use of mocks
for testing in collections
I've failed to be convinced by any argument to change any groupId. It
really doesn't seem to cause any harm leaving it as is, so lets leave it
as is.
Stephen
Henri Yandell wrote:
I've given up having any clue.
If I'm the RM for IO whatever and the changed groupId becomes a
blocker, then
Jochen Wiedmann wrote:
On 3/14/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
I've failed to be convinced by any argument to change any groupId. It
really doesn't seem to cause any harm leaving it as is, so lets leave it
as is.
Don't you believe that the Maven 1 conventions were changed
[
https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480199
]
Stephen Colebourne commented on COLLECTIONS-243:
With all of these cases, you also need to ask
Stephen Smith wrote:
Stephen C: earlier in this thread, you mentioned that we'll need to
throw away my current ramblings in the existing generics branch, but
thats no bad thing - how far did you get with your own work on
generifying/genericising (have we even settled on a word for what we're
OK Stephens (and anyone else!),
I'm not in a position to just grant commit access (I wish I could, but
thats not the Apache way). However, I am willing to review and apply
patches to get generified collections off the ground.
We already have a generics branch which is intended to be a
Stephen Smith wrote:
01. Removing all deprecated code - let's take the opportunity to shrink
the size of the Commons Collections JAR while we can.
+1
02. Removing (*not* deprecating) methods specifically related to type
safety pre-JSE5. I'm thinking of classes such as MapUtils here, whose
For example. if we're really going to push the boat out on this, what
about hiding public constructors in static utility classes? It's the
sort of thing CheckStyle whines about, and normally with good reason.
I've never understood why CollectionUtils#CollectionUtils is public,
even with a
Oliver Zeigermann wrote:
Could you explain what your understanding of a 'reboot' is? As opposed
to the port to generics?
A brand new implementation based on the same idea.
StarTrek TNG, Battlestar Galactica, ...
Stephen
-
To
[
https://issues.apache.org/jira/browse/COLLECTIONS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479762
]
Stephen Colebourne commented on COLLECTIONS-242:
I think such an interface is a useful
Hi all,
As you may have seen, I am now the co-spec lead for JSR-310, Date and
Time API. This will take forward my work on Joda-Time, hopefully into
Java 7.
Obviously, this is liable to take up a good proportion of my time (!),
so I'll be less able to add stuff or review in commons. Of the
Jochen Wiedmann wrote:
On 2/16/07, Jörg Schaible [EMAIL PROTECTED] wrote:
(1) The md5 files do not contain the file name, which is standard for
commons components (see section 2 of [1]).
This is the way Maven 2 generates *and* checks it. So if you change
those, I
am quite sure, that every
I'd like to know how much of 2.x is deprecated.
We may need 3.x to be JDK1.3 compatible but without the deprecations.
And thus 4.x () to be JDK1.5.
Anyway, for me, the project and version number should depend on compatibility.
We shouldn't release any new version, even of a major version number,
From: Henri Yandell [EMAIL PROTECTED]
So enum package would be removed and enums package would be deprecated
as it has a JDK replacement. We would then add functionality around
the JDK enums to provide some/all of the value back.
maybe.
Adding binary compatible generics is a pain in the arse
Henri Yandell wrote:
I would like to avoid the silliness of 'Lang5 1.0, much nicer to
emulate Sun's silliness and jump to Lang 5.0, so it sounds like:
I suspect that Lang5 1.0 is clearer.
1) Create a branch in Lang for the Lang5 version.
2) Change package name to be org.apache.commons.lang5
+1
We probably should mark the static changed method as @since 1.3.1, but
that is not a blocker.
Stephen
Henri Yandell wrote:
Going with RC3:
http://people.apache.org/~bayard/commons-io/1.3.1-rc3/
The only change is that I've fixed the manifest to say 1.3.1 and not 1.3.
[ ] +1
[ ] -1
The release notes have the wrong JIRA number in the incompatability section.
Stephen
[EMAIL PROTECTED] wrote:
Henri Yandell [EMAIL PROTECTED] wrote:
I screwed up the 1.3 release, so here's a 1.3.1 release:
http://people.apache.org/~bayard/commons-io/1.3.1-rc1/
+1
[
https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471523
]
Stephen Colebourne commented on IO-113:
---
I think that we can probably get away with option (b) if we are quick
[
https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471117
]
Stephen Colebourne commented on IO-113:
---
Problem is that the fix is binary incompatible :-(
It is source
Missing LICENSE and NOTICE in -sources.jar and -javadoc.jar.
Missing pom.xml in src bundle.
Stephen
Henri Yandell wrote:
Here's the 2nd release candidate for Lang 2.3:
http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/
Clirr, Jardiff + Site included.
[ ] +1
[ ] -1
Vote
LICENSE and NOTICE missing from -sources.jar and -javadoc.jar
Website has lost a lot of stuff compared to existing website
Stephen
Jochen Wiedmann wrote:
On 2/7/07, Oliver Heger [EMAIL PROTECTED] wrote:
Hm, I probably did not follow this thread in the past, so can you please
point me to
This sounds a little too specific for me. I suspect that most people
that want an expiring map will want it to be active not passive.
Stephen
Elifarley wrote:
I've developed a Map decorator which passively evicts expired entries once their
expiry time has been reached.
When putting an item
Its at the RMs discretion as to whether he wants a new RC.
James Carman wrote:
Is that a -1?
On 2/7/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
Missing LICENSE and NOTICE in -sources.jar and -javadoc.jar.
Missing pom.xml in src bundle.
Stephen
Henri Yandell wrote:
Here's the 2nd
I'm sorry, but I find this extremely complicated and unreasonable. It
really, really, really isn't a direction I want commons to take.
Firstly, the use of a static will annoy the IoC (Spring) crowd, so that
aspect of the proposal seems flawed.
Secondly, this proposes adding a whole ream of
Rahul Akolkar wrote:
On 2/2/07, Niall Pemberton [EMAIL PROTECTED] wrote:
On 2/1/07, Henri Yandell [EMAIL PROTECTED] wrote:
What do people think - update PROPOSALs or delete them?
Neither - leave it unchanged. It is historical and I think it is
obvious it is, many (most?) components have them
+1
Although compared to [io] we probably should have a sources and javadoc
jar in the zips as well.
Stephen
Henri Yandell wrote:
Next up - Lang 2.3.
Here's the release candidate:
http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc1/
Clirr, Jardiff + Site included.
[ ] +1
[
Any chance you could unzip the site?
Stephen
Henri Yandell wrote:
Next up - Lang 2.3.
Here's the release candidate:
http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc1/
Clirr, Jardiff + Site included.
[ ] +1
[ ] -1
Vote to close on Monday if it gets that far.
There is an
Jörg Schaible wrote:
My bottom line: If you build an application, you have
to do localization (of exception and logging) at the application
layer, because only there you can give the user a context, that is
really useful. This implies catching exceptions from libraries and
wrapping them
Phil Steitz wrote:
I am interested in what others have to
say about this as a general practice for commons. For [math] specifically,
I think it is important that we can fit seamlessly into localized
applications, and we are refactoring our exceptions hierarchy anyway, so I
say go for it.
I
+1
Stephen
Henri Yandell wrote:
I've made a third release candidate of IO 1.3, tagged IO_1_3_RC3.
Available at:
http://people.apache.org/~bayard/commons-io/1.3-rc3/
Various build files, clirr/jardiff reports and the proposed site.
[ ] +1
[ ] -1
Vote to end on Monday (if it makes it that
[
https://issues.apache.org/jira/browse/IO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467701
]
Stephen Colebourne commented on IO-109:
---
The new IO v1.3 release is going to use -kP. Let us know if this works
Two points
a) The manifest says version 1.2. Must be fixed.
b) The javadoc jar soesn't contain the LICENSE.txt or NOTICE.txt. Not
sure if this matters.
Stephen
Henri Yandell wrote:
I've made a second release candidate of IO 1.3, tagged IO_1_3_RC2.
Available at:
Matt Benson wrote:
What's the current status of collections? It needs to
be broken into smaller pieces before any more weight
can be added?
Yes, I believe thats a good approach. And the Java 5 branch needs finshing.
Stephen
From: Henri Yandell [EMAIL PROTECTED]
Yeah, I'm quite interested in what the response is to having this in
the API. It's novel (for me), but could be interesting to release IO
as is and see what feedback we get from users on the feature.
That would seem rather irresponsible. They will almost
Henri Yandell wrote:
So consensus so far seems to be towards leaving it in.
Well I'll remove my vote -1 then. But I still think its poor design.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
From: Henri Yandell [EMAIL PROTECTED]
This helps with naming, but without the scoping, you're left with the
Javadocs as the only way to specify that the exception is intended to be
used only within the DirectoryWalker class. Of course, a public static inner
class can be used elsewhere as
-1, here's why...
After reviewing the javadoc, I realised that having an inner class as an
exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong
in code.
I propose that this exception is promoted to a top level class, and
renamed to DirectoryWalkCancelledException.
Since
Martin Cooper wrote:
Could you say more about this, please? I happen to disagree on
exceptions as
inner classes being a bad idea; FileUpload has done this for years, without
any problems. But I'm always interested in hearing new perspectives...
I guess its stylistic, and therefore subjective.
+1
Henri Yandell wrote:
As you can see on the list, Matt would like to help out with JXPath.
Matt's been an Ant committer since Feb 2004. He's been active on the
dev/user lists over the last couple of years, so not a new face here
either.
[ ] +1
[ ] -1
Will end the vote on Tuesday morning.
Matt Benson wrote:
Can somebody (Henri?) offer advice on what I and/or
other members of the (user and/or Apache committer)
community might do to get the ball rolling?
Some things to think about:
- updating the license in each source file to the latest ASF standards
- update the xdocs site
Henri Yandell wrote:
Anything need fixing up before doing the real build?
I don't like the new table on the home page. I think it provides too
much information, and mainly information that isn't that relevant.
Its also inconsistent with the other similar commons sites, notably in
that
Stephen Kestle wrote:
If an Equator is determined to be something worthwhile for the next
(generic) version of Collections, I can provide interfaces, default
implementations tests etc.
I certainly think that there are multiple ways to to equals checks. In
my day job we compare by ==, equals
[
https://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne updated LANG-306:
Attachment: lang.patch
Extra StrBuilder methods
Jörg Schaible wrote:
M2 creates -sources.jar files :)
Personally, I like -src-ide.zip, but I can't be bothered to fight the
maven god on this.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
BooleanUtils isNotTrue/isNotFalse
-
Key: LANG-310
URL: https://issues.apache.org/jira/browse/LANG-310
Project: Commons Lang
Issue Type: Improvement
Reporter: Stephen Colebourne
Assigned
[
https://issues.apache.org/jira/browse/LANG-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne closed LANG-310.
---
Resolution: Fixed
svn commit C:\dev\commons\lang\RELEASE-NOTES.txt
C:\dev\commons\lang\src
[
https://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne closed LANG-306.
---
Resolution: Fixed
Assignee: Stephen Colebourne
svn commit C:\dev\commons\lang\RELEASE
[
https://issues.apache.org/jira/browse/LANG-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne closed LANG-275.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.3
Assignee
Rahul Akolkar wrote:
+ * BooleanUtils.isNotTrue(Boolean.TRUE) = true
+ * BooleanUtils.isNotTrue(Boolean.FALSE) = false
+ * BooleanUtils.isNotTrue(null) = true
+ */
+public static boolean isNotFalse(Boolean bool) {
+return !isFalse(bool);
+}
+
[
https://issues.apache.org/jira/browse/LANG-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462109
]
Stephen Colebourne commented on LANG-309:
-
The problem with the arrays methods is that there are a lot of them
Extra StrBuilder methods
Key: LANG-306
URL: http://issues.apache.org/jira/browse/LANG-306
Project: Commons Lang
Issue Type: Improvement
Reporter: Stephen Colebourne
Priority: Minor
[
http://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Colebourne updated LANG-306:
Attachment: StrBuilder.java
Extra StrBuilder methods
Phil Steitz wrote:
The [dbcp] javadoc includes links to [pool] APIs. Currently, [dbcp]'s
maven.javadoc.links points to
http://jakarta.apache.org/commons/pool/apidocs,
which is no good, since this will in general point to the current
development API. I was going to fix this by following the
Dennis Lundberg wrote:
1. What should a source distribution include?
Two things:
- commons-foo-1.0.jar - the binary jar
- The entire svn tree for the project
I include the binary jar file in the source distribution as I want to
ensure that the maximum number of people possible get the
I think it may allow the jar to be created on JDK1.3, and the dist on
JDK1.4, but you'll need to check that.
[EMAIL PROTECTED] wrote:
Author: bayard
Date: Tue Jan 2 14:47:03 2007
New Revision: 491956
URL: http://svn.apache.org/viewvc?view=revrev=491956
Log:
Don't get the point of 'dist' and
[
http://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461869
]
Stephen Colebourne commented on LANG-306:
-
Decision of the Release Manager. I wasn't expecting that they would
[
http://issues.apache.org/jira/browse/LANG-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461614
]
Stephen Colebourne commented on LANG-238:
-
This newly defined method seems a little unusual - is it really
I'll be honest and say I dislike the convention of using code for
null, as as such I'm not greatly enthused by this change. I'd prefer if
no more files were changed.
This comes down to my basic tenet that javadoc is for developers to
read, and it is *frequently* read as source code, not as an
This was a recent bug fix. Do we have tests to show that removing this
cast doesn't cause the bug to reappear?
Stephen
[EMAIL PROTECTED] wrote:
Author: ggregory
Date: Sat Dec 30 17:08:34 2006
New Revision: 491359
URL: http://svn.apache.org/viewvc?view=revrev=491359
Log:
Remove unnecessary
[ http://issues.apache.org/jira/browse/IO-99?page=all ]
Stephen Colebourne resolved IO-99.
--
Resolution: Fixed
Assignee: Stephen Colebourne
I took a look at getTrackerCount(), but its already synchronized because the
list is a Vector. I added
[ http://issues.apache.org/jira/browse/IO-97?page=all ]
Stephen Colebourne resolved IO-97.
--
Fix Version/s: 1.3
(was: 1.4)
Resolution: Fixed
Assignee: Stephen Colebourne
Trivial performance improvements
1 - 100 of 1816 matches
Mail list logo
