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.o...@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 <trip...@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 <da...@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.hu...@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:trip...@gmail.com] On Behalf Of Hugo Trippaers > > >>> Sent: Tuesday, February 25, 2014 3:34 AM > > >>> To: <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.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>> 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>> 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>> 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>> 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.o...@sungard.com > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
