Hey John, Thanks for pointing that out.
I recently upgraded Mac OS X from 10.8.3 to 10.9.2 and I believe it messed up my MySQL install. Thanks again, Mike On Thu, Feb 27, 2014 at 2:10 PM, John Kinsella <[email protected]> wrote: > Mike - that's not a JDBC error. Can you connect to the db using the mysql > client and properties under utils/conf/db.properties or > utils/conf/db.properties.override? > > On Feb 27, 2014, at 11:59 AM, Mike Tutkowski <[email protected] > <mailto:[email protected]>> wrote: > > Actually - I get this same error in master, as well. > > Consistent at least. :) > > > On Thu, Feb 27, 2014 at 12:37 PM, Mike Tutkowski < > [email protected]<mailto:[email protected]>> wrote: > > Just an FYI that I've tried this process on both 4.3-forward and 4.3. > > mvn -P developer -pl developer -Ddeploydb fails in both cases with the > following error: > > SQL exception in trying initDB: > com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications > link failure > > The last packet sent successfully to the server was 0 milliseconds ago. > The driver has not received any packets from the server. > > > On Wed, Feb 26, 2014 at 11:06 PM, Mike Tutkowski < > [email protected]<mailto:[email protected]>> wrote: > > Hey John, > > I'm just getting around now to trying to rebuild my CS environment using > the new changes in 4.3-forward. > > When I run the following: > > mvn -P developer -pl developer -Ddeploydb > > I receive the following error: > > ============> Running query: drop database if exists `cloud` > > SQL exception in trying initDB: > com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications > link failure > > I ran mvn -P deps before deploying the DB just to be sure. > > To build the system in the first place, I ran the following after > fetching the latest: > > mvn -P developer,systemvm clean install > > Any thoughts on this? > > Thanks! > > > On Wed, Feb 26, 2014 at 8:22 PM, Mike Tutkowski < > [email protected]<mailto:[email protected]>> wrote: > > Great, John - thanks again! > > > On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella <[email protected]<mailto: > [email protected]>> wrote: > > I've cherry-picked these into 4.3-forward...will ask RM in a separate > email to pick them into 4.3. > > John > > On Feb 26, 2014, at 5:26 PM, Mike Tutkowski < > [email protected]<mailto:[email protected]><mailto: > [email protected]>> > wrote: > > Awesome! Thanks, John! > > > On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella <[email protected]<mailto: > [email protected]> > <mailto:[email protected]>> 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 < > [email protected]<mailto:[email protected]><mailto: > [email protected]> > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>> 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 <[email protected]<mailto: > [email protected]> > <mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]><mailto:[email protected]>>> > 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 <[email protected]<mailto: > [email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto:[email protected]>>> 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 <[email protected]<mailto: > [email protected]> > <mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]>>> > 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:[email protected]] On Behalf Of Hugo Trippaers > Sent: Tuesday, February 25, 2014 3:34 AM > To: <[email protected]<mailto:[email protected]><mailto: > [email protected] > <mailto:[email protected]>> > 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 < > [email protected]<mailto:[email protected]><mailto: > [email protected]><mailto: > [email protected]<mailto:[email protected]>>> 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 > <[email protected]<mailto:[email protected]><mailto:[email protected] > ><mailto:[email protected] > <mailto:[email protected]>> > 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 > <[email protected]<mailto:[email protected]><mailto:[email protected]><mailto: > [email protected]><mailto: > [email protected]<mailto:[email protected]>>> 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 > <[email protected]<mailto:[email protected]><mailto:[email protected] > ><mailto:[email protected] > <mailto:[email protected]>> > 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 > <[email protected]<mailto:[email protected]><mailto:[email protected] > ><mailto:[email protected] > <mailto:[email protected]>> > 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: [email protected]<mailto: > [email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]>> > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: [email protected]<mailto:[email protected] > ><mailto:[email protected] > <mailto:[email protected]> > 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: [email protected]<mailto:[email protected] > ><mailto:[email protected]> > 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: [email protected]<mailto:[email protected]> > 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: [email protected]<mailto:[email protected]> > 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: [email protected]<mailto:[email protected]> > 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: [email protected]<mailto:[email protected]> > 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: [email protected] o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
