andretadeu commented on a change in pull request #4: [MJAR-254] Finish the fix
of MJAR-198.
URL: https://github.com/apache/maven-jar-plugin/pull/4#discussion_r248431986
##########
File path: src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java
##########
@@ -272,11 +275,25 @@ public void execute()
private boolean projectHasAlreadySetAnArtifact()
{
- final File artifact = getProject().getArtifact().getFile();
- if ( artifact != null )
+ if ( getProject().getArtifact().getFile() != null )
{
- final String defaultArtifactName = artifact.getName().replace(
".jar", "" );
- return artifact.isFile() && defaultArtifactName.equals( finalName
);
+ if ( getProject().getArtifact().getFile().isFile() )
+ {
+ try
+ {
+ JarFile existingJarFile = new JarFile(
getProject().getArtifact().getFile() );
+ Attributes existingJarFileAttr =
existingJarFile.getManifest().getMainAttributes();
Review comment:
OK, I got it. I guess were are wasting our time then. From this [PR #1 -
Fixes filename conflict when producing 2 jars without
classifier](https://github.com/apache/maven-jar-plugin/pull/1/files), the test
was already creating two artifacts with different names and the same
classifier. The correct behavior already happens and the first JAR is already
the one that is installed.
This test case is invalid and I can't do anything about it. As in
[https://issues.apache.org/jira/browse/MJAR-254], it is stated that:
> In summary, the build should fail if the actual JAR file would get
overridden, not if the classifier happens to be the same. That is, the conflict
is at the actual filesystem level.
but this is a behavior that should be invalid.
I am not sure what to do now.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
