You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Ingo Schmidt <an...@der-ingo.de> on 2011/01/18 14:46:48 UTC
Problem with packaging WARs
Hi folks,
consider this very simple project with just two files in it:
/test/app-war/src/main/webapp/css/test.css
/test/app-war/src/main/webapp/test.html
Create a build file from directory structure for this and then execute
the following commands:
buildr package
echo "test" > /test/app-war/src/main/webapp/css/test.css
buildr package
The first command creates a WAR package with my files in it. So far, so
good.
The second command updates the test.css file.
The third command executes the package task again, but buildr did not
detect any changes! The WAR still contains the old file!
Is this a bug? If not, could someone explain to me why not?
Now if I make a change to the "test.html" file, then buildr will detect
the change - and also update my css file!
buildr also detects changes if I "touch" the webapp folder.
It seems to me that buildr works like this:
The WarTask has the webapp folder as prerequisite. If I change a file
inside the webapp folder, this updates the timestamp for the webapp
folder and the prerequisite is executed. However, if I change a file in
a subfolder, then the timestamp of webapp is of course not touched and
thus the task does not execute. Is this correct?
Anyhow, I would have expected buildr to pick up changes anywhere in the
webapp folder by itself. Any help on this would be greatly appreciated!
Cheers, Ingo =;->
Re: Problem with packaging WARs
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Sorry Ingo. Definitely worth filing a bug and we will follow up by adding a
test for it.
On Tue, Jan 18, 2011 at 08:48, Rhett Sutphin <rh...@detailedbalance.net>wrote:
> Hi,
>
> I can reproduce this problem, though I also don't see the WAR repackaged if
> I make changes to src/main/webapp/test.html. This is on OS X 10.6.6 with
> buildr 1.4.4 on MRI 1.8.7.
>
> $ ls -l target/
> total 8
> -rw-r--r-- 1 rsutphin wheel 637 Jan 18 10:17 buildr-1.0.0.war
>
> $ ls -l src/main/webapp/
> total 8
> drwxr-xr-x 3 rsutphin wheel 102 Jan 18 10:16 css/
> -rw-r--r-- 1 rsutphin wheel 11 Jan 18 10:29 test.html
>
> (Note that test.html was modified after the war was last built.)
>
> $ buildr package
> (in /private/tmp/buildr, development)
> Building buildr
> Packaging buildr
> Running integration tests...
> Completed in 0.005s
>
> $ ls -l target/
> total 8
> -rw-r--r-- 1 rsutphin wheel 637 Jan 18 10:17 buildr-1.0.0.war
>
> Despite buildr indicating that it's packaging, the war isn't changed.
>
> I have noticed intermittently that some the subproject dependencies in a
> complex build aren't rebuilt after a change (usually a resource change). I
> hadn't taken the time to isolate the problem (since a clean build of the
> affected subproject is a cheap workaround), but this might be the same
> problem.
>
> Rhett
>
>
> On Jan 18, 2011, at 10:04 AM, Ingo Schmidt wrote:
>
> > Hi Antoine,
> >
> > I hadn't included the buildfile, because I had included the steps how to
> create it (I let buildr create it). Anyway, here it is for convenience:
> > --------------- snip ---------------
> > # Generated by Buildr 1.4.3, change to your liking
> > # Version number for this release
> > VERSION_NUMBER = "1.0.0"
> > # Group identifier for your projects
> > GROUP = "buildr-test"
> > COPYRIGHT = ""
> >
> > # Specify Maven 2.0 remote repositories here, like this:
> > repositories.remote << "http://www.ibiblio.org/maven2/"
> >
> > desc "The Buildr-test project"
> > define "buildr-test" do
> >
> > project.version = VERSION_NUMBER
> > project.group = GROUP
> > manifest["Implementation-Vendor"] = COPYRIGHT
> >
> > define "app-war" do
> > package(:war)
> > end
> >
> > end
> > --------------- snap ---------------
> >
> >> since we use timestamps to control what changed, Buildr probably didn't
> do
> >> anything the second time you asked, as the modification occurred last
> than a
> >> second before.
> >
> > No, that is definitely NOT the case. I checked that. Trust me, I made
> quite some tests before I came here and asked.
> >
> > This was just an example so that it is easy for people to reproduce it.
> If you could create this tiny project and try for yourself?
> >
> > It happens on Windows and Linux, by the way.
> >
> >
> > Cheers, Ingo =;->
>
>
Re: Problem with packaging WARs
Posted by Ingo Schmidt <an...@der-ingo.de>.
Hi Alex,
thanks for creating the bug report. Looking forward to the bugfix. Your
workaround does the job.
Cheers, Ingo =;->
Am 18.01.2011 18:58, schrieb Alex Boisvert:
> Yes, definitely a bug. I created an issue:
> https://issues.apache.org/jira/browse/BUILDR-562
>
> <https://issues.apache.org/jira/browse/BUILDR-562>Looks like we currently
> add src/main/webapp as dependency but not every file under src/main/webapp.
>
> As a temporary workaround, you can write:
>
> package(:war).enhance FileList[_(:src, :main, :webapp, '**/*')]
>
> which will correctly add all files as dependencies.
>
> alex
>
>
> On Tue, Jan 18, 2011 at 8:48 AM, Rhett Sutphin<rh...@detailedbalance.net>wrote:
>
>> Hi,
>>
>> I can reproduce this problem, though I also don't see the WAR repackaged if
>> I make changes to src/main/webapp/test.html. This is on OS X 10.6.6 with
>> buildr 1.4.4 on MRI 1.8.7.
>>
>> $ ls -l target/
>> total 8
>> -rw-r--r-- 1 rsutphin wheel 637 Jan 18 10:17 buildr-1.0.0.war
>>
>> $ ls -l src/main/webapp/
>> total 8
>> drwxr-xr-x 3 rsutphin wheel 102 Jan 18 10:16 css/
>> -rw-r--r-- 1 rsutphin wheel 11 Jan 18 10:29 test.html
>>
>> (Note that test.html was modified after the war was last built.)
>>
>> $ buildr package
>> (in /private/tmp/buildr, development)
>> Building buildr
>> Packaging buildr
>> Running integration tests...
>> Completed in 0.005s
>>
>> $ ls -l target/
>> total 8
>> -rw-r--r-- 1 rsutphin wheel 637 Jan 18 10:17 buildr-1.0.0.war
>>
>> Despite buildr indicating that it's packaging, the war isn't changed.
>>
>> I have noticed intermittently that some the subproject dependencies in a
>> complex build aren't rebuilt after a change (usually a resource change). I
>> hadn't taken the time to isolate the problem (since a clean build of the
>> affected subproject is a cheap workaround), but this might be the same
>> problem.
>>
>> Rhett
>>
>>
>> On Jan 18, 2011, at 10:04 AM, Ingo Schmidt wrote:
>>
>>> Hi Antoine,
>>>
>>> I hadn't included the buildfile, because I had included the steps how to
>> create it (I let buildr create it). Anyway, here it is for convenience:
>>> --------------- snip ---------------
>>> # Generated by Buildr 1.4.3, change to your liking
>>> # Version number for this release
>>> VERSION_NUMBER = "1.0.0"
>>> # Group identifier for your projects
>>> GROUP = "buildr-test"
>>> COPYRIGHT = ""
>>>
>>> # Specify Maven 2.0 remote repositories here, like this:
>>> repositories.remote<< "http://www.ibiblio.org/maven2/"
>>>
>>> desc "The Buildr-test project"
>>> define "buildr-test" do
>>>
>>> project.version = VERSION_NUMBER
>>> project.group = GROUP
>>> manifest["Implementation-Vendor"] = COPYRIGHT
>>>
>>> define "app-war" do
>>> package(:war)
>>> end
>>>
>>> end
>>> --------------- snap ---------------
>>>
>>>> since we use timestamps to control what changed, Buildr probably didn't
>> do
>>>> anything the second time you asked, as the modification occurred last
>> than a
>>>> second before.
>>> No, that is definitely NOT the case. I checked that. Trust me, I made
>> quite some tests before I came here and asked.
>>> This was just an example so that it is easy for people to reproduce it.
>> If you could create this tiny project and try for yourself?
>>> It happens on Windows and Linux, by the way.
>>>
>>>
>>> Cheers, Ingo =;->
>>
Re: Problem with packaging WARs
Posted by Alex Boisvert <al...@gmail.com>.
Yes, definitely a bug. I created an issue:
https://issues.apache.org/jira/browse/BUILDR-562
<https://issues.apache.org/jira/browse/BUILDR-562>Looks like we currently
add src/main/webapp as dependency but not every file under src/main/webapp.
As a temporary workaround, you can write:
package(:war).enhance FileList[_(:src, :main, :webapp, '**/*')]
which will correctly add all files as dependencies.
alex
On Tue, Jan 18, 2011 at 8:48 AM, Rhett Sutphin <rh...@detailedbalance.net>wrote:
> Hi,
>
> I can reproduce this problem, though I also don't see the WAR repackaged if
> I make changes to src/main/webapp/test.html. This is on OS X 10.6.6 with
> buildr 1.4.4 on MRI 1.8.7.
>
> $ ls -l target/
> total 8
> -rw-r--r-- 1 rsutphin wheel 637 Jan 18 10:17 buildr-1.0.0.war
>
> $ ls -l src/main/webapp/
> total 8
> drwxr-xr-x 3 rsutphin wheel 102 Jan 18 10:16 css/
> -rw-r--r-- 1 rsutphin wheel 11 Jan 18 10:29 test.html
>
> (Note that test.html was modified after the war was last built.)
>
> $ buildr package
> (in /private/tmp/buildr, development)
> Building buildr
> Packaging buildr
> Running integration tests...
> Completed in 0.005s
>
> $ ls -l target/
> total 8
> -rw-r--r-- 1 rsutphin wheel 637 Jan 18 10:17 buildr-1.0.0.war
>
> Despite buildr indicating that it's packaging, the war isn't changed.
>
> I have noticed intermittently that some the subproject dependencies in a
> complex build aren't rebuilt after a change (usually a resource change). I
> hadn't taken the time to isolate the problem (since a clean build of the
> affected subproject is a cheap workaround), but this might be the same
> problem.
>
> Rhett
>
>
> On Jan 18, 2011, at 10:04 AM, Ingo Schmidt wrote:
>
> > Hi Antoine,
> >
> > I hadn't included the buildfile, because I had included the steps how to
> create it (I let buildr create it). Anyway, here it is for convenience:
> > --------------- snip ---------------
> > # Generated by Buildr 1.4.3, change to your liking
> > # Version number for this release
> > VERSION_NUMBER = "1.0.0"
> > # Group identifier for your projects
> > GROUP = "buildr-test"
> > COPYRIGHT = ""
> >
> > # Specify Maven 2.0 remote repositories here, like this:
> > repositories.remote << "http://www.ibiblio.org/maven2/"
> >
> > desc "The Buildr-test project"
> > define "buildr-test" do
> >
> > project.version = VERSION_NUMBER
> > project.group = GROUP
> > manifest["Implementation-Vendor"] = COPYRIGHT
> >
> > define "app-war" do
> > package(:war)
> > end
> >
> > end
> > --------------- snap ---------------
> >
> >> since we use timestamps to control what changed, Buildr probably didn't
> do
> >> anything the second time you asked, as the modification occurred last
> than a
> >> second before.
> >
> > No, that is definitely NOT the case. I checked that. Trust me, I made
> quite some tests before I came here and asked.
> >
> > This was just an example so that it is easy for people to reproduce it.
> If you could create this tiny project and try for yourself?
> >
> > It happens on Windows and Linux, by the way.
> >
> >
> > Cheers, Ingo =;->
>
>
Re: Problem with packaging WARs
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi,
I can reproduce this problem, though I also don't see the WAR repackaged if I make changes to src/main/webapp/test.html. This is on OS X 10.6.6 with buildr 1.4.4 on MRI 1.8.7.
$ ls -l target/
total 8
-rw-r--r-- 1 rsutphin wheel 637 Jan 18 10:17 buildr-1.0.0.war
$ ls -l src/main/webapp/
total 8
drwxr-xr-x 3 rsutphin wheel 102 Jan 18 10:16 css/
-rw-r--r-- 1 rsutphin wheel 11 Jan 18 10:29 test.html
(Note that test.html was modified after the war was last built.)
$ buildr package
(in /private/tmp/buildr, development)
Building buildr
Packaging buildr
Running integration tests...
Completed in 0.005s
$ ls -l target/
total 8
-rw-r--r-- 1 rsutphin wheel 637 Jan 18 10:17 buildr-1.0.0.war
Despite buildr indicating that it's packaging, the war isn't changed.
I have noticed intermittently that some the subproject dependencies in a complex build aren't rebuilt after a change (usually a resource change). I hadn't taken the time to isolate the problem (since a clean build of the affected subproject is a cheap workaround), but this might be the same problem.
Rhett
On Jan 18, 2011, at 10:04 AM, Ingo Schmidt wrote:
> Hi Antoine,
>
> I hadn't included the buildfile, because I had included the steps how to create it (I let buildr create it). Anyway, here it is for convenience:
> --------------- snip ---------------
> # Generated by Buildr 1.4.3, change to your liking
> # Version number for this release
> VERSION_NUMBER = "1.0.0"
> # Group identifier for your projects
> GROUP = "buildr-test"
> COPYRIGHT = ""
>
> # Specify Maven 2.0 remote repositories here, like this:
> repositories.remote << "http://www.ibiblio.org/maven2/"
>
> desc "The Buildr-test project"
> define "buildr-test" do
>
> project.version = VERSION_NUMBER
> project.group = GROUP
> manifest["Implementation-Vendor"] = COPYRIGHT
>
> define "app-war" do
> package(:war)
> end
>
> end
> --------------- snap ---------------
>
>> since we use timestamps to control what changed, Buildr probably didn't do
>> anything the second time you asked, as the modification occurred last than a
>> second before.
>
> No, that is definitely NOT the case. I checked that. Trust me, I made quite some tests before I came here and asked.
>
> This was just an example so that it is easy for people to reproduce it. If you could create this tiny project and try for yourself?
>
> It happens on Windows and Linux, by the way.
>
>
> Cheers, Ingo =;->
Re: Problem with packaging WARs
Posted by Ingo Schmidt <an...@der-ingo.de>.
Hi Antoine,
I hadn't included the buildfile, because I had included the steps how to
create it (I let buildr create it). Anyway, here it is for convenience:
--------------- snip ---------------
# Generated by Buildr 1.4.3, change to your liking
# Version number for this release
VERSION_NUMBER = "1.0.0"
# Group identifier for your projects
GROUP = "buildr-test"
COPYRIGHT = ""
# Specify Maven 2.0 remote repositories here, like this:
repositories.remote << "http://www.ibiblio.org/maven2/"
desc "The Buildr-test project"
define "buildr-test" do
project.version = VERSION_NUMBER
project.group = GROUP
manifest["Implementation-Vendor"] = COPYRIGHT
define "app-war" do
package(:war)
end
end
--------------- snap ---------------
> since we use timestamps to control what changed, Buildr probably didn't do
> anything the second time you asked, as the modification occurred last than a
> second before.
No, that is definitely NOT the case. I checked that. Trust me, I made
quite some tests before I came here and asked.
This was just an example so that it is easy for people to reproduce it.
If you could create this tiny project and try for yourself?
It happens on Windows and Linux, by the way.
Cheers, Ingo =;->
Re: Problem with packaging WARs
Posted by Antoine Toulme <an...@lunar-ocean.com>.
I haven't seen your Buildfile, so it's kind of a shot in the dark:
since we use timestamps to control what changed, Buildr probably didn't do
anything the second time you asked, as the modification occurred last than a
second before.
Maybe adding a sleep for 1s would help.
On Tue, Jan 18, 2011 at 05:46, Ingo Schmidt <an...@der-ingo.de> wrote:
> Hi folks,
>
> consider this very simple project with just two files in it:
> /test/app-war/src/main/webapp/css/test.css
> /test/app-war/src/main/webapp/test.html
>
> Create a build file from directory structure for this and then execute the
> following commands:
>
> buildr package
> echo "test" > /test/app-war/src/main/webapp/css/test.css
> buildr package
>
> The first command creates a WAR package with my files in it. So far, so
> good.
> The second command updates the test.css file.
> The third command executes the package task again, but buildr did not
> detect any changes! The WAR still contains the old file!
>
> Is this a bug? If not, could someone explain to me why not?
>
> Now if I make a change to the "test.html" file, then buildr will detect the
> change - and also update my css file!
> buildr also detects changes if I "touch" the webapp folder.
>
> It seems to me that buildr works like this:
> The WarTask has the webapp folder as prerequisite. If I change a file
> inside the webapp folder, this updates the timestamp for the webapp folder
> and the prerequisite is executed. However, if I change a file in a
> subfolder, then the timestamp of webapp is of course not touched and thus
> the task does not execute. Is this correct?
>
> Anyhow, I would have expected buildr to pick up changes anywhere in the
> webapp folder by itself. Any help on this would be greatly appreciated!
>
>
> Cheers, Ingo =;->
>