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 Tue, 25 Feb 2014 20:59:03 GMT
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.tutkowski@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.tutkowski@solidfire.com> wrote:
>
>> No, let me try that now. Thanks
>>
>>
>> On Tue, Feb 25, 2014 at 1:22 PM, John Kinsella <jlk@stratosec.co> wrote:
>>
>>> Did you re-run mvn -P deps?
>>>
>>> On Feb 25, 2014, at 12:16 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com<mailto:mike.tutkowski@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 <jlk@stratosec.co<mailto:
>>> jlk@stratosec.co>> wrote:
>>>
>>> Yep that works - thanks! Will close 6157.
>>>
>>> On Feb 25, 2014, at 3:33 AM, Hugo Trippaers <hugo@trippaers.nl<mailto:
>>> hugo@trippaers.nl><mailto:
>>> hugo@trippaers.nl<mailto:hugo@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.Karuturi@citrix.com
>>> <mailto: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<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<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<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<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
>>>
>>>
>>>
>>>
>>>
>>> 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<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)*
>>
>
>
>
> --
> *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)*
>



-- 
*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