James Carman schrieb:
>
> This pattern (replacing the implementation of specific methods) is not
> supported "out of the box" by Proxy, but perhaps it should be? I
> wonder how common it is that you'd want to replace the implementation
> of certain methods and you wouldn't just go ahead and extend
James Carman schrieb:
> On Wed, Nov 5, 2008 at 4:04 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
>
>> So the rule would be:
>> * the project provides both an interface and an abstract class that
>> implements that interface.
>> * code that *uses* the API
Jörg Schaible schrieb:
>>> IMHO we should define what we want to reach. Adding a
>>> method to an interface does not break *binary* compatibility
>>> of existing code. The method is simply not called. However, a
>>> client will have to implement the new method, if CConf is a
>>> compile time depend
Jörg Schaible schrieb:
Hi Hendrik,
Hendrik Maryns wrote:
Hi,
I have downloaded and edited Commons CLI. It works fine after some
configuring in Eclipse. Building from the command line,
however, fails,
both with Ant and with Maven.
Ok, that is not entirely true: ant dist works in that it
p
sebb schrieb:
On 16/09/2008, Jörg Schaible <[EMAIL PROTECTED]> wrote:
sebb wrote:
> On 16/09/2008, Simon Kitching <[EMAIL PROTECTED]> wrote:
[snip]
It's not quite clear to me why a threadlocal is being used here. I'm
>> guessing it is for
sebb schrieb:
On 16/09/2008, Simon Kitching <[EMAIL PROTECTED]> wrote:
One other concern is regarding garbage collection. From a brief look at the
code, this thread-local registry object contains a set of Integer hashcodes.
With this change, the set will now contain real hard referen
sebb schrieb:
I think I've found a fix to LANG-459 - which is to borrow some code
from Apache Axis.
The required code is a single short class - IDKey (e.g.
http://www.jdocs.com/axis/1.4/org/apache/axis/utils/IDKey.html)
It could be added as a private class of HashCodeBuilder, but it has
wider u
Luc Maisonobe schrieb:
Maven also failed with a fatal error trying to compare with version
1.8.0-BETA which it did not found (I'm not even sure it tried to
download it). I fixed this again by downloading and installing both the
pom and jar file manually.
This is a known bug with the clirr p
Hi All,
People here may want to be aware of some changes with regard to the m2
snapshot repo on people.apache.org.
On 5 Aug the intrastructure team deleted every file in the snapshot repo
which is more than 30 days old. They intend to do this on a regular
basis from now on.
As a result, if
Hi Aaron,
This is the right list, and your suggestion makes good sense.
Beanutils is a fairly quiet project (though not dead). There are a
couple of people who work on it regularly, and I'm sure there will be an
answer from them. I'm a little surprised they haven't responded already,
but perhaps
Niall Pemberton <[EMAIL PROTECTED]> schrieb:
> On Feb 6, 2008 1:44 PM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
> > > Deprecation is useful when a method has been
> > > implemented inco
Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
> Deprecation is useful when a method has been
> implemented incorrectly, and we want to push users
> to a replacement, or for similar issues. Removing deprecated
> classes/methods should be considered in a major version change,
> but even there
Niall Pemberton <[EMAIL PROTECTED]> schrieb:
> I don't see why people are voting -1 on all of this when its only
> certain jars in question. IMO those that have an AL 2.0 and NOTICE
> file are good to go. Those with missing bits should be -1 (betwixt
> 0.5, httpclient 3.1, jxpath 1.2, pool 1.0
Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
> > On Feb 4, 2008 8:47 PM, Niall Pemberton <[EMAIL PROTECTED]>
>> From memory the preference was to move to a new package name - how
>> about "org.apache.commons.io2"?
To avoid confusion with version numbers, we could choose [io-two]:
org.ap
sebb <[EMAIL PROTECTED]> schrieb:
> I'm working on a Perl script to check that SVN properties have sensible
> values.
>
> I've tried it against some Commons projects, and found a few with
> rather odd settings, for example the following files are all flagged
> as svn:executable:
>
> Commons
Hi Siegfried,
Siegfried Goeschl <[EMAIL PROTECTED]> schrieb:
> Hi folks,
>
> since my last releases of Fulcrum components reminded me of the dark
> ages of release management I decided to move Fulcrum to M2
> +) I still have problems with the svn report - it picks up everything
> which I
Seconded about jars in svn. It's just clutter.
Perhaps if an apache project needs a jar for a project that has not yet
published it, the jar could be placed in the apache snapshot repo?
A custom groupid, like "external.example.foo" or "tmp.example.foo" (instead of
the real group "example.foo")
Hi Robert,
If the question is whether or not to host/develop such stuff here in the
commons project, I would think it unlikely.
As Henri noted, most of these libs would need to be significantly rewritten,
rather than just "translated". And I expect that there is not a lot of c#
knowledge (or i
sebb <[EMAIL PROTECTED]> schrieb:
> On 22/01/2008, Jörg Schaible <[EMAIL PROTECTED]> wrote:
> > Mark Proctor wrote:
> > > Torsten Curdt wrote:
> > >>
> > >> On 21.01.2008, at 10:08, Tom Schindl wrote:
> > >>
> > >>> Hi Torsten,
> > >>>
> > >>> I understand this but we are seeing many J2EE-Serv
Torsten Curdt <[EMAIL PROTECTED]> schrieb:
>
> On 21.01.2008, at 10:08, Tom Schindl wrote:
>
> > Hi Torsten,
> >
> > I understand this but we are seeing many J2EE-Servers adopting OSGi
> > and many applications
> > (I admit most of them in Eclipse-world) also. It seems strange to
> > me
Apache Wiki <[EMAIL PROTECTED]> schrieb:
> set up. Therefore adding OSGi attributes to commons-logging is not useful,
> as commons-logging
> is not usable in an OSGi environment.
>
> + ''niallp: Can't be? But what if it is, logging is used by many so I would
> be surprised if its not.
Luc Maisonobe <[EMAIL PROTECTED]> schrieb:
> Niall Pemberton wrote:
>
> > I'd like to release commons-sandbox-parent pom version 3 - then last
> > release used commons-parent version 4 and the only changes are to
> > upgrade to the latest version 7 of commons-parent and update the
> > plugin
[EMAIL PROTECTED] schrieb:
> - See the License for the specific mathuage governing permissions
Guess org.apache.commons.lang was the template used for this file :-)
:1,$s/lang/math/g
-
To unsubscribe, e-mail: [EMAIL PR
Hi,
I just happen to be experimenting with a project that used something called
org.apache.commons.jrcs, and was puzzled as I had never heard of it.
Eventually I found it here:
http://svn.apache.org/repos/asf/commons/dormant/
Interestingly, there are 40 project directories in the svn dormant
Niall Pemberton <[EMAIL PROTECTED]> schrieb:
> On Jan 14, 2008 9:13 PM, Oliver Heger <[EMAIL PROTECTED]> wrote:
> > The artifacts look good, the build also succeeded in all variants (on a
> > JDK 1.6). So I am +1 for this release.
> >
> > Two minor points:
> > - On my first attempt to build wi
Phil Steitz <[EMAIL PROTECTED]> schrieb:
> I agree here, but also with Luc's point above about logging not being
> part of the API contract. So the problem is how do you support the
> use case above and one more: configurable debug/trace information. I
> don't want to hijack this thread, but
Dennis Lundberg <[EMAIL PROTECTED]> schrieb:
> simon wrote:
> > On Thu, 2008-01-10 at 21:11 +0100, Dennis Lundberg wrote:
> >> sebb wrote:
> >>> AIUI, the NOTICE file is not about dependencies, it is about the
> >>> artefacts that are actually included in the distribution.
> >>>
> >>> In the c
Gary Gregory <[EMAIL PROTECTED]> schrieb:
> Hello all:
>
> I am seeing two types of names in project.xml name elements. For a project
> "Foo":
>
> - Foo
> - Commons Foo
>
> Can we standardize one pattern for all [commons] projects?
>
> Current examples:
>
> Codec (SVN)
> Commons Pool (SV
Jochen Wiedmann <[EMAIL PROTECTED]> schrieb:
> On Jan 10, 2008 9:04 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
>
> > No. What I am saying is that the NOTICE file should have *only* information
> > about the files in the current maven module. The NOTICE sh
Jochen Wiedmann <[EMAIL PROTECTED]> schrieb:
> On Jan 10, 2008 8:51 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
>
> > Sorry to repeat myself again, but I really do not think the
> > maven-remote-resources approach is
> > even legal. IANAL, but as I
Jochen Wiedmann <[EMAIL PROTECTED]> schrieb:
> On Jan 9, 2008 11:16 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
>
> > No, not in my opinion. We've agreed to disagree on which way to go with
> > this. There are two option, each with its merits and flaws.
> >
> > A) Use maven-remote-resource
Niall Pemberton <[EMAIL PROTECTED]> schrieb:
> On Jan 8, 2008 4:11 PM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > > > Does the current parent pom deal with adding NOTICE.txt and
> > > > LICENSE.txt to the javadoc jar files?
> > >
> > > No - but AIUI it doesn't need to since it only contains
Niall Pemberton <[EMAIL PROTECTED]> schrieb:
> On Dec 14, 2007 6:35 AM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > Seems like a bad idea to me, but I might not be understanding it correctly.
> >
> > 1) Does this mean the LICENSE and NOTICE file are not sitting in svn
> > next to the source?
"Jörg Schaible" <[EMAIL PROTECTED]> schrieb:
> Oliver Heger wrote:
> > (There was a similar discussion about commons lang recently.)
> >
> > Configuration used to support JDK 1.3. For the next release (either
> > 1.6 or 2.0) I would like to drop this compatibility. The number
> > of feature
>
Joerg Hohwiller <[EMAIL PROTECTED]> schrieb:
> Could you please change the groupId to "org.apache.commons.logging".
> It is an ugly legacy problem that many projects are still ignoring the maven
> conventions.
>
> Here are the good boys that have already been convinced:
> http://repo1.maven.o
sebb <[EMAIL PROTECTED]> schrieb:
> On 18/11/2007, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
>
> > > Some files in the tagged directory tree are not in the distribution zip:
> > >
> > > xdocs/**
> > > build-testing.xml
> > > commons-logging-api.pom
> > > doap_logging.rdf
> > > PROPOSAL.html
Hi Dennis,
It's great to see you're working towards a JCL release.
However there is one problem that probably should be resolved before the
release: the unit tests related to java.util.logging fail on Java 1.6. It looks
like the mechanism used by the unit tests to install a custom java.util.lo
37 matches
Mail list logo
