Yep that works - thanks! Will close 6157.

On Feb 25, 2014, at 3:33 AM, Hugo Trippaers 
<h...@trippaers.nl<mailto:h...@trippaers.nl>> wrote:

Heya,

Just pushed a change that will make the database work again. :-)


@Alex. The mysql jar used to be pulled in as a dependency from framework-db. As 
the client target is responsible for building the war file for the packages 
including this in the client pom would also put it in the war file and in the 
packages.

I think i have an elegant solution, its now included as a dependency for both 
the database deploy and the jetty:run target. Which makes it effectively a 
“provided” library for the purpose of our maven build. See commit 
8e6b86ae23dce802044388c5420ff61511d7115b and 
e883877c7a6f9df04b572afd4ee5f10d265bcc3a.

I can deploy a database and start the jetty:run target now without any trouble 
(at least not more trouble than usual ;-) )

My next step is to clean up some of the dependencies. I think that only 
cloud-framework-db should have a provided dependency on mysql. It’s the only 
piece of source code that actually needs the mysql driver to be present during 
compilation for the optional HA configuration. There are some test classes that 
depend on database functionally but those should be moved to an integration 
test profile that could include the database driver, those tests are disabled 
anyway so they don’t cause any trouble now.


Cheers,

Hugo

On 25 feb. 2014, at 06:39, Rajani Karuturi 
<rajani.karut...@citrix.com<mailto:rajani.karut...@citrix.com>> wrote:

Can we move the mysql-connector-java dependency to the parent 
POM(SOURCE-ROOT/pom.xml) and define it different scopes for each profile?

ie)


<profile>
<id>developer</id>
  <dependencies>
      <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <scope>compile</scope>
      </dependency>
  </dependencies>
</profile>
<profile>
  <id>production</id>
  <dependencies>
      <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <scope>provided</scope>
      </dependency>
  </dependencies>
</profile>

Thanks,
~Rajani



On 24-Feb-2014, at 11:41 pm, Hugo Trippaers 
<trip...@gmail.com<mailto:trip...@gmail.com><mailto:trip...@gmail.com>> wrote:

Indeed,

I've been fighting with maven all day to get the development profile to include 
MySql. No luck yet, will give it another shot tomorrow :-)

Hugo

Sent from my iPhone

On 24 feb. 2014, at 18:21, David Nalley 
<da...@gnsa.us<mailto:da...@gnsa.us><mailto:da...@gnsa.us>> wrote:

So it should be ok to include the jar in non-default builds. developer
and deploydb are not what we'd expect a normal user to consume.
(Anyone else's head spinning?)

--David

On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella 
<j...@stratosec.co<mailto:j...@stratosec.co><mailto:j...@stratosec.co>> wrote:
I created CLOUDSTACK-6157 over the weekend to track this. Not sure adding the 
jar after compile will help the deploydb target, but will give it a try this 
morning.

Could we set up the pom.xmls to use the jar for execution if it's found in the 
user/system classpaths while respecting the legal requirements?

Rayees' suggestion for cloud.spec makes sense for the RPM builds, but doesn't 
affect the developer issues.

-He who needs more maven experience

On Feb 24, 2014, at 7:36 AM, Hugo Trippaers 
<h...@trippaers.nl<mailto:h...@trippaers.nl><mailto:h...@trippaers.nl>> wrote:

Heya,

as the mysql dependency is now set to provided in all the poms to fix our 
license compliancy the jetty target and the deployed targets are not working.

I'm trying to configure an optional profile to enable those targets to include 
the mysql dependency while executing, but so far no luck. If anyone has some 
bright ideas on how to do this i'm all ears. In the meantime the best solutions 
i've found to continue working is to copy the mysql jar file into the directory 
client/target/cloud-client-ui-4.4.0-SNAPSHOT/WEB-INF/lib/ by hand after running 
mvm install and before running the jetty target (just don't run mvn clean).

Hopefully a better solution in the near future.

Cheers,

Hugo





Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Reply via email to