2014-08-08 21:12 GMT+04:00 Mark Thomas <ma...@apache.org>: > All, > > I've been chatting on and off over the last few weeks with some folks at > $work that make extensive use of Tomcat embedded and for whom any issues > with the JAR references in the Maven POM (such as [1]) are a real pain. > > The root cause of the issue is that the small (~2MB) Eclipse compiler > (JDT) JAR we use is not officially released to Maven Central by Eclipse. > One or more volunteers upload the JAR and it typically appears 2-4 weeks > after the Eclipse release. > > There is a larger JAR (5.3MB) with contains the same functionality that > is officially uploaded by Eclipse. It usually appears in Maven Central > sooner that the smaller JAR. > > Having discussed the pros and cons of various options I would like to > propose the following approach to be used when updating our dependency > on JDT. > > 1. Tomcat releases will always package the 'small' JDT JAR as they do > today. > > 2. The POMs that we use when we upload a release to Maven Central will > always include references to valid JARs that are known to already > exist in Maven central. > > 3. We will not normally update Tomcat's dependency on JDT until the > 'small' JAR is available in Maven Central. > > 4. If we need to update the JDT dependency before the 'small' JAR is > available in Maven central (e.g. security issue, access new features > such as Java 9 support for testing etc.) then we will use the > following fallback options for the POM references: > - if the 'small' JDT JAR is not available, use the 'large' one > - if neither the 'small' nor the 'large' JDT JARs are available > continue to reference the pre-upadte version of the 'small' JDT > JAR > > 5. The changelog should make clear which dependencies have been updated > and which have not. > > 6. The tomcat-embedded-jasper.pom will continue to reference the > 'small' Eclipse JAR as a non-optional dependency by default. > > I'll add this to a wiki page so we can reference it in the > build.properties.default file etc. Obviously this is only a proposal at > this stage. Feedback, questions alternative approaches etc. welcome. > > Mark > > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=50604 >
https://wiki.apache.org/tomcat/JDTCoreBatchCompiler I am +1 for 1-2, 5 above, they are good. I am +1 for 4. and 6, but I do not have much knowledge/practice in those areas. I disagree (-0, not a stopper) with 3., as this procedure lacks explicit step that triggers upload of "small" jar. Currently the incentive for the upload is our having started to use the new version. There is no incentive other than that, as I think no other project besides us uses the jar. Essentially we have to announce that we want to update the dependency and wait for a volunteer to notice the announcement. I think that the incentive for the existence of "big" jar is that tycho provides access to use Eclipse Compiler with Maven. E.g. mentioned in [2][3]. [2] http://wiki.eclipse.org/Tycho/FAQ#Can_I_use_the_Tycho_compiler_support_in_non-OSGi_projects.2C_too.3F [3] http://eclipse.org/tycho/sitedocs/tycho-compiler-plugin/plugin-info.html Looking at "big" jar org.eclipse.jdt.core-3.10.0.v20140604-1726.jar I have several comments. 1). The "big" jar is identical to the one distributed with Eclipse IDE. It is a plugin, a jar placed into "plugins" directory. There is insignificant naming difference, as the file in Eclipse uses "_" to separate version from name, while Maven one uses "-". 2). The "small" jar is a separate product, "JDT Core Batch Compiler" (as downloadable from Eclipse download pages). It slightly differs in packaging: it provides Main class in its MANIFEST.MF and declares implementation of javax.tools.JavaCompiler service with a META-INF/services file. As we do not use javax.tools.JavaCompiler API (available since Java 6 [4][5]) and are using the classes directly, we are OK with using the "big" jar. 3). As the file names differ, the "org.eclipse.jdt.core" file is currently not covered by default value of jarsToSkip masks specified in catalina.properties. I think we have to add a mask for that file name. [4] http://docs.oracle.com/javase/7/docs/api/javax/tools/package-summary.html#package_description [5] http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html I think that the procedure is 1) update build.properties.default and IDE project files 2) post a heads-up notice on dev/users and wait a few days 3) update POM (using the fallback options) Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
