I was not aware that jaxb was bundled with jdk6. Geotools is a java5 so that is what i use to build it. I only run with java6 in production.
Correct me if i am wrong but even with a dummy module for java 5 there is a still a dependency on jaxb from the core of the library. If we can move this dummy module out into a plugin then i would have no problem with it. Martin Desruisseaux wrote: > Justin Deoliveira a écrit : >> I am not sure adding a dependency on jaxb from a core module like >> metadata is such good idea. Others may feel differently about this but i >> would prefer that dependencies such as this are not added to the very >> core of the library unless its absolutely necessary. Is there any way >> you can achieve your goals in a separate module? > > My strategy is driven by the fact that JAXB 2.0 is builden in Java 6, so for > Java 6 users there is no new dependencies at all. For Java 5, we can erase > this > dependency totally. > > There is my strategy. Would it be acceptable? > > 1) Creates a dummy module that declares some JAXB annotations (only the > one we use) with @Retention(RetentionPolicy.SOURCE) policy. > > 2) When building with Java 5, add the above module in the dependencies > with <scope>provided</scope>. When building with Java 6, do not add > any dependency at all. > > The result is: > > * When building with Java 6, the build-in JAXB is used. > Absolutly no new dependency. > > * When building with Java 5, the effect of @Retention(RetentionPolicy.SOURCE) > is that annotations are totally discarted by the compiler. The result will > be as if we never wrote those annotations. Because the module has been > declared in Maven pom.xml with "provided" scope, it will not appears in the > JAR dependencies neither. So again the result is: absolutly no new > dependency. > > > So as you see, I can manage the build in such a way that there is really no > dependency added, at the cost of a dummy module for Java 5 only which is not > retained in the final dependencies. > > >> The upgrade to jaxb 2.0 will be a problem for the xsd module, which >> depends on metadata. I tried before and it led to problems. I would have >> to look into it again to see what exactly they are. > > But Java 6 is bundled with JAXB 2.0. Wouldn't be JAXB 1.3 a risk of conflict > for > Java 6 users? > > >> It also seems that we are adding another xml serialization technology to >> the mix... sigh. That brings us up to 5: >> >> * raw sax >> * raw dom >> * xdo >> * xsd >> * jaxb > > I must admit that I'm not familiar with all those technology, and I don't know > the pros and cons of each of them. My motivation was partially based on my > wish > to leverage technologies bundled in JDK when we can. Having JAXB annotation > would not force users to use JAXB, but they can if they wish. > > Martin > > ------------------------------------------------------------------------- > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4007,479f7dbd166553362379201! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
