Any interest in some simple additions (trivial pom.xml files) to build jdom with maven? <div><br></div><div>If so, I'll need a recipe for how to push changes via git. I use mercurial for everything else.</div><div><br>
</div><div>After years of tolerating W3C DOM, JDOM was like coming home again! Thanks for resurrecting this!<br><br><div class="gmail_quote">On Sun, Aug 7, 2011 at 9:32 PM, Jason Hunter <span dir="ltr"><<a href="mailto:jhunter@servlets.com">jhunter@servlets.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I thought I'd send a status update on JDOM 2.0...<br>
<br>
In the last couple weeks I've setup a GitHub repository for the work at <a href="https://github.com/hunterhacker/jdom" target="_blank">https://github.com/hunterhacker/jdom</a>. Â Rolf was able to import the CVS history fully into GitHub. Â If you're curious how, he wrote a wiki page in the project.<br>
<br>
The project has branches for 1.0, 1.1, and 1.1.1. Â The master branch is for 2.0 work, now underway.<br>
<br>
Here's a list of improvements we might make (feedback welcome):<br>
<a href="https://github.com/hunterhacker/jdom/wiki/JDOM-2.0" target="_blank">https://github.com/hunterhacker/jdom/wiki/JDOM-2.0</a><br>
<br>
A list of outstanding bugs and RFEs:<br>
<a href="https://github.com/hunterhacker/jdom/issues" target="_blank">https://github.com/hunterhacker/jdom/issues</a><br>
<br>
If you're new to GitHub one of the perks is you can "watch" the project to see what's happening. Â You can also fork the project, make changes, and send us a pull request to incorporate your change into the official tree. Â That's ideal for simple bug fixes or even major Java 5 feature adjustments where you might want to work in isolation for a while.<br>
<br>
You can follow the project on Twitter at:<br>
<a href="http://twitter.com/#!/jdomproject" target="_blank">http://twitter.com/#!/jdomproject</a><br>
<br>
And see all commits at:<br>
<a href="http://twitter.com/#!/jdomcommits" target="_blank">http://twitter.com/#!/jdomcommits</a><br>
<br>
We're looking for others who want to be heavily involved in the Java 5 work. Â Speak up if that's you.<br>
<br>
-jh-<br>
<br>
On Jul 22, 2011, at 1:33 PM, Jason Hunter wrote:<br>
<br>
> Rolf's been sending in good code for as long as I can remember. Â :)<br>
><br>
> The reason I've resisted jumping on generics was the backward compatibility problem. Â It's just something you can do without breaking old code, as Rolf's email explains in some good detail.<br>
><br>
> I do think it's causing JDOM to be seen in a negative light, so we should do something about it.<br>
><br>
> The alternative package approach is probably the best road forward. Â It's a bit uglier, but it makes explicit the breakage, and means you can use JDOM 1.1 and JDOM 2.0 classes in the same project without conflict (an issue that arises if a project uses both Library X and Library Y which both depend on JDOM and maybe not the same versions).<br>
><br>
> I suppose org.jdom2 is the best package. Â Suitable for a 2.0 release.<br>
><br>
> I don't have a lot of time to do coding but I'll be happy to coordinate. Â Rolf, why don't you send me the code and I'll put it in revision control. Â Some others have sent in versions as well. Â We can decide which one's best and work on a 2.0 release.<br>
><br>
> Maybe we should move the code to github while we're at it?<br>
><br>
> Send in thoughts...<br>
><br>
> -jh-<br>
><br>
> On Jul 21, 2011, at 4:56 PM, Rolf Lear wrote:<br>
><br>
>> As an overview of what I did:<br>
>><br>
>> README.Java5<br>
>> ============<br>
>><br>
>> Here are the more significant changes made for the Java5 proposed solution.<br>
>><br>
>> 1. Modified org.jdom.filter.Filter to be generic.<br>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>> This allows Filter Implementations to return specific Content types.<br>
>> In addition, instead of returning boolean, it instead must fulfill the contract to return the input content cast in to<br>
>> the same type as the Filter <T>. Returning a null value indicates the filter does not match.<br>
>><br>
>> public interface Filter <T extends Content> extends java.io.Serializable {<br>
>> Â Â public T filter(Content content);<br>
>> }<br>
>><br>
>> Here is the JDom1.1 interface:<br>
>> public interface Filter extends java.io.Serializable {<br>
>> Â Â public boolean matches(Object obj);<br>
>> }<br>
>><br>
>> Significant implications of this change include the change of the method name from 'matches' to 'filter'.<br>
>> This is somewhat mitigated by the 'AbstractFilter' method 'matches' which is simply:<br>
>> Â Â return filter(content) != null;<br>
>><br>
>> Another 'regression' is that the filter and matches method now require at least 'Content' instead of 'Object' data.<br>
>> A direct implication of this is that you can not have a Filter on Document Objects. I could not find any examples of<br>
>> this in the project, or my work environment. It seems to be somewhat 'safe'. This is especially true because Filters<br>
>> are primarily used as input to the Parent.getContent(Filter) method, which, since the content can never be Document,<br>
>> implies this change is probably benign. It does make some code redundant in class ContentFilter.<br>
>><br>
>> All classes that implement Filter have been modified to be sensible.<br>
>><br>
>> This is the change that makes the code:<br>
>> Â Â List<Element> kids = someelement.getChildren();<br>
>> possible.<br>
>><br>
>><br>
>> 2. Modified Parent to be generic.<br>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>><br>
>> This allows for the method:<br>
>> Â Â Parent<T> addContent(Content content)<br>
>> to be added to the Parent interface, and still return the right type...<br>
>><br>
>><br>
>> 2. Rewrote much of ContentList (again)<br>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>> Three motivators for this change:<br>
>> Â a) Generics - so much had to change to accomodate Generics, seems this was the core impact.<br>
>> Â b) Compliance - set() method on Collections are not supposed to impact Concurrent Modification,<br>
>> Â Â but JDom did. Changed this so that set() does not impact concurrent status.<br>
>> Â c) Performance - modified FilterList and FilterListIterator to work on an as-needed basis. Will<br>
>> Â Â cache known content, but will only filter data on an as-needed basis, or 'lazy' basis. Need to<br>
>> Â Â devise tests to measure performance impact, but things like element.getChildren.iterator() will be<br>
>> Â Â much faster.<br>
>><br>
>> Another motivator was conformance with existing concepts, specifically List.subList(int,int). The paradigm for<br>
>> SubList is that modifications to the base list would cause concurrent exception in subList. This seems to be<br>
>> appropriate for FilterLists too, but, too much code depends on essentially dynamic/concurrent modification<br>
>> to make the change. The old behaviour remains.... leading to potentially odd things in FilterList iterators.<br>
>><br>
>><br>
>> 3. Removed complexities in JDOMException<br>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>> In Java5 we have the initCause method embedded in to Throwable. We don't need to jump through hoops any more.<br>
>><br>
>><br>
>> 4. Removed TextBuffer class<br>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>> This was an attempt to be a better performing StringBuffer. With Java5's StringBuilder, we don't need to worry.<br>
>><br>
>><br>
>> 5. Created AttributeType Enum<br>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>> This makes new attributes easy to manage, and also eliminates a bunch of org.jdom.test.* stuff.<br>
>> This also has probably the largest impact on existing code because of the requriement to change things like<br>
>> Â Â Attribute att = new Attribute ("name", "somevalue", Attribute.ID_TYPE);<br>
>> to<br>
>> Â Â Attribute att = new Attribute ("name", "somevalue", AttributeType.ID_TYPE);<br>
>><br>
>> On the other hand, it is all now TypeSafe ;-)<br>
>><br>
>><br>
>> 6. Created Annotation CVS_ID<br>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
>> This is used instead of the static field CVS_ID. This is set up to be an annotation to a class. Previously we had:<br>
>> Â Â Â public class Attribute implements Serializable, Cloneable {<br>
>> Â Â Â Â Â Â Â private static final String CVS_ID = "@(#) $RCSfile: Attribute.java,v $ $Revision: 1.56 $ $Date: 2007/11/10 05:28:58 $ $Name: Â $";<br>
>> Â Â Â Â Â Â Â ....<br>
>><br>
>> we now instead have:<br>
>> Â Â Â @CVS_ID("@(#) $RCSfile: Attribute.java,v $ $Revision: 1.56 $ $Date: 2007/11/10 05:28:58 $ $Name: Â $")<br>
>> Â Â Â public class Attribute implements Serializable, Cloneable {<br>
>><br>
>> The motivation for this is because Eclipse complains when there are unused private members... but, this is perfect<br>
>> fodder for annotations.<br>
>><br>
>> As a result, all org.jdom.* classes in the main repo have been modified to use the annotation rather than the static String.<br>
>><br>
>> As an excercies later, we will be able to programatically be able to determing all the CVS details at runtime using<br>
>> the annotations, and I have tested that<br>
>><br>
>><br>
>> 7. General Tidy-up.<br>
>> ^^^^^^^^^^^^^^^^^^^<br>
>><br>
>> Fixed all JavaDoc comments where applicable. Ensured @Override was specified where appropriate, etc.<br>
>> basically, I set strict rules in Eclipse, and then fixed all issues.<br>
>><br>
>><br>
>> 8. JavaDoc<br>
>> ^^^^^^^^^^<br>
>> All public and protected classes, methods, and fields have had their JavaDoc entries inspected and completed.<br>
>><br>
>><br>
>> 9. build.xml<br>
>> ^^^^^^^^^^^^<br>
>><br>
>> set Java compliance levels, JDom version number.<br>
>><br>
>> TESTS<br>
>> =====<br>
>> org.jdom.test.* has been modified to use and test the new code properly.<br>
>> Alltests was modified to include some suites that were not included.<br>
>> Alltests has been run, and all run tests have passed.<br>
>><br>
>><br>
>> CONTRIB<br>
>> =======<br>
>> All code has been modified to do what appears to be sane usage of the new JDom, but testing has not been done.<br>
>><br>
>> STILL TO DO<br>
>> ===========<br>
>><br>
>> FilterIterator seems clunky still. Especially the XXX warning.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 21/07/2011 7:19 PM, Rolf Lear wrote:<br>
>>><br>
>>> I did a JDOM conversion a while back. Made the code available to those who were interested.<br>
>>><br>
>>> There are a few 'gotchas', and most of the Generics implementation relies on 'hiding' explicit casting inside of the ContentList class.<br>
>>><br>
>>> It makes code that compiles against the JDOM cleaner, but does not actually improve any reliability...<br>
>>><br>
>>> Additionally, the XPath support is pretty much impossible to accomplish.<br>
>>><br>
>>> Let me dig up the code.... Or, rather, anyone interested should mail me directly.<br>
>>><br>
>>> Rolf<br>
>>><br>
>><br>
>> _______________________________________________<br>
>> To control your jdom-interest membership:<br>
>> <a href="http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com" target="_blank">http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com</a><br>
><br>
><br>
> _______________________________________________<br>
> To control your jdom-interest membership:<br>
> <a href="http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com" target="_blank">http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com</a><br>
<br>
<br>
_______________________________________________<br>
To control your jdom-interest membership:<br>
<a href="http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com" target="_blank">http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Cell: 703-594-1883<br>Blog: <a href="http://bradjcox.blogspot.com">http://bradjcox.blogspot.com</a><br>Web: <a href="http://virtualschool.edu">http://virtualschool.edu</a><br>
Manassas VA 20111<br><br>
</div>