Provide additional deps on importing an ant build file in to build.gradle


(Pavel Alexeev) #1

Hello.
I’ve try use SenchaCmd ANT tasks to build and develop project in similar way: https://twasink.net/2014/07/30/extjs-5-and-gradle-playing-together/

ant.importBuild('build.xml') { antTaskName ->
    "sencha_${antTaskName.replaceAll('-', '_')}".toString()
}

Mostly it works. I be able call sencha_build and sencha_page.

But when I call sencha_watch task I receive 2 similar warnings like:

мая 31, 2016 2:20:42 PM org.eclipse.jetty.webapp.StandardDescriptorProcessor visitListener
WARNING: Could not instantiate listener org.eclipse.jetty.servlet.listener.IntrospectorCleaner
java.lang.ClassNotFoundException: org.eclipse.jetty.servlet.listener.IntrospectorCleaner
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:429)
at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:382)
at org.eclipse.jetty.server.handler.ContextHandler.loadClass(ContextHandler.java:1514)
at org.eclipse.jetty.webapp.StandardDescriptorProcessor.visitListener(StandardDescriptorProcessor.java:1831)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.jetty.webapp.IterativeDescriptorProcessor.visit(IterativeDescriptorProcessor.java:85)
at org.eclipse.jetty.webapp.IterativeDescriptorProcessor.process(IterativeDescriptorProcessor.java:72)
at org.eclipse.jetty.webapp.MetaData.resolve(MetaData.java:336)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1236)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:706)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:480)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:229)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:229)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.server.Server.doStart(Server.java:277)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at com.sencha.command.filesystem.StartCommand$2.run(StartCommand.java:195)
at java.lang.Thread.run(Thread.java:745)

That’s classes present in Sencha/Cmd/5.1.1.39/lib/jetty-servlet-8.1.7.v20120910.jar artifact. And Sencha directly run by:
sencha app watch
works just fine.

Start digging I found Sencha has mangle classloader in ANT build (portal-ui/.sencha/app/build-impl.xml):

<target name="init-cmd" 
    depends="find-cmd-in-path,
             find-cmd-in-environment,
             find-cmd-in-shell">
<echo>Using Sencha Cmd from ${cmd.dir} for ${ant.file}</echo>

<!--
load the sencha.jar ant task definitions.

NOTE: the 'loaderref' attribute stores this task def's class loader
on the project by that name, so it will be sharable across sub-projects.
This fixes out-of-memory issues, as well as increases performance.

To supoprt this, it is recommended that any customizations that use
'ant' or 'antcall' tasks set 'inheritrefs=true' on those tasks, in order
to propagate the senchaloader reference to those subprojects.  

The sencha 'x-ant-call' task, which extends 'antcall' and defaults 
'inheritrefs' to true, may be used in place of antcall in 
build process customizations.
-->
<taskdef resource="com/sencha/ant/antlib.xml" 
         classpath="${cmd.dir}/sencha.jar"
         loaderref="senchaloader"/>

Debugging further I found hints like Ant imports & taskdefs - failed to create task or type junit and When importing an ant build file in to build.gradle, do I have to redefine the dependencies in Gradle's way?.
But it still does not help me, because for start Jetty used classloader from Thread.currentThread() instead of classloader used for com.sencha.command.filesystem.StartCommand (and it is able resolve that classes).

I does not need define any additional tasks, but could I provide additional dependencies to existing ANT tasks to run it fine from gradle? Should I do that from build.gradle or from ANT build.xml?


(Pavel Alexeev) #2

May be someone could just point me how to gradle import ant tasks and deal with their classloaders? Honestly I had been start debug it, but it seams new thread started or even new JVM forked… I be able debug gradle tasks, but does not find Ant task execution entry point yet. How I could find where in lifecycle how imported ant task invoked?