On 9/8/05, Brett Porter <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
