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
<[email protected]> 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.
