Maven 1.x Jar Plugin

jar:install copies jar even when no changes have occurred

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.6
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Linux/Windows
  • Number of attachments :
    0

Description

jar:install copies the built jar from the target area to the local repository even if the jar has no changes. This can cause a snowball effect on builds if you are using the reactor for instance. When testing a large project (before a release) it can be cumbersome since the build time is increased significantly.

As an example, I currently use the reactor to build 26 separate jars with all of them dependent on the base component. if I change one of them and then re-run the build it builds everything because the base jar is being copied back into the repository even if I don' change it. This causes the reactor to build all of the other jars and so-forth.

All that is needed is to change the jar:install copy line...remove the overwrite attribute and the builds speed up...It doesn't break anything either since you can alway runs a clean before a major build but when testing you can just keep running maven without the clean...you would be saving a lot of disk activity around the world by removing the overwrite attribute.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Carlos Sanchez added a comment -

I don't see much sense to do what you say in an install goal, as it's used when making releases, neither in an install-snapshot as usually you will clean first to ensure everything is correctly built

Show
Carlos Sanchez added a comment - I don't see much sense to do what you say in an install goal, as it's used when making releases, neither in an install-snapshot as usually you will clean first to ensure everything is correctly built
Hide
Permalink
Colin Saxton added a comment -

This is useful when you are writing large builds since you continually chop and change component maven/pom/src to make sure everything is working fine...in some cases you don't want to do a full install/build you just want to test your changes so it wouldn't make sense at that point to do a clean and then a build. That decision should really be in the hands of the developer.

I could understand if this was a complicated update but its just a simple deletion on one line.

Show
Colin Saxton added a comment - This is useful when you are writing large builds since you continually chop and change component maven/pom/src to make sure everything is working fine...in some cases you don't want to do a full install/build you just want to test your changes so it wouldn't make sense at that point to do a clean and then a build. That decision should really be in the hands of the developer. I could understand if this was a complicated update but its just a simple deletion on one line.
Hide
Permalink
Andy Wilde added a comment -

I came across this problem today when a developer was using multiproject:install to build a set of sub-projects. He assumed that jar:install would not overwrite the repository jar if there had been no changes. It seems to me that that wasn't an unreasonable assumption, and even if it wasn't the default behaviour it would at least be configurable.

Show
Andy Wilde added a comment - I came across this problem today when a developer was using multiproject:install to build a set of sub-projects. He assumed that jar:install would not overwrite the repository jar if there had been no changes. It seems to me that that wasn't an unreasonable assumption, and even if it wasn't the default behaviour it would at least be configurable.
Hide
Permalink
Marius Krabset added a comment -

How about comparing the md5sums in order to decide whether the jar already present in the local repository should be overwritten or not.

Eg. replace the jar:install-goal in the jar-plugin with something like this:
<goal name="jar:install" prereqs="jar:jar" description="Install the jar in the local repository">
<j:new var="md5" className="org.apache.maven.util.MD5Sum"/>

<util:file var="localArtifactFile" name="${maven.build.dir}/${maven.final.name}.jar"/>
<util:file var="repArtifactFile"
name="${maven.repo.local}/${pom.groupId}/jars/${pom.artifactId}-${pom.currentVersion}.jar" />
${md5.setFile(localArtifactFile)}
${md5.execute()}
<j:set var="localCheckSum" value="${md5.getChecksum()}"/>
${md5.setFile(repArtifactFile)}
${md5.execute()}
<j:set var="repCheckSum" value="${md5.getChecksum()}"/>
<j:if test="${!repCheckSum.equals(localCheckSum)}">
<artifact:install
artifact="${maven.build.dir}/${maven.final.name}.jar"
type="jar"
project="${pom}"
/>
</j:if>
</goal>

Since it's common to store md5sum-files in the local repository, the above goal could also be changed to:
1) Use md5sum-file if present
2) Generate and store md5sum-file if not present.
This could increase performance since reading an m5sum-file is a lot faster than calculating it.

Show
Marius Krabset added a comment - How about comparing the md5sums in order to decide whether the jar already present in the local repository should be overwritten or not. Eg. replace the jar:install-goal in the jar-plugin with something like this: <goal name="jar:install" prereqs="jar:jar" description="Install the jar in the local repository"> <j:new var="md5" className="org.apache.maven.util.MD5Sum"/> <util:file var="localArtifactFile" name="${maven.build.dir}/${maven.final.name}.jar"/> <util:file var="repArtifactFile" name="${maven.repo.local}/${pom.groupId}/jars/${pom.artifactId}-${pom.currentVersion}.jar" /> ${md5.setFile(localArtifactFile)} ${md5.execute()} <j:set var="localCheckSum" value="${md5.getChecksum()}"/> ${md5.setFile(repArtifactFile)} ${md5.execute()} <j:set var="repCheckSum" value="${md5.getChecksum()}"/> <j:if test="${!repCheckSum.equals(localCheckSum)}"> <artifact:install artifact="${maven.build.dir}/${maven.final.name}.jar" type="jar" project="${pom}" /> </j:if> </goal> Since it's common to store md5sum-files in the local repository, the above goal could also be changed to: 1) Use md5sum-file if present 2) Generate and store md5sum-file if not present. This could increase performance since reading an m5sum-file is a lot faster than calculating it.

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:

Time Tracking

Estimated:
2m
Original Estimate - 2 minutes
Remaining:
2m
Remaining Estimate - 2 minutes
Logged:
Not Specified
Time Spent - Not Specified
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.