Improve functionality of the classloader task when applied to the core loader #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Changes Main.runBuild to always provide an AntClassLoader as the core loader, so there will always be a loader to which additional path elements can be added. Also changes the behaviour of the classloader task when name is omitted or specified as "ant.coreLoader". In that case, the loader is not looked up by reference, but instead the core loader of the project is used. This avoids having to register a reference to this loader anywhere else. This patch was taken from PR #47003 and dates back to April 2009.
Instead of introducing an AntClassLoader in Main, we now have the Project class itself ensure that the core class loader is always an AntClassLoader. This should cater for the embedded mode, where Main isn't even used. We also use the factory method to make sure we get the right subclass of the class loader class. And there is some API documentation about all of this.
The documentation now specifies the version when the behavior changed. The private variable is adjusted to reflect the fact that we always want an AntClassLoader there. The public interface is left as is, though, to avoid trouble in case someone subclasses Project and overrides that method. Although I can't imagine why someone would do that.
|
Personally I'd prefer to have the discussion about this pull request in a single place - see https://issues.apache.org/bugzilla/show_bug.cgi?id=47003 |
lelou6666
pushed a commit
to lelou6666/ant
that referenced
this pull request
Mar 14, 2016
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@1572981 13f79535-47bb-0310-9956-ffa450edef68
Fuadsaja
approved these changes
Nov 20, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Revisiting issue 47003. The original title was “Add to ant lib classpath from within project file” which still describes what I'm trying to accomplish here.
With these changes, the core class loader is guaranteed to always be an
AntClassLoader, so the (still undocumented)<classloader>task can be used to add to that without replacing it. One use case is the following: users only have ant core available, but some dependency management tool (e.g. Ivy) provides jar files for optional tasks and their dependencies. Then adding those jars to the core class loader will make those optional tasks available without having to<taskdef>each one with the corresponding<classpath>. There is an antunit test case demonstrating this, using<junit>as an example. This approach can be used for third-party tasks as well, potentially simplifying things a lot. This should in particular help projects which up to now had a dedicated build script (or two, one shell script for *nix and one batch file for Windows) to build the class path resp. library path before invoking ant. Now they can drop those scripts and portably build the class path in ant itself.Of course it would be useful to also document the
<classloader>task, and give examples where modifying a non-core loader would be useful, and add antunit tests for that as well. But since I haven't yet figured out those non-core use cases, I'd like to keep that out of this pull request. And I'd welcome input on that.