[m2] plugin as module, timestamp checking and jar install

[John Fallows <jo...@gmail.com>]

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] plugin as module, timestamp checking and jar install

[Brett Porter <br...@gmail.com>]

Hi John,

Sorry for the late reply.

On 9/8/05, John Fallows <jo...@gmail.com> wrote:
> Where is the default implementation class for the ArtifactInstaller
> interface?

DefaultArtifactInstaller (consult components.xml to find this) in
maven-artifact-manager.

> It may very well already be implemented as incremental,
> since it seems like the target JAR is actually being recreated on each
> build.

Presently it always copies, but it could be changed as you say.

> 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.

It recreates everything every time at present. It's not a heavy
operation, but the catalyst of all of them adds up.

> 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 pom.properties 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.

This seems like a reasonable approach, as long as the cost of first
reading the archive doesn't negate the benefit.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] plugin as module, timestamp checking and jar install

[John Fallows <jo...@gmail.com>]

On 9/8/05, Brett Porter <br...@gmail.com> 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
invalid.

>  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
plexus.

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
build.

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 pom.properties 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.

Thoughts?

Kind Regards,
John Fallows.

> On 9/8/05, John Fallows <jo...@gmail.com> 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:
> users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> > 
> > 
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] plugin as module, timestamp checking and jar install

[Brett Porter <br...@gmail.com>]

Hi John,

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.

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

Cheers,
Brett

On 9/8/05, John Fallows <jo...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>