Mailing-List: contact empire-db-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: empire-db-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
Subject: re: EMPIREDB-38, switch to slf4j
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 24 Jan 2011 21:46:40 +0100
Message-ID: <B297D4737108A0459B66C3A85BB7F90127CCEB@kn.esteam.de>
In-Reply-To: <4D3D5F18.4080808@arcor.de>
Thread-Topic: re: EMPIREDB-38, switch to slf4j
thread-index: Acu7t1o19IwoXpsWTlmx0fRTmwgPewAUBlwA
References: <AANLkTi=BW7oDTkUEKFXAvhbN1T8t7p6_wyMb-t_WdZ3n@mail.gmail.com>
 <4D3CC64E.3050707@arcor.de>
 <AANLkTi=D087KuPomr0XgLXOPzGqHOA0R0rc_993Ns-Au@mail.gmail.com>
 <4D3D5F18.4080808@arcor.de>
From: =?iso-8859-1?Q?Rainer_D=F6bele?= <doebele@esteam.de>
To: <empire-db-dev@incubator.apache.org>

Hi Benjamin,=20

glad to hear that you want to take on this issue.

But before you start, we should make our minds up what exactly we want =
to achieve and how we are going to do this.

I don't think it is necessary or desirable to put all =
org.apache.empire.xml classes into a separate module.

Regards
Rainer


Benjamin Venditti wrote:
> from: Benjamin Venditti [mailto:benjamin.venditti@arcor.de]
> to: empire-db-dev@incubator.apache.org
> re: Re: EMPIREDB-38, switch to slf4j
>=20
> Hi Francis,
>=20
> would be great if you could put the org.apache.empire.xml package to a
> separate module.
> I'll start switching to slf4j later this evening.
>=20
> What do you think would be best? Switch each module successively or =
all
> in one step?
>=20
> Cheerio,
>      Benjamin
>=20
>=20
>=20
> Am 24.01.2011 09:50, schrieb Francis De Brabandere:
> > Hi Benjamin,
> >
> > Maybe I would first split off the org.apache.empire.xml package to a
> > empire-db-config module that can still depend on log4j.
> >
> > I can take care of that today. Afterwards we can switch everything =
to
> > slf4j except that config. We need to make sure we sync here and work
> > fast so that not everybody is blocked waiting for this big change...
> >
> > Shall I make that change?
> >
> > Also for slf4j make sure we switch to the parametrized logging and
> you
> > could also remove a lot of unneeded String.valueOf() calls.
> >
> > Cheers,
> > Francis
> >
> > On Mon, Jan 24, 2011 at 1:22 AM, Benjamin Venditti
> > <benjamin.venditti@arcor.de>  wrote:
> >> Hey there,
> >>
> >> i thought i could contribute a little for the next release and had =
a
> look at
> >> the open-issues list for the upcoming release. I picked up =
EMPIREDB-
> 38
> >> "switch to slf4j" as i think i can handle it (not so sure with the
> other
> >> issues), and it shows to be unassigned.
> >>
> >> My first impression is that it involves not to much work, we would
> have to
> >> get rid of calls to "log.fatal(...)" as slf4j just offers 5 instead
> of 6
> >> logging levels. Do we make any destinction between fatal and
> "normal"
> >> errors? If not, we can simply map fatal to error.
> >>
> >>     slf4j.Logger:                                     debug, error,
> info,
> >> trace, warn
> >>     apache.commons.logging.Log:      trace, debug, info, warn,
> error, fatal
> >>
> >> And there is a "LogFactory.releaseAll();" which i'm not sure how to
> map in
> >> slf4j.
> >>
> >> The "DOMConfiguration" stuff will be removed as far is i =
understood,
> as this
> >> is neccessary for the configuration of the specific logging
> implementation
> >> which will now go into a different config file.
> >>
> >> I suggest to switch logging to slf4j in the whole project. That way
> i could
> >> start with non crutial parts of the project, like the examples, and
> i
> >> wouldn't have to worry about messing up the core. And in the end we
> will
> >> have consistent logging in the whole project.
> >>
> >> Please let me know what you think?
> >>
> >>     Best Regards
> >>
> >>
> >>
> >> Am 22.01.2011 19:34, schrieb Francis De Brabandere:
> >>> Hello there.
> >>>
> >>> As empire-db is struggling a bit to grow a community, and we need =
a
> >>> bigger community to graduate, we want to involve our users in the
> >>> decision on where to go with the project.
> >>>
> >>> Below you'll find some questions and we would be delighted to hear
> >>> your comments!
> >>>
> >>> * Where do you use empire-db? or what keeps you from using empire-
> db?
> >>> * If you evaluated empire-db but switched to something else we
> would
> >>> like to know what you are using.
> >>> * How do you feel about the project?
> >>> * Is there anything we could do better?
> >>> * What should we put more effort into?
> >>> * Would you be interested in contributing. For example helping =
with
> >>> documentation, examples, blog posts, or adding functionality.
> >>>
> >>> Thanks,
> >>>
> >>> The empire-db team.
> >>>
> >>> -- our incubator report as reference below --
> >>> http://wiki.apache.org/incubator/January2011
> >>>
> >>> Empire-db
> >>>
> >>> Apache Empire-db is a relational database abstraction layer that
> >>> allows developers to take a more SQL-centric approach in
> application
> >>> development than traditional ORM frameworks. Its focus is to allow
> >>> highly efficient database operations in combination with a maximum
> of
> >>> compile-time-safety and DBMS independence.
> >>>
> >>> Project development since the last report
> >>>
> >>> Last December we have finished and published release 2.0.7 that
> >>> features some minor improvements and bug fixes. Currently we are
> >>> working on release 2.1.0 with more significant improvements.
> >>>
> >>> Issues to address in the move towards graduation and community
> development
> >>>
> >>> After now being 2 and a half years in the incubator we have =
managed
> to
> >>> successfully implement and establish the Apache development and
> >>> release cycle, we have published several releases and we have
> received
> >>> good feedback from users who are subscribed to the dev and user
> lists.
> >>>
> >>> However during all this time, we have still not managed to get
> >>> ourselves known to a wider audience and to get a significant =
amount
> of
> >>> public attention, most certainly due to the fact that have not
> managed
> >>> to work on publicity as much as on code. Also our community
> currently
> >>> consists of only 3 active committers that are regularly
> contributing
> >>> to the project.
> >>>
> >>> For this reason questions about the future of the project and
> whether
> >>> we will ever be able to graduate have been raised. While the
> remaining
> >>> active committers are determined to continue their project
> commitment
> >>> and to work towards graduation it is still unclear by which
> measures
> >>> new committers can be won to join the project.
> >>>
> >>> Hence, for the coming months answering this question and
> establishing
> >>> the corresponding measures should be our focus. One way of
> answering
> >>> this question could be to move this discussion to the dev list in
> >>> order to find out how our subscribers feel about the status of the
> >>> project. Also it might make sense to combine the user and dev =
lists
> in
> >>> order to prevent subscribers from missing information and getting
> them
> >>> more involved in the project.
> >>>
> >>
> >
> >