On Thu, Jun 12, 2008 at 4:45 PM, Matt Benson [EMAIL PROTECTED] wrote:
--- Niall Pemberton [EMAIL PROTECTED] wrote:
On Fri, May 2, 2008 at 6:48 PM, Matt Benson
[EMAIL PROTECTED] wrote:
Thanks, Seb.
I changed the m1 build to use JUnit 3.8.1 and add
the new dependency
for mockrruner:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The following page has been changed by MattBenson:
http://wiki.apache.org/commons/CommonsPeople
--
*
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The following page has been changed by MattBenson:
http://wiki.apache.org/commons/CreatingReleases
--
*
Have I mentioned I HATE Maven? I don't understand how
something that looks innocuous like building an RC can
go out and update the production website, which,
AFAICT, isn't backed up anywhere, so I guess I'll be
trying to regen it from the previous release. Can
anyone tell me simply exactly what
--- James Carman [EMAIL PROTECTED] wrote:
You're right, imagining the profanity makes this
message much more
enjoyable! :)
I don't know about that, but I know that writing it
without felt awfully stifling.
You need to use the rc profile when building a
release candidate.
The default
Update: Luckily pquerna was available on #asfinfra
and retrieved the production site from www before it
got synched with the new content. I couldn't get
JXPATH_1_2 to build the Maven 1 site... though I did
find an email trail where jcarman had had the same
problem before:
Could not find the
On Fri, Jun 13, 2008 at 12:27 AM, Matt Benson [EMAIL PROTECTED] wrote:
Update: Luckily pquerna was available on #asfinfra
and retrieved the production site from www before it
got synched with the new content. I couldn't get
JXPATH_1_2 to build the Maven 1 site... though I did
find an email
I haven't been following this list all that long so I'm interested in
knowing why you want the package names changed. (I apologize in advance
to those who have already heard this before).
BTW - I'm +1 on Java 5. Not only for lang but for a bunch of commons
projects.
James Carman wrote:
On
James Carman schrieb:
On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson [EMAIL PROTECTED] wrote:
There is a JIRA item for using generics, and another
for varargs. Additionally it'd probably be nice to
use generics-level reflection in the oacl.reflect
package. Thoughts on [lang] 3.0 moving to
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
I'm also +1 for changing the package name because one can not assume
that everybody is using Felix, Equinox or other OSGi-Envs.
Tom
[EMAIL PROTECTED] schrieb:
James Carman schrieb:
On Wed, Jun
Tom Schindl schrieb:
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
Yep. Well, it works for those libs that are just internal implementation
details.
I'm not an OSGi expert, but if any exported class contains a public or
protected method that has
I think we should ask the felix people what can be solved with OSGi and
what can not.
Tom
[EMAIL PROTECTED] schrieb:
Tom Schindl schrieb:
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
Yep. Well, it works for those libs that are just internal
Hi!
+1 on generics
+99 on package-name change.
+100
The ASM project (org.objectweb.asm) changes their API significantly with
major releases, but do not change the package name. And it causes major
pain. For example, the following libs all require specific versions of ASM:
* hibernate
*
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-vfs has an issue affecting its community integration.
This issue affects
On Thu, Jun 12, 2008 at 4:43 AM, James Carman
[EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson [EMAIL PROTECTED] wrote:
There is a JIRA item for using generics, and another
for varargs. Additionally it'd probably be nice to
use generics-level reflection in the
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
P.S. Perhaps its a moot point in Lang's case since I guess the
deprecated enum package has to be removed to move to a minimum of JDK
1.5.
Do you mean that the removal of the enums would mean that we have to
change
On Thu, Jun 12, 2008 at 2:46 AM, Ralph Goers [EMAIL PROTECTED] wrote:
I haven't been following this list all that long so I'm interested in
knowing why you want the package names changed. (I apologize in advance to
those who have already heard this before).
Sure. We should probably have a
On Thu, Jun 12, 2008 at 12:19 PM, James Carman
[EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
P.S. Perhaps its a moot point in Lang's case since I guess the
deprecated enum package has to be removed to move to a minimum of JDK
1.5.
Do
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
I would agree that for Lang that *if* the API change breaks
compatibility, then a package name change would be appropriate - but I
think its a mistake in general to start making decisions along the
lines JDK
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
Do you mean that the removal of the enums would mean that we have to
change package names?
Would class/interface removals necessitate a
package name change? I haven't really thought that through.
Perhaps not,
On 12/06/2008, James Carman [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
Do you mean that the removal of the enums would mean that we have to
change package names?
Would class/interface removals necessitate a
package name
On Thu, Jun 12, 2008 at 8:05 AM, sebb [EMAIL PROTECTED] wrote:
Removal of a *public* interface/method/class means that the API is not
compatible, as it is not possible to replace the jar without breaking
classes that use these items.
I guess I was thinking of the situation where you'd have
sebb a écrit :
BTW, perhaps Commons should have a similar naming convention for
packages that need to contain public methods, but which are only
intended to be used in Commons libraries.
Or a big DO NOT USE THIS CLASS, RESERVED FOR INTERNAL USE in the Javadoc ?
Emmanuel Bourg
[EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
I would agree that for Lang that *if* the API change breaks
compatibility, then a package name change would be appropriate - but
I think its a mistake in general to start making decisions
Phil Steitz wrote:
Yes, and I would distinguish performance optimization from numerical
accuracy. From my perspective, we can release a .0 with room for
performance improvement, but at least decent numerics are required.
I agree that decent numerics are required. I'm still rather
Emmanuel Bourg schrieb:
sebb a écrit :
BTW, perhaps Commons should have a similar naming convention for
packages that need to contain public methods, but which are only
intended to be used in Commons libraries.
Or a big DO NOT USE THIS CLASS, RESERVED FOR INTERNAL USE in the
Javadoc ?
In
James Carman schrieb:
On Thu, Jun 12, 2008 at 8:05 AM, sebb [EMAIL PROTECTED] wrote:
Removal of a *public* interface/method/class means that the API is not
compatible, as it is not possible to replace the jar without breaking
classes that use these items.
I guess I was thinking
Well the whole commons stack now has support for OSGi and OSGi provides
a mechanism to not export a package so I'd say one should use the
internal package (e.g. org.apache.commons.lang.internal) for all classes
that have to be public but are not part of the public API.
This is better than
James Carman wrote:
Perhaps we need to come up with a standardized versioning strategy for
Commons projects, then. A simple rule might be that if you're
breaking compatibility, you have to jump major versions and change
your package names (I would argue that whenever we jump version
numbers,
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
[EMAIL PROTECTED] wrote:
This confuses me. Doesn't the fact that since the code will no longer run on
a pre-1.5 JDK mean that compatibility is broken, even if not a single line
of code changes? (Yes - I know that we technically only release source
James Carman wrote:
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
[EMAIL PROTECTED] wrote:
This confuses me. Doesn't the fact that since the code will no longer run on
a pre-1.5 JDK mean that compatibility is broken, even if not a single line
of code changes? (Yes - I know that we
Yes, of course! :) But, who does that anymore? ;) I'm kidding of
course. I know that some vendors only support JDK 1.4 currently.
On Thu, Jun 12, 2008 at 11:16 AM, Ralph Goers
[EMAIL PROTECTED] wrote:
James Carman wrote:
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
[EMAIL PROTECTED]
Ralph Goers schrieb:
James Carman wrote:
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
[EMAIL PROTECTED] wrote:
This confuses me. Doesn't the fact that since the code will no
longer run on
a pre-1.5 JDK mean that compatibility is broken, even if not a
single line
of code changes?
--- Niall Pemberton [EMAIL PROTECTED] wrote:
On Fri, May 2, 2008 at 6:48 PM, Matt Benson
[EMAIL PROTECTED] wrote:
Thanks, Seb.
I changed the m1 build to use JUnit 3.8.1 and add
the new dependency
for mockrruner:
Niall, I apologize for having failed to express my
appreciation of this
34 matches
Mail list logo
