After examining the output more, I noticed that a lot of tests were run, but at the very end this warning was printed:
[WARNING] The requested profile "deps" could not be activated because it does not exist. On Tue, Feb 25, 2014 at 1:30 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Unfortunately I get the same result after running "mvn -P deps". > > I've tried it on both Ubuntu 12.04 and Mac OS X 10.8.3. Same results: > > ERROR [c.c.u.d.Merovingian2] (main:null) Unable to get a new db connection > java.sql.SQLException: No suitable driver found for > jdbc:mysql://localhost:3306/cloud?autoReconnect=true&prepStmtCacheSize=517&cachePrepStmts=true > > > On Tue, Feb 25, 2014 at 1:23 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> No, let me try that now. Thanks >> >> >> On Tue, Feb 25, 2014 at 1:22 PM, John Kinsella <j...@stratosec.co> wrote: >> >>> Did you re-run mvn -P deps? >>> >>> On Feb 25, 2014, at 12:16 PM, Mike Tutkowski < >>> mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> >>> wrote: >>> >>> I'm still getting the following error: >>> >>> ERROR [c.c.u.d.Merovingian2] (main:null) Unable to get a new db >>> connection >>> java.sql.SQLException: No suitable driver found for >>> >>> jdbc:mysql://localhost:3306/cloud?autoReconnect=true&prepStmtCacheSize=517&cachePrepStmts=true >>> >>> I built using "mvn -P developer,systemvm clean install" and ran the >>> management server using "mvn -pl client jetty:run". >>> >>> Any thoughts on that? >>> >>> Thanks >>> >>> >>> On Tue, Feb 25, 2014 at 1:10 PM, John Kinsella <j...@stratosec.co<mailto: >>> j...@stratosec.co>> wrote: >>> >>> Yep that works - thanks! Will close 6157. >>> >>> On Feb 25, 2014, at 3:33 AM, Hugo Trippaers <h...@trippaers.nl<mailto: >>> h...@trippaers.nl><mailto: >>> 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> >>> <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<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<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<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<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> >>> >>> >>> >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@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.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the >> cloud<http://solidfire.com/solution/overview/?video=play> >> *(tm)* >> > > > > -- > *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)* > -- *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)*
