incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: EMPIREDB-38, switch to slf4j
Date Mon, 24 Jan 2011 20:46:40 GMT
Hi Benjamin, 

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
> 
> Hi Francis,
> 
> 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.
> 
> What do you think would be best? Switch each module successively or all
> in one step?
> 
> Cheerio,
>      Benjamin
> 
> 
> 
> 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.
> >>>
> >>
> >
> >


Mime
View raw message