Hi Filip, I'm very happy to hear that from you and dom4j team.
dom4j is ( and would be ) my choice for xml parsing and navigation within my projects. I've try other apis, but never find something similar with a so easy and at the same time flexible api. Saying that, there are other considerantions that i should do for future developments and as i've explained in previous messages the point to be solved quickly are the mandatory depency with Jaxen ( runtime and compile-time ), and the modularity problems allowing to have a minimum core and other fetures as modules. With regards to Jaxen, in like it as dom4j and it's a great ( in my opinion the best xpath engine around) but unfortunately there're some use-case where i cannot use it ( I'm making an eclipse project and Jaxen is not approved by IP Team for use ) and this is * a great problem * for dom4j too, because there's the dependency between the two projects. My question now is about the roadmap for these features, Do you've a timeline for that features?? Is there any expected date for final version of dom4j-2.0.0. Andrea Il 17/08/2010 08:49, Filip Jirsák ha scritto: > Hello Andrea, > separation of swing code had been planned for version 2.0 as well as > introduction pluggable mechanisms for switching XPath implementation, > QName cache implementation and so on. You are right this should be > done more thoroughly. Your suggestion of modules is good, I think we > could do it that way. > > Filip Jirsák > > > > 2010/8/13 Andrea Zoppello<zoppe...@tiscali.it>: > >> Hi all, >> >> I'm looking at the code of dom4j 2.0.0 aplha because i'm interested in >> having a codebase >> compiling with JDK 1.6 and i've still noticed that the codebase has >> packaged related >> to >> >> - swing >> - xml pull parsing >> - relax bg schema integration >> >> Now maybe it's only my thougths but i'm thinking to know the community >> opinion on >> the chance opportunity to have a dom4j-core packages and separate >> packages to do the >> integrations. >> >> One of the main problem i continue to have with dom4j is in the compile >> time circular dependency >> with Jaxen and i'm thinking in a refactoring to remove that but would to >> know the community >> opinion about that. >> >> What i'm definitely thinking for dom4j in future is something like >> >> - a core packahge ) dom4j-core focused on DOM parsing and navigation >> capabilities >> - dom4j-jaxen package ( Realize the integration with Jaxen in pluggable >> way ) >> - dom4j-swing >> -dom4j-realxng >> -dom4j-xmlpull >> >> Such packaging structure could sound more modular, flexible and would >> solve circular dependencies... >> >> I would like to hear about community opinion about.... >> >> Thx >> Andrea >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> dom4j-user mailing list >> dom4j-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dom4j-user >> >> > ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ dom4j-user mailing list dom4j-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dom4j-user
