The version of the dependency to ecj is wrong: <dependency> <groupId>org.eclipse.jdt.core.compiler</groupId> <artifactId>ecj</artifactId> <version>3.3.1</version> </dependency> There is no version 3.3.1. This should probably be 3.5.1: http://repo2.maven.org/maven2/org/eclipse/jdt/core/compiler/ecj/ This bug has been introduced on 22/09/10 *after* release 6.0.29. In fact I'm quite surprised that deployment to the Maven central repository is allowed with such a bad reference as the rules are now stronger (what is good)) Tomcat 7 seems to contain wrong references as well (reference to ecj 3.6 which doesn't exist either as far as I can see). This is particularly bad here as the improved embeddable possibilities should be one feature of Tomcat 7.
Those ECJ version numbers are correct. You can confirm the version being used by looking in build.properties.default in the root of the svn tag for any given version. The issue is that not all of the Eclipse versions make it into the Maven repos and the organisation of the repos changes from time to time. I went and did some digging to see which versions I could turn up and I found the same ones you did. I thought I had found other versions in the past but my recollection may be wrong. You'll need to load the JARs manually into your local repo.
No matter whether these versions exist somewhere or not, if you publish to the maven central repository, then it means that you want to allow your users to use Tomcat from there. If you depend on versions that are not available there, you just put your users into trouble (in fact from the logic, the central repo should forbid such an artifact). From http://maven.apache.org/guides/mini/guide-central-repository-upload.html "...we do strongly encourage making sure all your dependencies are included in Central. If you rely on sketchy repositories that have junk in them or disappear, it just creates havok for downstream users." Is there one (or a set of) Maven repository(ies) that can *safely* be used for Tomcat dependencies? The central repo was ok for 6.0.29 but it is not the case anymore for 6.0.30.
Background: Up to 6.0.29 the Tomcat build process went through a convoluted process to generate what was essentially ecj.jar from jdt.jar. This meant a 40MB+ download was required to create a 1MB jar. The advantage was that the Jar was a Tomcat jar and was uploaded as part of the upload process. 7.0.x and 6.0.30 onwards use ecj.jar directly to speed up the build process. Issue: As far as I can tell from Googling, the Eclipse jars have been uploaded manually by various third parties. I'll add looking at this to my todo list but there is no reason stopping you doing it yourself and since this is your itch I suspect you'll get this done faster than I will. I did see from looking at the comments in one of the poms [1] that the process appeared to have been automated although since it is just ecj.jar then it shouldn't be too hard to do manually. [1] http://repo2.maven.org/maven2/org/eclipse/jdt/core/compiler/ecj/3.5.1/ecj-3.5.1.pom
*** Bug 54464 has been marked as a duplicate of this bug. ***
The ecj 4.2.1 bundle has been uploaded to Maven Central by Ralph Schaer Details: http://markmail.org/message/cb4jfopm4hbtq6dz Many thanks to him.
*** Bug 56670 has been marked as a duplicate of this bug. ***
This came up at work today. From this Eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=283745 it doesn't look like the necessary jar is going to be routinely published to Maven central any time soon. I also discovered that the version number of the JAR is not 4.4.RC4 but 3.10.0.v20140604-1726. I suspect that should Eclipse ever upload these JARs to central there are going to be version issues with the existing JARs that the community has uploaded. Options considered to address this: a) continue as is and let consumers of tomcat-jasper deal with this b) drop the Maven releases c) delay the release to Maven central until the ecj JAR is available - delay likely to be 1-2 weeks after upload is requested - either release manager has to arrange for upload or wait for the community to do it (longer delay) d) get Eclipse to upload JARs to central as part of their release process e) upload the JAR under the Tomcat groupId f) add the p2 repository to the pom a) is far from ideal as this is causing pain for some users b) is not a serious option as Maven releases are used too widely c) will cause problems for projects (TomEE?) that work from the zips that are released to Maven as access to the latest releases will be delayed d) looks to be unlikely given how long the current bug requesting this has been open e) could result in class loading issues if a project has a dependency on an older ecj JAR that is in central unless we package rename f) this should work in theory but I couldn't get it to work and not all build tools that use Maven central can access p2 repositories Given all of the above, the best way forward appears to be a variation of e) using jarjar to repackage the JAR (org.apache.tomact.org.eclipse.jdt.*) and then upload that to central under Tomcat's group ID. I don't really like doing this but don't see a better way forward at this point.
I'd vote c), then e). If Eclipse delays its releases by a couple weeks, it shouldn't be the end of the world if Tomcat does the same thing, right ?
(In reply to Remy Maucherat from comment #8) > I'd vote c), then e). If Eclipse delays its releases by a couple weeks, it > shouldn't be the end of the world if Tomcat does the same thing, right ? The delay comes from a non-Eclipse person uploading something into the org.eclipse namespace. It has to go through some additional, manual checks. It isn't that often that we update the ECJ jar. It has happened more frequently recently because of Java 8 support. My main concern with c) at this point is that some of the JARs already uploaded have been uploaded using a different version number to the one listed in the JAR's manifest - that creates a dependency management mess that it is going to be hard to recover from. I don't want to make that worse. There are also fewer hoops to jump through for e) than c).
I have nothing against doing e), no problem.
(In reply to Mark Thomas from comment #7) I think e) is not possible, because Eclipse uses a different license. An additional idea: g) Remove that dependency. (At least mark it optional). First, Tomcat can be used with javac compiler from JDK. Second, if someone wants to re-bundle the ecj jar, I think they can depend on the "Binary distribution" bundle of Tomcat (the one that publishes zip and tar.gz) and unzip ecj.jar from within the lib/ directory there. > I also discovered that the version number of > the JAR is not 4.4.RC4 but 3.10.0.v20140604-1726. It is no wonder. Each component in Eclipse has its own version like that. The f) option sounds interesting. I do not know what it actually looks like. How it works? (Are there some examples, precedents?) In general, is it possible to teach Maven to download some known version of a dependency from some fixed known location (like our Ant script downloads from sourceforge.net and from eclipse.org)?
(In reply to Konstantin Kolinko from comment #11) > (In reply to Mark Thomas from comment #7) > > I think e) is not possible, because Eclipse uses a different license. The license looks OK as long as we only ship the package renamed binary. I don't think we'd be able to ship the source. Keep in mind we used to do some major re-packaging of Eclipse JARs and that wasn't an issue. > An additional idea: > > g) Remove that dependency. (At least mark it optional). > > First, Tomcat can be used with javac compiler from JDK. > > Second, if someone wants to re-bundle the ecj jar, > I think they can depend on the "Binary distribution" bundle of Tomcat > (the one that publishes zip and tar.gz) and unzip ecj.jar from within the > lib/ directory there. That is about the same level of pain that folks see at the moment (and what I'd like to avoid). > > I also discovered that the version number of > > the JAR is not 4.4.RC4 but 3.10.0.v20140604-1726. > > It is no wonder. Each component in Eclipse has its own version like that. > > > The f) option sounds interesting. > I do not know what it actually looks like. How it works? > (Are there some examples, precedents?) I experimented with the tycho plugin but couldn't get it to use the p2 repo. The issue remains with that option of buidl tools other than Maven that use maven central and can't talk to p2 repositories. > In general, is it possible to teach Maven to download some known version of > a dependency from some fixed known location (like our Ant script downloads > from sourceforge.net and from eclipse.org)? As far as my research shows, no.
Technical (bikeshed) question about e): 1. what version number are you going to use? a. 4.4 from the file name b. 3.something from the manifest c. 8.0.9 from Tomcat If it a. or b. I think that formally we need to do a vote to release that. If it is b. then files downloaded from Maven will have some different filename. If it is c. then there will be some versioning mess, with files such as ecj-8.0.9.jar being downloaded and used somewhere. I expect people to be able to upgrade their ecj.jar at any time, if there are problems. If we go c) as the easiest and established way then the file at Maven central probably will have to be named "tomcat-ecj-8.0.9.jar".
Can we use the Eclipse maven repository? https://repo.eclipse.org/content/repositories/eclipse-releases/ <dependency> <groupId>org.eclipse.jdt</groupId> <artifactId>org.eclipse.jdt.core</artifactId> <version>3.10.0.v20140604-1726</version> </dependency> version 3.10.0.v20140604-1726 from MANIFEST.MF == version 4.4 from jar name
The JAR in that repo is over twice the size of the JAR we currently use. Further there is only a partial overlap between the JARs so the larger file is not a superset of the smaller. I'm currently looking around the Eclipse Maven repo to see if the JAR we want is in there somewhere.
The JAR is also available in Maven Central as: http://search.maven.org/#artifactdetails|org.eclipse.tycho|org.eclipse.jdt.core|3.10.0.v20140604-1726|jar I'm wondering if a) this JAR would work as a replacement and b) how folks would feel about if being larger. I'm only thinking of referencing it in the Jasper POM, not using it in a normal Tomcat build.
Chatting this over with some folks that actively use embedded Tomcat at $work someone suggested using the JDK compiler instead. With this in mind, I am currently thinking about the following plan: a) switch the JDT dependency in Jasper to the 5.3MB JAR that is in Maven central b) make the JDT dependency optional This should mean embedded Tomcat uses the JDK compiler by default unless JDT is available. I want to test that this works the way I think it will before I make any changes.
*** Bug 56759 has been marked as a duplicate of this bug. ***
After exploring various options the approach to be taken for this JAR going forward has been documented here: https://wiki.apache.org/tomcat/JDTCoreBatchCompiler Note that this is a wiki and the details of the policy may evolve over time. However, one part won't change and that is: <quote> The POMs used when uploading a release to Maven Central will always include references to valid JARs that are known to already exist in Maven central. </quote> There may be consequences as a result of this but the policy aims to minimize them.