Bug 38306 - Change registration mechanism for in-VM taskdefs
Change registration mechanism for in-VM taskdefs
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Ant
3.x
All All
: P2 (vote)
: 3.x
Assigned To: Jesse Glick
issues@projects
: API, API_REVIEW_FAST
: 36778 (view as bug list)
Depends on: 38330
Blocks: 20211 35756 36702
  Show dependency treegraph
 
Reported: 2003-12-23 23:26 UTC by Jesse Glick
Modified: 2004-01-07 22:20 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
:


Attachments
Current patch (lightly edited to exclude irrelevant temporary changes, and also including a patch to autoupdate; #38330 patch not included) (49.83 KB, patch)
2003-12-26 18:17 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-12-23 23:26:22 UTC
The current system of registering in-VM taskdefs
has some problems. Currently, any JAR in
ant/nblib/*.jar is checked for
META-INF/taskdefs.properties (or
typedefs.properties) which produce defs loaded in
a class loader based on o.n.c.m.SystemClassLoader
+ Ant.

1. JARs from disabled modules are loaded. (Issue
#36702)

2. The class loader for an in-VM taskdef JAR
includes too much. (Related to issue #35756)

3. The format is ad-hoc and does not match Ant
1.6's "antlib" convention.

4. There is no support for using XML namespaces
(in Ant 1.6) to scope names.

5. Scanning for JARs does not work well with
InstalledFileLocator. (Details in issue #36701)

Proposed change:

1. Each module may install exactly one such in-VM
def jar. It must be named ant/nblib/a-b-c.jar if
the module's code name base is a.b.c, but this
need not be located in the same installation dir
as the Ant module itself.

2. The task/type definition(s) must reside in
ant/nblib/a-b-c.jar!/a/b/c/antlib.xml.

3. When running under Ant 1.5.x, antlib.xml is
parsed only for simple <taskdef name="..."
classname="..."/> and <typedef name="..."
classname="..."/>. Any other elements or
attributes are ignored. (TBD: produce an error or
warning instead?) The parsing is done manually by
the Ant module.

4. When running under Ant 1.6.x, full antlib
syntax is permitted. The parsing is done by Ant's
proper methods.

5. The class loader for ant/nblib/bridge.jar
should be just Ant (i.e. the "main class loader"
used to load Ant itself) +
netbeans/modules/ant.jar (i.e. Ant module's
loader), in that order. (Could rename bridge.jar
to org-apache-tools-ant-module.jar, TBD.)

6. The class loader for ant/nblib/a-b-c.jar should
consist of just Ant + a.b.c's module loader, in
that order.

7. When running under Ant 1.5.x, or under 1.6.x
with a project whose root <project> element is in
the default namespace, the namespace URI used for
definitions is the default namespace. This should
provide compatibility for old non-namespace-aware
build scripts. Note that the project for which
this check is done is only the top-level project
selected by the user to run; any subprojects are
assumed to be similar.

8. When running under Ant 1.6.x with namespaces
enabled (as determined by <project> having the
namespace antlib:org.apache.tools.ant, which
should also be supported by the MIME resolver for
Ant scripts), the new definitions should be placed
in the expected namespace antlib:a.b.c, which the
script can refer to via namespace prefixes etc. as
usual. Besides providing support for scoping, this
means that an in-VM lib JAR which also provides
fallback impls that can work *without* NetBeans
classes has a chance of working without
modification using command-line Ant 1.6 - just
place it in the classpath.

The change is incompatible for modules installing
in-VM tasks; they will need to rename their def
JAR and change the def format to use antlib.xml.
However (a) only three modules are currently known
to be using this system, none of them in the
standard NB distro (apisupport/ant,
debuggerjpda/ant, and ant/browsetask); (b) the
current in-VM system was anyway introduced (as an
incompatible change) in the trunk after NB 3.5, to
support issue #20211, so it has never been in a
stable release.
Comment 1 Jesse Glick 2003-12-23 23:35:32 UTC
Branched:

cvs rtag -b -r BLD200312231900 ant_nblib_38306 ant debuggerjpda apisupport
Comment 2 Jesse Glick 2003-12-23 23:43:54 UTC
*** Issue 36778 has been marked as a duplicate of this issue. ***
Comment 3 Jesse Glick 2003-12-24 01:36:02 UTC
Might be necessary to modify #7 and #8 so that under Ant 1.5.x, the
defs are added to the project with no namespace qualification, but
under Ant 1.6.x they are added *both* with and without namespace
qualification. Reasons for the change:

1. There does not appear to be any way to ask a Project, once parsed,
whether it was using antlib:org.apache.tools.ant on <project> or not.
You could do this check separately using AntProjectCookie, though that
would be a bit of a performance hit in case the project would not
otherwise have been parsed.

2. It is probably pretty common to have a wrapper script which calls
the real implementation. The real implementation might be
namespace-qualified; who knows if the wrapper script is or not.

3. Not really intuitive that making a usually no-op change (adding the
namespace qualification to <project>) would affect these taskdefs.
Comment 4 Jesse Glick 2003-12-26 01:38:36 UTC
Branching also core and openide to support issue #38330 - same tag
name and base tag.
Comment 5 Jesse Glick 2003-12-26 04:00:26 UTC
Seems to be working OK. Code completion does not grok the namespaced
tags yet, but that is a separate issue (much lower priority).
Comment 6 Jesse Glick 2003-12-26 04:16:23 UTC
Specifically these things work:

1. Running w/ no namespaces under Ant 1.5.

2. Running w/ no namespaces under Ant 1.6.

3. Running w/ namespaces under Ant 1.6.

4. Error signaled under Ant 1.6 w/ namespaces if the task name is
wrong, or the namespace is wrong, or the namespace prefix is nonexistent.

5. Warning signaled under Ant 1.6 w/ namespaces by Ant module when
attempting to load custom defs with an unknown element in antlib.xml.

6. Error signaled under Ant 1.6 w/ namespaces by Ant itself when
antlib.xml contains an unknown element.

7. Under all 3 scenarios, if the module defining the task is disabled,
the build fails with a proper message from Ant that the task was not
defined.

8. From commandline, running namespaced build script with Ant 1.6 with
CLASSPATH containing openide.jar and
org-netbeans-modules-ant-browsetask.jar, the definition succeeds with
the implicit antlib and NbBrowse gets as far as a NPE
(URLDisplayer.default == null), i.e. as far as can be expected given
that it cannot run successfully outside the NB JVM.

Performance is still not great for Ant 1.6 - cca. 100msec per build to
load custom defs from three modules. Will add caching to try to
improve this. Under Ant 1.5, overhead is still negligible (1msec).
Comment 7 Jesse Glick 2003-12-26 17:54:30 UTC
Added caching of class loaders for ant/nblib/*.jar (easy), and removed
SPL comments from antlib.xml's to speed parsing. Seems to have reduced
overhead (under Ant 1.6) somewhat, to perhaps 40msec per build for
three provider modules (times are quite variable however). OptimizeIt
says that most of that overhead is parsing antlib.xml, and that most
of the parsing time is actually spent getting parser objects; this
should be unnecessary, so I filed

http://issues.apache.org/bugzilla/show_bug.cgi?id=25767
Comment 8 Jesse Glick 2003-12-26 18:17:00 UTC
Created attachment 12677 [details]
Current patch (lightly edited to exclude irrelevant temporary changes, and also including a patch to autoupdate; #38330 patch not included)
Comment 9 Jesse Glick 2003-12-26 20:20:03 UTC
Submitting for API review.

Incompatible, but only within the 3.6 dev cycle, and only for modules
using this part of the Ant module API - as far as I know, just three,
all experimental, all maintained by myself - and the changes required
to support the new registration mechanism are trivial (packaging only,
not code).

I have added an arch desc for the Ant module in the trunk, for your
reference. Should be visible in next daily Javadoc build. The trunk
arch desc reflects changes made in this issue in a couple of places.

Provisionally marking this section of the API as devel stability;
should be supported, but there is little data to tell if the API is
adequate for all users, since I seem to be the only one.
Comment 10 Jesse Glick 2004-01-06 16:33:45 UTC
Planned for commit to trunk during the day (US time) on Wednesday.
Comment 11 Jesse Glick 2004-01-07 22:20:15 UTC
committed 1.64 ant/manifest.mf
committed 1.7  ant/api/doc/changes/apichanges.xml
committed 1.4  ant/api/doc/org/apache/tools/ant/module/api/package.html
committed 1.7  ant/browsetask/build.xml
committed 1.4  ant/browsetask/manifest.mf
removed   1.2  ant/browsetask/src/META-INF/taskdefs.properties
committed 1.2 
ant/browsetask/src/org/netbeans/modules/ant/browsetask/antlib.xml
committed 1.7 
ant/src-bridge/org/apache/tools/ant/module/bridge/impl/BridgeImpl.java
committed 1.2 
ant/src-bridge/org/apache/tools/ant/module/bridge/impl/NbAntlib.java
committed 1.19
ant/src/org/apache/tools/ant/module/api/IntrospectedInfo.java
committed 1.8  ant/src/org/apache/tools/ant/module/bridge/AntBridge.java
committed 1.4 
ant/src/org/apache/tools/ant/module/bridge/AuxClassLoader.java
committed 1.3 
ant/src/org/apache/tools/ant/module/bridge/BridgeInterface.java
committed 1.3 
ant/src/org/apache/tools/ant/module/bridge/DummyBridgeImpl.java
committed 1.4 
ant/src/org/apache/tools/ant/module/resources/mime-resolver.xml
committed 1.19 apisupport/ant/build.xml
committed 1.13 apisupport/ant/manifest.mf
removed   1.2  apisupport/ant/src/META-INF/taskdefs.properties
committed 1.2 
apisupport/ant/src/org/netbeans/modules/apisupport/ant/antlib.xml
committed 1.26
autoupdate/src/org/netbeans/modules/autoupdate/SignVerifier.java
committed 1.6  debuggerjpda/ant/build.xml
committed 1.2  debuggerjpda/ant/manifest.mf
removed   1.2  debuggerjpda/ant/src/META-INF/taskdefs.properties
committed 1.2 
debuggerjpda/ant/src/org/netbeans/modules/debugger/jpda/ant/antlib.xml
committed 1.35 performance/threaddemo/build.xml


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo