Hello, Jody has essentially answered you already but I'll add my take which may flesh out the explanation.
The style specification evolved greatly from its earlier incarnation which involved a fairly extensive re-design of the system in place. During that work the author of the new style system decided to follow the lead of another developer who was starting a major cleanup effort of the whole library. So the work has been completed but cannot, in its current form, be committed back to trunk; it has, among other things, been written against Java 1.6 rather than Java5. I believe the author is also waiting for an extensive code review to feel the code is of library quality and ready for release. The cleanup work started for many reasons but three main ones were: obtaining a code base which could be built completely every night, raise the quality of the code to the standard needed for a library, and use the benefits of the Java 6 virtual machine and language constructs. For the former, the current version of geotools cannot be completely built and no one is quite sure why: for example, we need a different compiler to generate the javadocs from that used to generate the code. For the quality issue, this is something everyone is facing since the geotools library has been written over a long time. Other recent efforts have aimed to clean up other parts of the code base such as cleaning the access systems for data hosted in a database and more recently for the file based data access systems. Finally the language issue is one where the official project policy regarding language does not actually reflect the reality of what the project decided or what the contributors want. Our official policy dates from back in the Java 1.4 days---it was intended to express a desire to follow the newer Java platform releases but with enough delay to ensure that institutional clients would have the platform installed or at the very least be able to install it. The official policy we adopted was intended to formalize that balance but, since it relies on a numbering system Sun no longer follows, our policy no longer works. Formally, we are not even allowed to use Java 5 but that change was made by consensus for the Geotools 2.5 release. Since then, there has been no consensus to move on; the real policy is much more focused now on the JEE platform than it was when our formal policy was adopted. Anyhow, the developer launching the cleanup effort decided that since it would take a while to finish, he would start the rewrite on Java 6 and leverage the improvements of that platform. The style work followed and is now stuck in limbo. So the style work will not land for a while yet. The first phase of the cleanup work is almost ready but once that is announced there will be lots of work remaining before the styling code can land. The JAXB question is more complex, raising the existence of the religious war that so tiringly rages in our midst. There are the two factions in Geotools, the eclipse sect and the sun fanatics. Neither can tolerate the technology of the other and both are too lazy to really learn the strengths and limitations of the technology of the other. SLD parsing has been done both ways, with JAXB and by hand parsing. Both work, and both could probably co-exist but religious wars tend not to produce a good environment for co-existence. Finally, on the matching of geoapi and SLD, you may very well be right. I know as part of the work on the new styling, the Geoapi interfaces were modified. That may indeed have aligned them better with the new specification. Geoapi in general is improving over time as we understand it better, as the specifications evolve and improve, and as we need to maintain the project over time. As I understand things, the plan is indeed to move towards the GeoAPI approach. cheers, --adrian Francisco Moura wrote: > Srs., > > I´m working on a project that is being built on top of Geotools. > > One of our demands is some advanced styles, and so, I´ve been studing > the current 2.5.1 version implmentation and reading the upcoming > modifications. > > I saw that you are creating a new MarkFactory and some other great > stuff, and I have some questions: > > - When should this new style version be released? > > - Is there any issue for not using a library like JAXB for doing the SLD > parser and tranformer? > > - Are you going to make geotools style more like the geoapi style? > Because geoapi style seems to be closer to the SLD specification. > > Thanks in advance, > > Francisco Moura > Tecgraf - PUC-Rio > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
