cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: developers and mysql
Date Thu, 27 Feb 2014 01:26:15 GMT
Awesome! Thanks, John!


On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella <jlk@stratosec.co> wrote:

> I've merged one of the commits, will get the other two in this evening
>
> On Feb 26, 2014, at 3:59 PM, Mike Tutkowski <mike.tutkowski@solidfire.com
> <mailto:mike.tutkowski@solidfire.com>> wrote:
>
> Yeah, if we have a 4.3 workaround for this, that would be great. Thanks
>
>
> On Wed, Feb 26, 2014 at 11:19 AM, Sonal Ojha <sonal.ojha@sungard.com
> <mailto:sonal.ojha@sungard.com>> wrote:
>
> I am seeing the issue on 4.3 branch, can someone help me how can that be
> made to work ??
>
>
> On Wed, Feb 26, 2014 at 3:32 AM, Hugo Trippaers <trippie@gmail.com<mailto:
> trippie@gmail.com>> wrote:
>
> We are already pretty much locked in as all our database scripts are
> MySQL
> specific. If we want to be neutral we should fix that.
>
> Cheers,
>
> Hugo
>
> Sent from my iPhone
>
> On 25 feb. 2014, at 22:57, David Nalley <david@gnsa.us<mailto:
> david@gnsa.us>> wrote:
>
> git blame showed that it came from the HA/replication work from
> Damoder.
> I didn't speak up at the time, but I am really reluctant for
> mysql-specific features to sneak in and lock us in.
>
> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang <Alex.Huang@citrix.com<mailto:
> Alex.Huang@citrix.com>>
> wrote:
> Who added the dependency on mysql for framework-db?  We actually
> worked
> hard to keep that depending on jdbc only.  It should not depend on mysql.
> We need to fix that.
>
> --Alex
>
> -----Original Message-----
> From: Trippie [mailto:trippie@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Tuesday, February 25, 2014 3:34 AM
> To: <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
> Subject: Re: developers and mysql
>
> 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.Karuturi@citrix.com<mailto:Rajani.Karuturi@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
> <trippie@gmail.com<mailto:trippie@gmail.com><mailto:trippie@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
> <david@gnsa.us<mailto:david@gnsa.us><mailto:david@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
> <jlk@stratosec.co<mailto:jlk@stratosec.co><mailto:jlk@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
> <hugo@trippaers.nl<mailto:hugo@trippaers.nl><mailto:hugo@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
>
>
>
>
>
>
>
>
> --
>
> Thanks and Regards,
>
> *Sonal Ojha* * Senior Engineer Product Development *  SunGard IT
> Availability
>
> Mobile +91-9922412645* E-Mail: sonal.ojha@sungard.com<mailto:
> sonal.ojha@sungard.com>
>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com>
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*
>
> Stratosec<http://stratosec.co/> - Compliance as a Service
> o: 415.315.9385
> @johnlkinsella<http://twitter.com/johnlkinsella>
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message