cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <h...@trippaers.nl>
Subject Re: developers and mysql
Date Thu, 27 Feb 2014 07:35:31 GMT
Hey,

StaticStrategy is an optional component, so it should be perfectly OK to include it at compile
time in our source code. If i understand the apache rules correctly we can keep it in the
code base without problems as long as it is optional. We should however move it to a separate
project inside cloudstack source and build it using a separate profile (or the noredist).

Can Apache projects rely on components whose licensing affects the Apache product?
Apache projects cannot distribute any such components. However, if the component is only needed
for optional features, a project can provide the user with instructions on how to obtain and
install the non-included work. Optional means that the component is not required for standard
use of the product or for the product to achieve a desirable level of quality. The question
to ask yourself in this situation is:

	• "Will the majority of users want to use my product without adding the optional components?"

— source http://www.apache.org/legal/resolved.html


Cheers,

Hugo



On 27 feb. 2014, at 06:24, Alex Huang <Alex.Huang@citrix.com> wrote:

> Hi Damoder,
> 
> I don't think I follow.  There's clearly compile dependency on mysql in StaticStrategy.

> 
> To me, when I look at StaticStartegy, it makes sense to move that into separate project
in github and reference people to it if they want to use the specific setup outlined in the
DB HA wiki.  That to me would make it a runtime dependency only.
> 
> --Alex 
> 
>> -----Original Message-----
>> From: Damoder Reddy
>> Sent: Wednesday, February 26, 2014 9:20 PM
>> To: Alex Huang; dev@cloudstack.apache.org
>> Subject: RE: developers and mysql
>> 
>> Hi Alex,
>> 
>> 	The mysql dependency is on for only " StaticStrategy.java" as
>> mentioned by you. And this is not used anywhere in the code base as a
>> compile time dependency rather used as a run time dependency in
>> db.properties. this will be passed to mysql driver as part of mysql Database
>> URL construction.
>> 
>> This StaticStrategy.java will become mute if we move out of mysql driver as it
>> has only runtime dependency.
>> 
>> Thanks & Regards
>> Damodar/
>> 
>> -----Original Message-----
>> From: Alex Huang
>> Sent: Thursday, February 27, 2014 4:13 AM
>> To: dev@cloudstack.apache.org
>> Cc: Damoder Reddy
>> Subject: RE: developers and mysql
>> 
>> @Hugo
>> 
>> The mysql scripts is a legacy of we used to dump the mysql db to create the
>> create-schema sql but it is at worst still a runtime dependency.  We should fix
>> it but I don't think it's as high a priority as the compile time dependency that
>> has been introduced.
>> 
>> @Damoder,
>> 
>> Can you take a look at StaticStrategy.java?  This is the only file that requires
>> mysql but I couldn't find anywhere in the code that references this class.  I
>> then looked at the bug and wiki and it also doesn't mentioned that
>> dependency on mysql has been added.  It doesn't make sense for
>> CloudStack to include this automatically.  There are many ways to provide DB
>> HA and incorporate it into our code just limits the possibilities.  We can for
>> example document this as a way to do it in on the wiki for example but I just
>> don't see why we would use code to limit it.
>> 
>> Thanks.
>> 
>> --Alex
>> 
>>> -----Original Message-----
>>> From: Hugo Trippaers [mailto:trippie@gmail.com]
>>> Sent: Tuesday, February 25, 2014 2:02 PM
>>> To: dev@cloudstack.apache.org
>>> Cc: dev@cloudstack.apache.org
>>> Subject: Re: developers and mysql
>>> 
>>> 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> 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>
>>> 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>
>>>>>> 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>
>>> 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>> 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>> 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>> 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>> 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
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 


Mime
View raw message