[Bug] What does the WAR plugin do to the Copy task?


(Thomas) #1

I have a very strange behaviour using the WAR plugin and the Copy task. Please see this dummy build: https://nofile.io/f/ecejzkYnTOY/abc.tar.gz

The build is very simple and contains just one Copy task (named “abc”). It should copy the files from “$buildDir/from” into “$buildDir/dest” which are also prepared in the package. As long was the WAR plugin is commented out (which it is not in the package) everything works as expected. But as soon as the WAR plugin is active the “from” directory seems to just replace the “dest” directory.

I consider this a bug but I can’t create a thread in the Bugs forum.

Please note:
The error just seems to happen as long as the .gradle directory doesn’t exist. Therefore it is easier to just use the abc.tar.gz every time you want to try it without reusing existing unpacked files.


(Thomas) #2

Does no one know what is happening here? Or at least where I can get further information?

Thanks a lot!

PS:
Bug does still exist in Gradle 4.7 RC 2


(Carlo Luib-Finetti) #3

It is unclear, what you are trying to do. Why do you not just declare task war and do special things which are not done by default within this task?

For a standard war structure layout do actually have do nothing but just invoke gradle war.


(Thomas) #4

Thanks for your reply but I don’t want to use the war task. I also don’t want to build a war by that task. The problem is that the Copy task doesn’t work correctly anymore as soon as the war plugin is added to the project.

Did you try my example? The abc task behaves differently as soon as the war plugin is loaded. From my perspective this is a bug. This example is reduced to the very minimum. The real build is much larger and much more complex but it boils down to the war plugin corrupting the Copy task.


(Carlo Luib-Finetti) #5

sorry, I’m out on this question.


(Thomas) #6

Can anybody provide help for this? It’s really a very annoying bug in Gradle.

PS:
Problem still exists in Gradle 4.8.


(Thomas) #7

Problem still exists in Gradle 4.9