Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
To: commons-dev@jakarta.apache.org
Path: not-for-mail
From: "Henning P. Schmiedehausen" <hps@intermeta.de>
Newsgroups: hometree.jakarta.commons.dev
Subject: Re: [configuration] Loading and Saving
Date: Wed, 8 Sep 2004 14:30:41 +0000 (UTC)
Organization: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
Lines: 78
Message-ID: <chn52h$dlj$1@tangens.hometree.net>
References: <chkref$q3m$1@tangens.hometree.net> <413EE28F.8060203@lfjr.net>
Reply-To: hps@intermeta.de
NNTP-Posting-Host: forge.intermeta.de
NNTP-Posting-Date: Wed, 8 Sep 2004 14:30:41 +0000 (UTC)
User-Agent: nn/6.6.5

Emmanuel Bourg <smanux@lfjr.net> writes:

>Henning P. Schmiedehausen wrote:

>> I like all of this. However, even more I'd like to get 1.0 finally out
>> of the door. I'm really willing to tell our users, that they can rely
>> only on the non-deprecated method signatures in the
>> o.a.c.c.Configuration interface and that everything else can and will
>> be changed post-1.0, but for the moment, getting this stuff released
>> is my #1 prio.

>Releasing the 1.0 final is also my top priority, while I agree to 
>sacrifice features for this (like automatic reloading, support for 
>additional types & more configuration formats) I don't want to sacrifice 
>quality (API consistency, testing & documentation), that's why I call 
>for these changes now. I don't want to be tied to backward compatibility 
>concerns once 1.0 is released because we didn't take the time to address 
>these inconsistencies.

The C'tors pose no problems as we can add them even after a
release. For the missing methods:

- Are they defined by an interface somewhere? As far as I can see, they
  are not. We should then at least define them by an interface (not
  Configuration please), so users know what to expect from the various
  Configuration implementations.

- Adding the missing methods can be as simple as

  public void fooMissing(...) {
    throw new UnsupportedOperationException("Not yet implemented");
  }

Yeah, not really user friendly but it would help to get the API in shape
without having to write too much new Code.

>Well, the merit of the rc1 is to provide and temporary official release 
>that can sweep away the various unofficial snapshots and bring more 
>testing and feedback on the project. But I don't consider it good enough 
>in this state to become a final release.

The unfortunate thing with rc1 is, that it is missing getVector()
which is crucial to c-c users like Turbine or Torque. And there is
also the changed semantics w.r.t get<xxx>(String propertyName)
(Exception vs. null). So it is not a matter of simple replacing.

As I wrote before, I'm -0 on releasing the current state as 1.0
because of the semantics changes. The same thing basically applies to
the current state as rc2. The rc1 problems are clearly visible. You
drop rc1 into a Turbine application, then it crashed immediately. You
drop the HEAD into a Turbine application, the errors are much more
subtle and hard to find.

>> So please. Let's find an agreement on the get<xxx> semantics, do one
>> more RC and the CfV the release.

>I don't mind if we revert to a null-when-missing semantic now and add a 
>switch later for exception-when-missing.

I'm +1 with this. Eric? 

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

"Fighting for one's political stand is an honorable action, but re-
 fusing to acknowledge that there might be weaknesses in one's
 position - in order to identify them so that they can be remedied -
 is a large enough problem with the Open Source movement that it
 deserves to be on this list of the top five problems."
                       -- Michelle Levesque, "Fundamental Issues with
                                    Open Source Software Development"

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org