You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2014/08/08 19:12:24 UTC
Eclipse JAR dependency
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Eclipse JAR dependency
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-08-11 16:36 GMT+04:00 Mark Thomas <ma...@apache.org>:
> On 10/08/2014 14:24, Konstantin Kolinko wrote:
>> 2014-08-08 21:12 GMT+04:00 Mark Thomas <ma...@apache.org>:
>
> <snip/>
>
>>> 3. We will not normally update Tomcat's dependency on JDT until the
>>> 'small' JAR is available in Maven Central.
>
> <snip/>
>
>> 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.
>
> Ah. That makes things more problematic, especially if they wait for the
> pom to be updated and start to fail before they start their update process.
>
> <snip/>
>
>> 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)
>
> It is going to be a while before we need to update this again.
4.4.1 (Luna SR1) is planned for end of September
https://projects.eclipse.org/projects/eclipse/releases/4.4.1/plan
> I suspect
> there will have to be a little bit of trial and error until we find the
> smoothest process. It would help if we knew who was currently uploading
> the JDT jar then we could ping them directly (unless they are already
> watching the dev list).
http://markmail.org/message/xyw3bv2flmbhsdt4
"ECJ 3.3.1 now in Maven Central for Tomcat Jasper 6.0.32" by Ian,
with a blog
http://ianbrandt.com/2011/10/10/ecj-3-7-1-published-to-maven-central/
http://markmail.org/message/ezd4aabn4j3cqje4
"Tomcat 7.0.34 and ecj 3.7.2/4.2.1" by Ralph
http://markmail.org/message/eup4mxfjvxl7c5mp
"ecj 4.2.2" by Ralph
The latter posts were on the users list.
I do not remember reading any followup letters for versions ("4.3.1",
"P20140317-1600", "4.4"). Maybe there are, but I missed them. So I do
not know whom to thank for those.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Eclipse JAR dependency
Posted by Mark Thomas <ma...@apache.org>.
On 10/08/2014 14:24, Konstantin Kolinko wrote:
> 2014-08-08 21:12 GMT+04:00 Mark Thomas <ma...@apache.org>:
<snip/>
>> 3. We will not normally update Tomcat's dependency on JDT until the
>> 'small' JAR is available in Maven Central.
<snip/>
> 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.
Ah. That makes things more problematic, especially if they wait for the
pom to be updated and start to fail before they start their update process.
<snip/>
> 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)
It is going to be a while before we need to update this again. I suspect
there will have to be a little bit of trial and error until we find the
smoothest process. It would help if we knew who was currently uploading
the JDT jar then we could ping them directly (unless they are already
watching the dev list).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Eclipse JAR dependency
Posted by Konstantin Kolinko <kn...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org