|Summary:||Obtain dependencies from Maven Central where possible|
|Product:||Tomcat 9||Reporter:||Mark Thomas <markt>|
|Component:||Packaging||Assignee:||Tomcat Developers Mailing List <dev>|
Description Mark Thomas 2018-06-25 15:21:03 UTC
Talking with michaelo at the ApacheCon EU Roadshow, he mentioned that the way Tomcat pulls dependencies from multiple locations makes it harder to build from source when located behind a strict firewall. He suggested obtaining references from Maven Central where possible as most orgs have a mechanism for proxying / caching Maven Central. Not all dependencies are available from Maven Central (e.g. NSIS is not) but any progress we can make on this would be helpful.
Comment 1 Mark Thomas 2018-06-25 15:21:53 UTC
Whoops. Should have created this as an enhancement request.
Comment 2 Remy Maucherat 2018-06-25 15:34:01 UTC
So you simply base all downloads (except one) on https://repo.maven.apache.org/maven2/ ? Why not.
Comment 3 Emmanuel Bourg 2018-06-25 15:37:46 UTC
What about using the Maven Ant Tasks? https://maven.apache.org/resolver-ant-tasks/
Comment 4 Mark Thomas 2018-06-25 15:46:35 UTC
(In reply to Emmanuel Bourg from comment #3) > What about using the Maven Ant Tasks? I'm on the fence. For: It would handle dependencies of dependencies Against: It is another component that would have to be downloaded (manually?) first. At the moment, we obtain a number of dependencies from Maven Central. My plan was to see how many of the others could be easily switched and then see where we were.
Comment 5 Mark Thomas 2018-06-25 19:11:27 UTC
I've done the simple ones (there were three of them). There are now seven dependencies not obtained from Maven Central.
Comment 6 Michael Osipov 2018-06-25 19:44:22 UTC
Mark, thanks for raising! Let me add some stuff here what I'd like to see/expect: Easily swappable URL of Maven Central against an internal Nexus instance, providing credentials for it. At best, we'd use the Resolver Ant Tasks which I can finish and publish to Central. It requires an Über JAR (either lightweight/URLConnection or with HttpComponents Client) which I wouldn't commit along with the code, but would require it to be in Ant's classpath. The best about this, you can define classpath entries for test and compilation and the tasks do the rest for you. People could leverage their settings.xml. Using Ant's get task if fine for the first shot. This is what I do with those tasks at work to customize the vanilla Tomcat tarball from Central with some internal and external libraries. I'd be happy to test a patch.
Comment 7 Michael Osipov 2018-06-25 19:45:22 UTC
(In reply to Emmanuel Bourg from comment #3) > What about using the Maven Ant Tasks? > > https://maven.apache.org/resolver-ant-tasks/ Please don't call them Maven Ant Tasks, those have been deprecated by me long time ago. The Resolver Ant Tasks have nothing to do with them.
Comment 8 Emmanuel Bourg 2018-06-25 20:22:32 UTC
(In reply to Michael Osipov from comment #7) > Please don't call them Maven Ant Tasks, those have been deprecated by me > long time ago. The Resolver Ant Tasks have nothing to do with them. Well, the full name is "Maven Artifact Resolver Ant Tasks" but that's rather long and boring ;)