Jody wrote: "Nice work! It is so much easier to proceed when there is someone who "owns" the code."
Peter sounds like he'll be able to answer questions, but I don't think he currently has the time to actively maintain the module. Maybe that is why work on the modile has tappered off. After looking at the code I think I have come up with a plan to move forward. Peter mentioned the XML parsing code in his module is likely outdated. I plan on replacing this with some updated code. I actually found some code by Paul Austing that provides reads GPX files to produce generic DataObjects, and writes DataObjects back out to GPX. I'm hoping that I can integrate this code. I'll convert the DataObjects to user-firendly representations of GPX entities. Then I'll tap into Peter's existing code so that the GPX entities are available trough the typical GeoTools DataStore. The advantage of this approach is that OpenJUMP and other programs can tap into the code "underneath" the GeoTools DataStore stuff. This will also give me a chance to introduce the DataObjects framework to GeoTools, which I think will be a good thing. Jody wrote: "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." I'm not planning on any changes to the core at this point, and will try to avoid this at all costs. Jody wrote: "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." It would be great if we could parse all the pom.xml files and produce a master list of dependencies by module. That might point out opportunities for library consolidation. Landon On Thu, May 15, 2008 at 12:49 AM, Jody Garnett <[EMAIL PROTECTED]> wrote: > 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
