Spying on what Ant is doing

[Kohsuke Kawaguchi]

Jesse showed me the other day how he had injected code into a running
Ant process to figure out what's going on.

I've took that and implemented it in Ant plugin. This is still a proof
of concept, because I don't have time to get it fully done right now,
such as exposing it for other plugins.

The idea is that we can do the same kind of automatic integration that
we do with Maven. For example, today in the freestyle project, we ask
the user to tell us where the unit test reports go. But with this kind
of spying, we can find out from Ant that it has run unit tests, and
the output has been sent to a certain directory. Or imagine an Android
build, where we can automatically figure out where the appliation was
produced.

[1] https://github.com/jenkinsci/ant-plugin/tree/interceptor

--
Kohsuke Kawaguchi

[Bruno P. Kinoshita]

Looks interesting Kohsuke, looking forward to the final result.

I'm working with Apache Nutch building from sources + some plugins. The project consist of Nutch (Ant + Ivy) and several plugins (all Ant + Ivy as well). Just tested the interceptor branch with this project and worked like a charm, here's the output: 

https://gist.github.com/3805338

This Nutch project is not being built with Jenkins yet, but I can already think about a couple of cool things to do with this interceptor in this project (like calling other plugins and giving me more information about each plugin).

Thanks and have a great JUC SF!

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com

>________________________________
> From: Kohsuke Kawaguchi <k...@kohsuke.org>
>To: jenkin...@googlegroups.com
>Cc: Jesse Glick <jgl...@cloudbees.com>
>Sent: Saturday, 29 September 2012 6:31 PM
>Subject: Spying on what Ant is doing

[Kohsuke Kawaguchi]

Thanks.

During JavaOne, I talked to the folks from Gradleware and found a
similar mechanism to inject Jenkins into a running Gradle process.
Maybe we can come up with an abstraction that capture common build spy
events (source code in this directory got compiled with these
libraries) across Ant/Maven/Gradle.

Still need to work further, obviously...

2012/9/29 Bruno P. Kinoshita <brunod...@yahoo.com.br>:

--
Kohsuke Kawaguchi

[Jesse Glick]

On 10/05/2012 09:16 PM, Kohsuke Kawaguchi wrote:
> an abstraction that capture common build spy events (source code in this directory got compiled with these libraries) across Ant/Maven/Gradle

By way of background, the code Kohsuke alluded to earlier was in NetBeans; the Ant runner reports build events through an SPI [1], and a plugin [2] can be told to listen
to events from a certain project’s build and watch for interesting tasks. In the case of an IDE, the primary focus is on source code, and there are SPIs (e.g. [3], [4])
which allow plugins to report information about projects—whether inferred as in this case, explicitly configured via IDE-specific means, or read from an existing standard
such as a Maven POM. The key is that the provision of this information (e.g. by a project type) and its consumption (e.g. by an editor) are decoupled, using API/SPI pairs
called “queries”.

In the Jenkins world, the analogous feature would be publishers (or other job attributes) which can obtain their configuration in several ways. Currently things like the
JUnit publisher are directly configured by the user. This is fine for freestyle projects, but is not very flexible:

1. In the case of a native Maven project, maven-plugin directly hardcodes a few core publishers—but not, say, code coverage or static analysis handled by other plugins,
even when the POM configures these mojos.

2. If you want to “sniff” build events to autoconfigure a project using a procedural build tool like Ant, you have to either make this a one-time wizard which does not
adapt to project refactorings; or live with the config.xml being repeatedly regenerated.

In other words, instead of an abstraction over build spies, what you may want is an abstraction over job configuration. Thus a plugin like JaCoCo would continue to define
a publisher that can be manually configured with the location of coverage results and other details, but can also be implicitly configured by a different plugin based on
arbitrary sources of information: POM parsing, spying on calls to the JaCoCo Ant task, or something else. There may also be kinds of information which would be consumed
by multiple plugins; for example, information about Java source roots, classpaths, and source levels would be of value to many plugins (definitely Sorcerer), and if
@Exported would be of value to external tools as well.

[1] http://bits.netbeans.org/dev/javadoc/org-apache-tools-ant-module/org/apache/tools/ant/module/spi/AntLogger.html
[2] http://wiki.netbeans.org/AutomaticProjects
[3] http://bits.netbeans.org/dev/javadoc/org-netbeans-api-java-classpath/org/netbeans/spi/java/classpath/ClassPathProvider.html
[4] http://bits.netbeans.org/dev/javadoc/org-netbeans-api-java/org/netbeans/spi/java/queries/SourceLevelQueryImplementation2.html