[jdom-interest] jdom 2.0 with generics

[Rolf]

Hi Paul.

Couple of things.... I've found that git's 'mv' tracking is somewhat
problematic, it's not as easy to track an item's history than before the
move.... you have to specify --follow for the 'git log' request.

Neither eclipse nor github appear to apply the --follow logic to the moved
files' history... It would be nicer if they did, since all the classes have
moved once already (jdom -> jdom2).

I acknowledge that the current system of dumping the supporting jars in
the repo is 'crude', but, it has some other advantages. Having everyone
using the same jar versions for the JDOM2 development would reduce the
number of 'head-scratching' problems. This is up for discussion, but it
seems that eliminating inconsistencies at this point in the development
would be useful.

Finally, I am in the habit of using ant and eclipse (call me 'old
fashioned'), and I have the habit of throwing in an 'eclipse' target for
ant build.xml files. I have added this target to the jdom build file.

Running 'ant eclipse' and refreshing your eclipse project (f5) will set
up/update your eclipse source folders, and library dependencies in a way
that makes it all 'just work'.

I normally have a 'smarter' eclipse target that uses the ant classpath to
set up eclipse, but, in this case, I have it hard-coded at the moment. I
see that it's missing the xml-apis.jar file, so it needs an update anyway.
I'll make it dynamic based on the ant compile classpath instead.

Obviously the demand for 'Mavenization' is growing... perhaps the most
important question is 'how important' is it? I have always worked in an
environment where build dependencies are more tightly controlled than what
maven would allow, and the dependency-loading nature of maven would be
'wrong'.

If you can make a convincing argument to 'Mavenize' then the actual commit
process would have to be very tightly coordinated, and it would interrupt
the actual JDOM2 coding as things stabilize. Further, it would also benefit
from having the comprehensive unit testing in order to confirm that nothing
has broken in 'the wash'.

As for a full Maven re-structure, I am hesitant... and I think Jason will
have to weigh in with the final word on that. It's more far-reaching than
just JDOM2...

Rolf

On Mon, 8 Aug 2011 15:25:31 +0200, Paul Libbrecht <paul at hoplahup.net>
wrote:
> I think Brad's offer was to do it.
> It does involve an amount of move around but it brings a few advantages
> for people to take things up.
> 
> Except for being able to transparently depend on jdom if it makes its
way
> into the maven repo (that's somewhat further), it allows to open in
Eclipse
> and IntelliJ IDEA directly, classpath and sourcepath all set.
> 
> Brad, have you tried using the IntelliJ IDEA or Eclipse git checkout
> methods (IntelliJ had me locate a Git executable which I had to
download,
> about 3 minutes)? If using this rearranging there will then nicely keep
> history the same way an svn mv would do.
> 
> paul
> 
> Le 8 août 2011 à 14:52, jdom a écrit :
> 
>> 
>> Hi Brad
>> 
>> In the short term it is unlikely that the JDOM repo will be converted
to
>> a
>> maven-style build. I simply do not use maven at all, and I do not know
>> the
>> maven 'paradigm'.
>> 
>> I know that the possibility is there to produe the maven co-ordinates
for
>> the JDOM releases, but it woul dmake sense to first get something
usable
>> out of JDOM2 before we go publishing it as a maven resource.
>> 
>> Bottom line is that, if it happens, it will be one of the last things
to
>> go through. Probably only after the alpha/beta/final stages of JDOM2
are
>> settled.
>> 
>> Still, JDOM is all about 'Java manipulation of XML made easy', so, it
>> should be considered, and I've updated the wiki page
>> https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 to reflect that
Maven
>> artifacts should be a possible goal of JDOM2.
>> 
>> Pleased to see the mounting excitement for JDOM2.
>> 
>> Rolf
>>