Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of trippie@gmail.com designates
 74.125.83.42 as permitted sender)
References: <CE326B99.262F5%chiradeep.vittal@citrix.com>
 <7245D3B6-0EC5-4D78-97D9-91C4CD919EFB@netapp.com>
 <9ADDE3F979256644BED8F0D244BE51F0061419@AMSPEX01CL02.citrite.net>
Mime-Version: 1.0 (1.0)
In-Reply-To: <9ADDE3F979256644BED8F0D244BE51F0061419@AMSPEX01CL02.citrite.net>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE26C649-46AD-43BC-BE4F-678CA989B194@gmail.com>
Cc: "SuichII, Christopher" <Chris.Suich@netapp.com>,
 "<dev@cloudstack.apache.org>" <dev@cloudstack.apache.org>,
 Alex Huang <Alex.Huang@citrix.com>
From: Hugo Trippaers <trippie@gmail.com>
Subject: Re: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
 deploying API Plugins
Date: Fri, 16 Aug 2013 11:46:24 +0200
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>

Heya,

An easier solution could be to explicitly start the scripts with /bin/sh. No=
 need to set executable bits anymore, this makes a lot of stuff easier when h=
andling scripts.

Cheers,

Hugo=20

Sent from my iPhone

On 16 aug. 2013, at 01:12, Donal Lafferty <donal.lafferty@citrix.com> wrote:=


> Hi Christopher,
>=20
> Could you take a quick look at the permissions on scripts in the ./client f=
older?
>=20
> I raised https://issues.apache.org/jira/browse/CLOUDSTACK-3650, because th=
e Maven project that launched Jetty does not set execution permissions for s=
cripts in  <webAppSourceDirectory>${project.build.directory}/${project.build=
.finalName}</webAppSourceDirectory>  E.g.=20
>=20
> root@mgmtserver:~/github/cshv3/client# ls -al ./target/cloud-client-ui-4.2=
.0-SNAPSHOT/WEB-INF/classes/scripts/vm/hypervisor/versions.sh
> -rw-r--r-- 1 root root 1636 Aug 14 15:42 ./target/cloud-client-ui-4.2.0-SN=
APSHOT/WEB-INF/classes/scripts/vm/hypervisor/versions.sh
>=20
> versus
>=20
> root@mgmtserver:~/github/cshv3/client# ls -al ./target/generated-webapp/WE=
B-INF/classes/scripts/vm/hypervisor/versions.sh
> -rwxr-xr-x 1 root 1636 Aug 14 15:42 ./target/generated-webapp/WEB-INF/clas=
ses/scripts/vm/hypervisor/versions.sh
>=20
>=20
> I'm confused as to how other systems were able to run scripts.  I can't ge=
t them to run to run on Debian 7.
>=20
> root@mgmtserver:~/github/cshv3/client# ./target/cloud-client-ui-4.2.0-SNAP=
SHOT/WEB-INF/classes/scripts/vm/hypervisor/versions.sh
> -bash: ./target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/=
hypervisor/versions.sh: Permission denied
>=20
> root@mgmtserver:~/github/cshv3/client# ./target/generated-webapp/WEB-INF/c=
lasses/scripts/vm/hypervisor/versions.sh
> Host.OS=3DUnknown Linux
> Host.OS.Version=3DX.Y
> Host.OS.Kernel.Version=3D3.2.0-4-amd64
>=20
>=20
> Are you using an O/S with permissions disabled?
>=20
>=20
> DL
>=20
>=20
>=20
>> -----Original Message-----
>> From: SuichII, Christopher [mailto:Chris.Suich@netapp.com]
>> Sent: 15 August 2013 20:13
>> To: <dev@cloudstack.apache.org>
>> Cc: Donal Lafferty; Alex Huang
>> Subject: Re: Changes to cloud-client-ui jetty webAppSourceDirectory and h=
ot
>> deploying API Plugins
>>=20
>> As I look in to this, it looks like the problem definitely comes from swi=
tching
>> Jetty from using the target/...4.3.0/ to target/generated-webapp/
>>=20
>> The maven-war-plugin creates all the war files in target/cloud-client-ui-=
4.3.0-
>> SNAPSHOT/ then copies *some* of it to target/generated-webapp/ from
>> client/ and then create the cloud-client-ui-4.3.0-SNAPSHOT.war.
>>=20
>> I'm not all that strong with maven, so despite some digging, I can't figu=
re out
>> why it creates and copies WEB-INF/classes/ from client/ but not WEB-INF/l=
ib/
>>=20
>> Still not sure why the mvn repo is used? Maybe it falls back to that to
>> populate the classpath?
>>=20
>> On Aug 15, 2013, at 2:28 PM, Chiradeep Vittal <Chiradeep.Vittal@citrix.co=
m>
>> wrote:
>>=20
>>> Seems related to https://issues.apache.org/jira/browse/CLOUDSTACK-
>> 3650
>>> Not sure about why the mvn repo is used. Have you tried clean install?
>>>=20
>>> On 8/15/13 11:05 AM, "SuichII, Christopher" <Chris.Suich@netapp.com>
>> wrote:
>>>=20
>>>> Some of you may remember a previous thread where I talked a bit about
>>>> this, so bear with me:
>>>>=20
>>>> We are working on an API plugin that we would like to be hot
>>>> deployable (not committed to source and can be deployed at any time).
>>>> In a previous discussion, I was told that this had not been tested
>>>> with CloudStack, but luckily it worked with no fancy tricks. This was
>>>> because I could drop our jar into
>>>> client/target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/lib and the jar
>> would automagically get picked up on the class path.
>>>>=20
>>>> This changed a couple days ago. It looks like with commit
>>>> 49c9fbfb70413f86642956423c4bbba2e43d8aec this was changed to use the
>>>> client/target/generated-webapp/ folder instead. The issue I'm running
>>>> in to is that this jetty deployment does not have a WEB-INF/lib
>>>> folder - it appears to use the dependencies straight from the local
>>>> maven repo instead.
>>>>=20
>>>> Can someone briefly explain the reasoning behind this change? I am
>>>> now unable to hot deploy our jar to a compiled build without editing
>>>> client/pom.xml to add an additional folder to the <extraClasspath> tag.=

>>>>=20
>>>> This raises another question I've been meaning to ask. How is the
>>>> jetty folder hierarchy structured when someone downloads a release
>>>> build of CloudStack? Is there a lib folder where jars like this could
>>>> be dropped, or is everything packaged into a single file?
>>>>=20
>>>> Thanks,
>>>> Chris
>=20