Hey Frank, I reopened the ticket with the following comment:
I reverted this commit because it breaks the system for developers who use an operating system that has no cp or mkdir command (the mkdir was later added by Rohit) I did not notice the original issue because the executable bit is not an issue on windows systems. We should find an alternative way to do this to solve this problem in a way that works on all operating systems. It's mainly a developer problem as the permissions are set using the packaging scripts for deployments. A check if mkdir and cp exists before doing the copy should work i think, but maybe there is an ant task that will take care of the permissions on unix based systems. Or maybe explicitly call bash instead of depending to the os to execute the script. I don't have much time this weekend, but I'm willing to see if I can find a solution next week. Cheers, Hugo > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: zaterdag 2 maart 2013 20:01 > To: cloudstack-dev@incubator.apache.org > Cc: Hugo Trippaers (trip...@gmail.com) > Subject: Re: copying scripts in client/pom.xml > > On Fri, Mar 01, 2013 at 03:20:38PM -0800, Frank Zhang wrote: > > Hi Hugo: > > I noticed your recent change as below. It will cause bug > > https://issues.apache.org/jira/browse/CLOUDSTACK-1304 that I have > > fixed some days ago > > > > > > be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 271) > > <copy > todir="${basedir}/target/generated-webapp/WEB-INF/classes/scripts"> > > be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 272) > <fileset dir="${basedir}/../scripts" /> > > be141f6e (Hugo Trippaers 2013-03-01 08:22:40 +0100 273) > </copy> > > > > > > my fixes basically does: > > > > <exec executable="cp"> > > <arg value="-r" /> > > <arg value="${basedir}/../scripts" /> > > <arg value="${basedir}/target/generated-webapp/WEB- > INF/classes/scripts" /> > > </exec> > > > > Is there any special reason you changed it back? Thank > > you > > > > Frank / Hugo - Should we reopen CLOUDSTACK-1304? > > I'd also suggest that the description of the bug makes it a bit higher than > the > Major designation (i.e.: we should fix it in 4.1).
