We managed to fall off the list with your last reply ... Sunburned Surveyor wrote: > Jody, > > Thanks for answering all of my questions. Additional comments can be > found below: > > Jody wrote: "The user guide has instructions for using maven to "ask" > what the dependencies are for a given plug-in. Nobody uses all of > GeoTools; just the parts they need for the work they are doing ... as > an example: > - uDig uses some jars like gt-brewer and gt-validation; while > - geoserver experiments with things like gt-h2.jar" > > O.K. - That helps, but let me ask another question with an example. > The GPX schema defines an attribute of a waypoint that stores the time > a waypoint was collected. Let's say I'm considering the use of the > Joda library to represent time instances. It sounds like I make the > call on whether or not to use the library in my own module. I'm > guessing this could lead to a situation where different GeoTools > modules depended on the same library, or even different versions of > the same library. I'm just wondering if there was a policy to depend > on the same version of very common libraries that would be used by > more than one module. > Joda time is by all accounts great; Andrea suggested adopting Joda formally as a way to handle date representation in our Feature model (simply because all the Java implementations are terrible). I think Joda is headed for a JSR so hopefully we will get the best of both worlds.... one of the reasons we could not agree at the time was because a) it was another dependency and b) we were not clear if it was going to be a winner. It was easier to patch up our existing solution(s) then risk taking on a dependency when none of us felt confident that a clear winner had emerged yet.
Specifically to answer your question: The versions of the jars are declared in the root pom.xml; in your individual module (GPX) you would just say you depend on Joda. I am not sure if this is described in the developers guide yet; I am pretty sure that "how to add a third party library" could use a review by one of our Maven gurus. > Jody wrote: "The policy is we try and stay one "dot" release behind > Sun's latest and greatest; for the longest time we stayed at Java 1.4 > because the various Java EE applications that use GeoTools could not > upgrade until Java 5 EE came out." > > The policy is very clear. Thanks for providing the link. > I wonder if the page should be called "Java" just to get the point across :-) You did not find it at a glance after all... > The Sunburned Surveyor > > P.S. - I got in touch with the maintainer of the GPX module, and it > sounds like he is willing to help me work on the module. this is good > news. > Nice work! It is so much easier to proceed when there is someone who "owns" the code. The two of you can work away doing whatever it is you want, until such time as the module wants to be accepted into the library; that is the point where we would do a code review, check the test case coverage, and explore if Joda time is earning its keep, and if it was a solution other datastore modules would like to adopt etc... If you end up running into some limitation of the core library you will end making a "change proposal" to fix whatever API is giving you trouble. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
