Re: Contrib

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 
called).
- 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 
production-ready

- 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 
values.... yet.

- org.jdom2.contrib.ids - tracking 'ID' values for Elements. Allows fast 
lookup by ID. - has to be 'maintained' as the JDOM document is built.

Sample Code
===========

- 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 
Domain.
- 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 
appears incomplete...
- Perf code - used as the benchmark for JDOM performance.


Dead Code
=========

- nothing, it seems.

Rolf



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.
>
> Thanks
>
> Rolf
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/[email protected]
>

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]