|Thomas Scheffler||Jul 21, 2011 7:08 am|
|J Dalton||Jul 21, 2011 8:04 am|
|Olivier Jaquemet||Jul 21, 2011 8:23 am|
|Brenner, Mike||Jul 21, 2011 8:37 am|
|Paul Libbrecht||Jul 21, 2011 8:50 am|
|Bob Jacobsen||Jul 21, 2011 9:23 am|
|Alves, Licinio S CIV NUWC NWPT||Jul 21, 2011 2:06 pm|
|Rolf Lear||Jul 21, 2011 4:18 pm|
|Michael Kay||Jul 21, 2011 4:29 pm|
|Rolf Lear||Jul 21, 2011 4:55 pm|
|Noel Grandin||Jul 22, 2011 6:25 am|
|Rolf Lear||Jul 22, 2011 8:43 am|
|Jason Hunter||Jul 22, 2011 1:33 pm|
|Noel Grandin||Jul 25, 2011 12:57 am|
|Jason Hunter||Aug 7, 2011 6:32 pm|
|Brad Cox||Aug 8, 2011 4:10 am|
|jdom||Aug 8, 2011 5:52 am|
|Rolf||Aug 8, 2011 6:12 am|
|Rolf||Aug 8, 2011 7:12 am|
|Joe Bowbeer||Aug 8, 2011 9:22 am|
|Brad Cox||Aug 10, 2011 4:17 pm|
|Subject:||Re: [jdom-interest] jdom 2.0 with generics|
|Date:||Aug 8, 2011 7:12:30 am|
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...
On Mon, 8 Aug 2011 15:25:31 +0200, Paul Libbrecht <pa...@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.
Le 8 août 2011 à 14:52, jdom a écrit :
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.
_______________________________________________ To control your jdom-interest membership: http://www.jdom.org/mailman/options/jdom-interest/your...@yourhost.com