jdom at tuis.net
Sat Feb 18 19:08:54 PST 2012
I have done a scan of the contrib code, and grouped things in to 4 chunks:
1. code I think should be 'supported' - moved to 'core'
2. code I think should be 'considered'. 'Considered' code I think will
need a 'subject specialist' (not me) to do the 'official' migration.
3. code I think should be kept as 'sample' code only.
4. code which no longer has significant value... and should be abandoned.
The way I see it happening is that the contrib jar (and
org.jdom2.contrib) is going to disappear, with the code either moving to
org.jdom2, moving to 'sample', or being deleted entirely.
For the 'considered' code, there are things (like JavaBean mapping
systems) which are subject-specialized. If there is someone using that
code, or an 'expert' in the subject area, who is able to work on
bringing the code to adequate 'production-ready' status (generalized,
test code, etc.) then it can (likely) be moved in to core.
Code to 'move' to core
- Sort content in a ContentList - Issue #65 - I think this should be
re-structured as Element.sortContent(Comparator<? extends Content>).
(avoid problems with existing Collections.sort() where detach() is not
- AttAwareXMLOutputProcessor - Issue #66 - this code allows you to *not*
output Attributes if they match certain rules (like they are 'fixed' or
'defaulted' values from a DTD.
- TextHelper - Issue #67 - This has some 'convenience methods' for
getting Text content. Some of the methods already exist in some core
places (like Format.compact(), Format.trim(), etc.).
- XPathHelper - Issue #68 - provides ways to create XPath query strings
for existing content (think "the xpath to this Element is "/x/y/z/this")
- In-memory verifier - issue #11 - contrib version uses RelaxNG, but
this could be made more general.
Code to Consider (subject-specialized)
- org.jdom2.contrib.beans - JavaBean mapping code. This code has a
number of structures which are not 'general XML' type items, and this
code is not likely to be considered unless it is 'motivated' somehow.
- org.jdom2.contrib.dom - A 'lightweight read-only DOM wrapper for JDOM
content'. I added this code recently because I used it to 'interface'
with javax.xml.xpath and Xalan XPath libraries. It makes it possible to
use DOM-only libraries to access JDOM content. Being that this code is
new, currently has little 'testing', etc., it should be 'motivated' too.
If it is considered valuable enough, then I volunteer to get it
- org.jdom2.contrib.xpath Java/Xalan - test code used to validate XPath
API. May be worth building in to core. Already got test cases, etc. The
native Java version does not support String/Boolean/Double return
- org.jdom2.contrib.ids - tracking 'ID' values for Elements. Allows fast
lookup by ID. - has to be 'maintained' as the JDOM document is built.
- ResultSetBuilder - converts an SQL ResultSet to a JDOM/XML
implementation. I don't know if this is 'generalized' enough... there
are standard ways of doing this thing now... not sure if it is in JDOM's
- Input Scanner - filter Input SAX Events... this is mostly replaced by
functionality in the StAX API.
- JTreeOutputter - output of Element content to a Swing JTree. This
- Perf code - used as the benchmark for JDOM performance.
- nothing, it seems.
On 16/02/2012 11:43 PM, Rolf Lear wrote:
> Hi all.
> I want some input on the way that JDOM has previously shipped as both
> the 'core' and 'contrib' jars. It is my feeling that 'contrib' is a
> second-class citizen in the JDOM process... this is reinforced by the
> fact that I have paid it very little attention in the past 6 months and
> there are still functional elements in it which are new to me.
> I do not feel that I am in a position to 'support' the contrib code...
> if there are bugs, I am not familiar enough with the code to fix them, etc.
> If anyone has any ideas of how to deal with contrib I would appreciate
> hearing them.
> The options I see are:
> 1. keep the code as 'sample' code, but do not create a contrib jar (my
> preference, I think).
> 2. keep the code, build it, but document that the 'contrib' jar contains
> unsupported code.
> 3. move the 'valuable' contrib code in to core, 'support' that code, and
> 'kill' the code that is not valuable.
> I am interested in hearing people's ideas on this, and I am also
> interested in hearing from people who use the contrib jar, and what they
> use from that jar.
> To control your jdom-interest membership:
More information about the jdom-interest