Are you sure? This sounds like a crazy assumption.

Java's jar tool has always placed the manifest first, and most if not all frameworks expect this. OSGi bundles and war files are both extensions of jar files. Was there a reason the WEB-INF was placed first? I know of no requirement for this by any standard, framework, or container, so it should do no harm reverting this change.

BTW the java.util.jar.JarInputStream and JarOutputStream classes also expect this.

I don't know why the change was made, but it's likely there was some reason. That said, if it's wrong, it needs to be fixed.

I noticed that this was not fixed in 1.8 RC1. Are there any plans to address this?

Please consider this bug from the oracle java bug database.

JDK-5046178 : JarInputStream doesn't return Manifest object

The bug is not going to be fixed, so gradles behavior WILL cause trouble. I was already hit by it.

Why do you think that this issue isn't going to be fixed? Also, the issue only seems to apply to indexed Jar files. Are you creating such an index yourself? Unless I'm missing something, Gradle has no built-in support for creating a Jar index.

I think he was just wondering, if it's going to be fixed.

But why do you think that this is just an issue with indexed jars? JarInputStream fails to read the manifest file from a war that was created with gradle. It doesn't matter if it is indexed or not. And who knows in which java tools or apps JarInputStream is used...

BTW: I hate it to argue for this issue. Why on earth is this fact not part of the jar spec? If it is a requirement for a jar that the manifest is the first file of a jar it should be in the spec.

But still, I think gradle should try to simulate the official jar tool as good as possible. And the jar tool enforces that the manifest file is the first file.

> But why do you think that this is just an issue with indexed jars?

I misinterpreted the issue description. Turns out that creating an indexed Jar is sufficient but not necessary for this problem to occur.

Yes, any war file created by Gradle 1.7 (and later at this point) will not produce jars consistent with the jar tool in the JDK. Did you ever discover why the change was made in 1.7? It was a very small change that is easily reverted, but with large consequences. If you are producing war files not consistent with the jar tool, it seems like there should be a good reason for it.

Attached is a patch that reverts a change made in Gradle 1.7. This patch will retain the order of the META-INF when generating war and ear files.

I forgot to mention, the patch is against 1.8-rc-1.

I'll need to submit another patch as an ear plugin test is failing. I'll do that a bit later today.

New patch. This patch updates one ear plugin integration test also. The patch reverts to Gradle 1.6 behavior.

I discovered why this change was made, and it is related to GRADLE-2171. The change was by Kyle Mahan (kyle.mahan@gmail.com). Files were placed first ahead of the META-INF in order to preserve precedence of "WEB-INF" and "lib" when duplicatesStrategy is set to "exclude". This bug is really a regression introduced by changes made for GRADLE-2171.

By reverting to Gradle 1.6, files added with the "into" closure will take precedence when resolving duplicate conflicts. I modified the EarPluginIntegrationTest to reflect this expectation.

Patch v3. I similarly altered the WarTaskIntegrationTest. I also added a check to EarPluginIntegrationTest and WarTaskIntegrationTest to ensure the manifest is placed as JarInputStream expects (first, or second after META-INF).

Patch v4. Added check for manifest placement to JarIntegrationTest.

FYI, these patches are obsolete, I generated a pull request on GitHub.

I tested 1.9-rc-2 in my environment and this appears to be fixed.