maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Fallows <>
Subject Re: [m2] plugin as module, timestamp checking and jar install
Date Thu, 08 Sep 2005 02:16:38 GMT
On 9/8/05, Brett Porter <> wrote:
>  We were planning a more generic technique for this (letting Maven handle it
> by declaring your inputs and only executing mojos that had their inputs
> changed). This isn't scheduled for 2.0, however.

That doesn't seem to cover the case where the inputs are static but
the plugin itself is under development as a module and has changed
since the last invocation.

If none of the inputs have changed (static), and the plugin is not
executed, then the plugin would not get a chance to throw away
previously generated target files, even though they must be considered

>  If you have a solution to add to jar:jar and install:install then I'd be
> happy to apply it.

Where in the codebase should I be looking?  I found that the
maven-install-plugin uses an ArtifactInstaller, which is only an
interface so the actual implementation is most likely instantiated by

Where is the default implementation class for the ArtifactInstaller
interface?  It may very well already be implemented as incremental,
since it seems like the target JAR is actually being recreated on each

Looking at the maven-jar-plugin, it is using the MavenArchiver to
create the JAR in target before installation.

The MavenArchiver is eagerly creating some additional metadata files
derived from the POM, then the Plexus JAR archiver is called to
actually produce the archive.

How incremental is the Plexus JAR archiver?  Does it avoid updating
the JAR if the contents are not different or is it based solely on
timestamp?  I would expect the latter, which explains the eager JAR
creation due to the more recent timestamp on the per-build generated
POM-derived metadata.

Perhaps certain entries in the JAR archiver could be compared for
content as well as timestamp, even when the timestamp indicates that
they are more recent?  This mode could be enabled for the Manifest,
the and the exported pom.xml files, giving a no-op on
JAR creation when the output unchanged.  This would then enable the
ArtifactInstaller to behave truly incrementally, using a simple
timestamp check.


Kind Regards,
John Fallows.

> On 9/8/05, John Fallows <> wrote:
> > 
> > I'm developing a source generation plugin as a project module with the
> > following structure:
> > 
> > project/
> >   plugin/
> >   api/
> >   impl/
> > 
> > where the plugin is part of the reactor build process.  The plugin
> > builds first and is used by the api and impl builds.
> > 
> > As a good plugin developer citizen, I'd like to make sure the build is
> > incremental when appropriate, so timestamp checks are used to avoid
> > unnecessary regeneration of target files from source files during the 
> > api and impl builds.
> > 
> > In addition, this incremental behavior should be avoided when the
> > plugin itself has been updated because the previously generated api
> > and impl results are no longer guaranteed to be valid.  The 
> > plugin-up-to-date check can be verified using the timestamp of the
> > plugin dependency JAR itself.
> > 
> > Unfortunately, even when there is nothing to compile and no new
> > resources to package, the install goal still copies the plugin JAR to 
> > the local repository, updating the timestamp and defeating the
> > plugin-up-to-date check.
> > 
> > Would it be reasonable to make the install goal incremental as well?
> > For example, if nothing has changed and the local repository JAR has 
> > the same timestamp as the JAR sitting in project/plugin/target, then
> > no need to copy?
> > 
> > Kind Regards,
> > John Fallows.
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> > 
> > 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message