Comments (15)
A potential fix:
Investigation (inserting debug statements in ArtifactAttacher) shows that's being called with null as the artifactType, when using the top level goal "files". The caller passing in null is in the FilesMojo, method getFilesToProcess, with the call
new ChecksumFile( (new File( fileSetDirectory ) ).getPath(), new File( fileSetDirectory, filePath ), null, null
A comparable call, when using the top level goal "artifacts" (which doesn't have this issue) uses the call:
new ChecksumFile( "", project.getArtifact().getFile(), project.getArtifact().getType(),null
A fix for this would be something that extracted the maven concept of "type" from the filePath. I did a hack of just getting the last segment of the filepath from the last '.' + 1 to the end. With that, it worked.
from checksum-maven-plugin.
closed by accident.
from checksum-maven-plugin.
I did a test: using "files" with an artifact which included a classifier: e.g. my-proj-2.10.3-SNAPSHOT-source-release.zip.
This fails because the creation of the ChecksumFile instance passes in "null" for the classifier. If I override that in the source code (e.g., look in the file path to see if has "source-release" and if so, pass that as the classifier, it succeeds in attaching the checksum properly.
I think a proper fix for this will need either:
-
a reliable maven-endorsed way to extract a "type" and a "classifier" from a filepath, (which might not be doable, in general), or
-
an augmentation of the configuration of this plugin which adds to the of the attributes for type and classifier, or
-
a combination of the two (use the specified type/classifier if supplied, otherwise attempt to deduce them from the filePath)
Is this something that can be fixed quickly? If not, since this is blocking our releases, we'll have to drop using this approach and go back to something like ANT scripts.
from checksum-maven-plugin.
It is the same as #62, I fixed it for the artifacts
goal but did not realize it also impacted files
and dependencies
.
I don't have time to work on this right away, so maybe you can try to use the artifacts
goal instead.
Anyway, I have to give it more thought, but as you pointed out attachArtifacts
is ambiguous for files
and dependencies
goals... So we might just remove it for these goals if we want to keep it simple.
from checksum-maven-plugin.
Just FYI: the "artifacts" goal also has an usual issue. It seems to pick up other artifacts, but misses the pom itself. I tried using the build-helper-maven-plugin to "attach" the pom but got an error indicating it was already "attached".
One thing I've noticed that's different about the pom: the source is not in the /target but is at the top level and is named "pom.xml". The attached artifact is never put into the target (normally), but does appear in the .m2 repo, where it's renamed -.pom (no xml, and using the standard maven naming conventions).
from checksum-maven-plugin.
The recently (August 18th) updated "apache-wide" super-pom ( https://search.maven.org/artifact/org.apache/apache/21/pom ) now uses this plugin, with the "files" option, attempting to add signatures for the source-release classifier artifacts.
from checksum-maven-plugin.
The maven-gpg-plugin also has a "sign all the artifacts" option. The code for this is in GpgSignAttachedMojo, and special-cases the pom separately from the other "attached" artifacts, and seems to have code for handling the case where the pom is not in the /target.
I did notice at one spot it has a wrong value due to the assumption that the pom for deploy has a name made from ${finalName} - that is I think not correct, I think it is forced to be ${artifactId}-${version}. This is, of course, the "default for finalName, but some users override this. For things going into /target, this is allowed, but for things going into .m2 repositories, the official maven naming convention is (I believe) "enforced". The line in the class (maybe) needing a fix would be this one:
File pomToSign = new File( project.getBuild().getDirectory(), project.getBuild().getFinalName() + ".pom" );
from checksum-maven-plugin.
clarification: I ran a test using a pom with a finalName which was just ${artifactId}. The maven-gpg-plugin created in /target a copy of the pom.xml file, with thename ${artifactId}.pom and signed it, creating in the /target a file ${artifactId}.pom.asc.
The maven install plugin seems to have the code to force maven naming conventions - it changed the name of this file in the .m2 spot to ${artifactId}-${version}.pom, and the signature likewise to ${artifactId}-${version}.pom.asc.
from checksum-maven-plugin.
If both this plugin and the maven-gpg-plugin are run (as would be typically done), they should account for the possibility that the other plugin may have already copied the pom.xml into the target.
from checksum-maven-plugin.
The "artifacts" goal adds sha512 to "attached" artifacts. Here's a surprise that goes against assumptions:
The code in ArtifactAttacher method artifactCreated accesses the artifactType. For an artifact produced by the "maven-source-plugin" using the goal "jar", the artifact produced has a file name:
${project.build.finalName}-sources.jar
You might think the "classifier" is sources and the "type" is "jar".
Correct for the classifier - it is "sources", but the artifactType is "java-source".
The result is the signature in /trunk is named ${project.build.finalName}-sources.jar.sha512
(just appending sha512 the the file name), but it is deployed as
${project.build.artifactId}-${project.build.version}-sources.java-source.sha512 . I think this should be
${project.build.artifactId}-${project.build.version}-sources.jar.sha512
In other words, don't use the artifact type if it doesn't match file-name after the classifier part '.'; use the part after the classifier '.' instead, as the type.
from checksum-maven-plugin.
Another plugin doing a similar thing of setting the artifact 'type' to other than the last part of the file name is the maven-javadoc-plugin. The type it uses is "javadoc"
from checksum-maven-plugin.
What seems to work is to have the ArtifactAttacher method artifactCreated call the attachArtifact with an attachementType that is made from the actual file name (which ends ....xxx.sha512) set to xxx.sha512. Example: for the artifact produced by the maven-javadocs plugin "jar" goal (name =
${finalName}-javadocs.jar), the checksum artifact is
${finalName}-javadocs.jar.sha512 (this is the name in the /target dir) and the deployed name would be
${finalName}-javadocs.jar.sha512 (the attachArtifact attachementType = jar.sha512, the artifactClassifier is javadocs).
Here's a code snippet, without enough checking, which worked for me:
public void artifactCreated(File artifact, String checksumType, String artifactType, String artifactClassifier) {
if (checksumType.startsWith(".")) {
// Project helper expects a type without leading dot (e.g. turn ".md5" into "md5").
checksumType = checksumType.substring(1);
}
String fileName = artifact.getName();
int period1 = fileName.lastIndexOf('.'); // finds xxx.yyy.sha512 period in front of sha512
int period2 = fileName.lastIndexOf('.', period1 - 1);
String attachmentType = fileName.substring(period2 + 1); // yyy.sha512
System.out.println("debug artifactType: " + ((artifactType == null) ? "null" : artifactType));
System.out.println("debug artifactClassifier: " + artifactClassifier);
System.out.println("debug checksumType: " + ((checksumType == null) ? "null" : checksumType));
System.out.println("debug derived attachmentType: " + attachmentType);
System.out.println("debug artifact: " + artifact.getAbsolutePath());
projectHelper.attachArtifact(project, attachmentType, artifactClassifier, artifact);
}
from checksum-maven-plugin.
here's a patch file fixing 2 items: 1) generating for the "artifacts" goal the proper names for artifacts where the artifact 'type' is different from the file-type, and 2) adding the "pom" to the list of things to generate checksums for, when using the artifacts goal.
checksum-maven-plugin-1.8-issue-64.txt
Sorry for the name ending in -64, it was supposed to be -63...)
I'm hoping this fix can be released soon - it's kind of blocking our progress.
from checksum-maven-plugin.
Can you submit your patch as a pull request ? This way we can have the tests run and discuss changes.
It looks like the patch contains several unnecessary changes, like commented out debug traces and modifications on license headers. Also, looking at your code snippet I doubt looking for two dots in a filename is a robust solution, and I believe a deeper refactoring is needed...
from checksum-maven-plugin.
@nicoulaj I provided a new PR for this issue at #87. Please have a look and let me know what you think.
from checksum-maven-plugin.
Related Issues (20)
- artifacts mojo: only generate checksum for specific (attached) artifacts HOT 2
- Migrate from plexus-utils to maven-shared-utils HOT 1
- Use Java 8 signature in animal-sniffer
- artifacts mojo: allow to exclude extensions
- Should have an option to enable check of dependencies for pom project HOT 5
- blake3 HOT 1
- ignore line endings in text files HOT 1
- Contents should include checksum and filename in standard format HOT 9
- Documentation site cannot be reached HOT 1
- Goal "check" searchs the summary file in wrong folder HOT 2
- Handle no files gracefully HOT 1
- "files" goal should have "appendFilename" option
- checksum-maven-plugin "artifacts" appends wrong filename
- cannot get a file containing checksums
- Documentation site cannot be resolved HOT 2
- Changelog
- 12:00:42 Could not find credentials βnexus3.onap.org:10001β for optf-fgps-maven-docker-stage-master #21 12:00:42 copy managed file [optf-fgps-settings] to file:/w/workspace/optf-fgps-maven-docker-stage-master@tmp/config950102380339591617tmp 12:00:42 [optf-fgps-maven-docker-stage-master] $ /bin/bash /tmp/jenkins6209735274096598136.sh 12:00:42 ---> docker-login.sh 12:00:42 nexus3.onap.org:10001 12:00:42 Build step 'Execute shell' marked build as failure HOT 1
- Generate checksum for pom.xml with goal "artifacts" HOT 2
- ITs should not check for SHA1/MD5 HOT 1
- NullPointerException running checksum:dependencies with test scope dependencies. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from checksum-maven-plugin.