RE: developers and mysql
-Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Wednesday, February 26, 2014 11:36 PM To: dev@cloudstack.apache.org Subject: Re: developers and mysql 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). I'm fine with that too. --Alex
Re: developers and mysql
Ok, I’ll fix it in the poms then. Cheers, Hugo On 27 feb. 2014, at 09:02, Alex Huang alex.hu...@citrix.com wrote: -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Wednesday, February 26, 2014 11:36 PM To: dev@cloudstack.apache.org Subject: Re: developers and mysql 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). I'm fine with that too. --Alex
RE: developers and mysql
Abhi, It's not licensing issue that troubles me. It's the fact that mysql's been made a compile dependency when it wasn't before. It encourages people to adopt more mysql functionality into the cloudstack code. Eventually that means we get more and more tied in with mysql once the trend has started. I would prefer the entire file is not in CloudStack as it really has nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion of this being put into pluginin enabled by noredist and mysql is only dependent upon in that plugin's pom.xml. --Alex -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, February 26, 2014 9:54 PM To: dev@cloudstack.apache.org; Damoder Reddy Subject: Re: developers and mysql Immediately if there are no specific licensing issues we should maintain the status-quo. The fact is that some other HA solutions will not work as all the schema related scripts are mysql engine specific. When we decide to move the mysql dependency out of cloudstack we should do it for all such dependencies. If there is an agreement here we can file a ticket to track this. -abhi On 27/02/14 11:16 am, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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:trip...@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 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
Re: developers and mysql
On 27 feb. 2014, at 09:09, Alex Huang alex.hu...@citrix.com wrote: Abhi, It's not licensing issue that troubles me. It's the fact that mysql's been made a compile dependency when it wasn't before. It encourages people to adopt more mysql functionality into the cloudstack code. Eventually that means we get more and more tied in with mysql once the trend has started. Agreed, that is a risk. We need to keep paying attention that new additions don’t introduce something we are not comfortable with. We maybe could make a jenkins check that will alert if the dependency list changes from a previous compile. Should be possible with a little creative scripting. I would prefer the entire file is not in CloudStack as it really has nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion of this being put into pluginin enabled by noredist and mysql is only dependent upon in that plugin's pom.xml. My reasoning here is that somebody took the time and effort to write something to either improve cloudstack or fix a problem. We should try to include this if we reasonably can, every contribution is valuable. That said i would be curious to know if anyone is relying on this at the moment. --Alex -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, February 26, 2014 9:54 PM To: dev@cloudstack.apache.org; Damoder Reddy Subject: Re: developers and mysql Immediately if there are no specific licensing issues we should maintain the status-quo. The fact is that some other HA solutions will not work as all the schema related scripts are mysql engine specific. When we decide to move the mysql dependency out of cloudstack we should do it for all such dependencies. If there is an agreement here we can file a ticket to track this. -abhi On 27/02/14 11:16 am, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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:trip...@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 da
Re: developers and mysql
Done commit a0f932437c9ac9a0a82cc9b45b1aa6f17e8a478a Author: Hugo Trippaers htrippa...@schubergphilis.com Date: Thu Feb 27 09:48:55 2014 +0100 Move mysql ha strategy to a plugin. Activate this plugin using the mysqlha profile or the noredist flag On 27 feb. 2014, at 09:25, Hugo Trippaers trip...@gmail.com wrote: On 27 feb. 2014, at 09:09, Alex Huang alex.hu...@citrix.com wrote: Abhi, It's not licensing issue that troubles me. It's the fact that mysql's been made a compile dependency when it wasn't before. It encourages people to adopt more mysql functionality into the cloudstack code. Eventually that means we get more and more tied in with mysql once the trend has started. Agreed, that is a risk. We need to keep paying attention that new additions don’t introduce something we are not comfortable with. We maybe could make a jenkins check that will alert if the dependency list changes from a previous compile. Should be possible with a little creative scripting. I would prefer the entire file is not in CloudStack as it really has nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion of this being put into pluginin enabled by noredist and mysql is only dependent upon in that plugin's pom.xml. My reasoning here is that somebody took the time and effort to write something to either improve cloudstack or fix a problem. We should try to include this if we reasonably can, every contribution is valuable. That said i would be curious to know if anyone is relying on this at the moment. --Alex -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, February 26, 2014 9:54 PM To: dev@cloudstack.apache.org; Damoder Reddy Subject: Re: developers and mysql Immediately if there are no specific licensing issues we should maintain the status-quo. The fact is that some other HA solutions will not work as all the schema related scripts are mysql engine specific. When we decide to move the mysql dependency out of cloudstack we should do it for all such dependencies. If there is an agreement here we can file a ticket to track this. -abhi On 27/02/14 11:16 am, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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:trip...@gmail.com] Sent: Tuesday, February 25
RE: developers and mysql
Does this all warrant a process sign off of upgrade testing? HA working in production and upgrading to felton with changes below? Thanks! Santhosh From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@trippaers.nl] Sent: Thursday, February 27, 2014 3:51 AM To: dev@cloudstack.apache.org Subject: Re: developers and mysql Done commit a0f932437c9ac9a0a82cc9b45b1aa6f17e8a478a Author: Hugo Trippaers htrippa...@schubergphilis.com Date: Thu Feb 27 09:48:55 2014 +0100 Move mysql ha strategy to a plugin. Activate this plugin using the mysqlha profile or the noredist flag On 27 feb. 2014, at 09:25, Hugo Trippaers trip...@gmail.com wrote: On 27 feb. 2014, at 09:09, Alex Huang alex.hu...@citrix.com wrote: Abhi, It's not licensing issue that troubles me. It's the fact that mysql's been made a compile dependency when it wasn't before. It encourages people to adopt more mysql functionality into the cloudstack code. Eventually that means we get more and more tied in with mysql once the trend has started. Agreed, that is a risk. We need to keep paying attention that new additions don’t introduce something we are not comfortable with. We maybe could make a jenkins check that will alert if the dependency list changes from a previous compile. Should be possible with a little creative scripting. I would prefer the entire file is not in CloudStack as it really has nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion of this being put into pluginin enabled by noredist and mysql is only dependent upon in that plugin's pom.xml. My reasoning here is that somebody took the time and effort to write something to either improve cloudstack or fix a problem. We should try to include this if we reasonably can, every contribution is valuable. That said i would be curious to know if anyone is relying on this at the moment. --Alex -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, February 26, 2014 9:54 PM To: dev@cloudstack.apache.org; Damoder Reddy Subject: Re: developers and mysql Immediately if there are no specific licensing issues we should maintain the status-quo. The fact is that some other HA solutions will not work as all the schema related scripts are mysql engine specific. When we decide to move the mysql dependency out of cloudstack we should do it for all such dependencies. If there is an agreement here we can file a ticket to track this. -abhi On 27/02/14 11:16 am, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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
RE: developers and mysql
I think We need to upload this new jar somewhere so that people who need DB HA can download from there. This is for non-developers (For Example Testers). Thanks Regards Damodar/ -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Thursday, February 27, 2014 2:22 PM To: dev@cloudstack.apache.org Subject: Re: developers and mysql Done commit a0f932437c9ac9a0a82cc9b45b1aa6f17e8a478a Author: Hugo Trippaers htrippa...@schubergphilis.com Date: Thu Feb 27 09:48:55 2014 +0100 Move mysql ha strategy to a plugin. Activate this plugin using the mysqlha profile or the noredist flag On 27 feb. 2014, at 09:25, Hugo Trippaers trip...@gmail.com wrote: On 27 feb. 2014, at 09:09, Alex Huang alex.hu...@citrix.com wrote: Abhi, It's not licensing issue that troubles me. It's the fact that mysql's been made a compile dependency when it wasn't before. It encourages people to adopt more mysql functionality into the cloudstack code. Eventually that means we get more and more tied in with mysql once the trend has started. Agreed, that is a risk. We need to keep paying attention that new additions don't introduce something we are not comfortable with. We maybe could make a jenkins check that will alert if the dependency list changes from a previous compile. Should be possible with a little creative scripting. I would prefer the entire file is not in CloudStack as it really has nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion of this being put into pluginin enabled by noredist and mysql is only dependent upon in that plugin's pom.xml. My reasoning here is that somebody took the time and effort to write something to either improve cloudstack or fix a problem. We should try to include this if we reasonably can, every contribution is valuable. That said i would be curious to know if anyone is relying on this at the moment. --Alex -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, February 26, 2014 9:54 PM To: dev@cloudstack.apache.org; Damoder Reddy Subject: Re: developers and mysql Immediately if there are no specific licensing issues we should maintain the status-quo. The fact is that some other HA solutions will not work as all the schema related scripts are mysql engine specific. When we decide to move the mysql dependency out of cloudstack we should do it for all such dependencies. If there is an agreement here we can file a ticket to track this. -abhi On 27/02/14 11:16 am, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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
RE: developers and mysql
1. We may wanted to document or\and release note the below for HA feature. However it might be worth mentioning that if the admin switched to the HA procedure he should either disable this before upgrading or make sure he uses the noredist build when upgrading. 2. Also, just a note, people testing HA for RC so far, can once more test this way and see if no issues are there before next rc spin. Regards. Santhosh From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@trippaers.nl] Sent: Thursday, February 27, 2014 7:35 AM To: dev@cloudstack.apache.org Subject: Re: developers and mysql We don’t need to do anything for upgrade testing, in the release this feature is disabled, so there will be no issues when upgrading a stock release. However it might be worth mentioning that if the admin switched to the HA procedure he should either disable this before upgrading or make sure he uses the noredist build when upgrading. I’m not familiar with “felton, what is that? Cheers, Hugo On 27 feb. 2014, at 10:02, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: Does this all warrant a process sign off of upgrade testing? HA working in production and upgrading to felton with changes below? Thanks! Santhosh From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@trippaers.nl] Sent: Thursday, February 27, 2014 3:51 AM To: dev@cloudstack.apache.org Subject: Re: developers and mysql Done commit a0f932437c9ac9a0a82cc9b45b1aa6f17e8a478a Author: Hugo Trippaers htrippa...@schubergphilis.com Date: Thu Feb 27 09:48:55 2014 +0100 Move mysql ha strategy to a plugin. Activate this plugin using the mysqlha profile or the noredist flag On 27 feb. 2014, at 09:25, Hugo Trippaers trip...@gmail.com wrote: On 27 feb. 2014, at 09:09, Alex Huang alex.hu...@citrix.com wrote: Abhi, It's not licensing issue that troubles me. It's the fact that mysql's been made a compile dependency when it wasn't before. It encourages people to adopt more mysql functionality into the cloudstack code. Eventually that means we get more and more tied in with mysql once the trend has started. Agreed, that is a risk. We need to keep paying attention that new additions don’t introduce something we are not comfortable with. We maybe could make a jenkins check that will alert if the dependency list changes from a previous compile. Should be possible with a little creative scripting. I would prefer the entire file is not in CloudStack as it really has nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion of this being put into pluginin enabled by noredist and mysql is only dependent upon in that plugin's pom.xml. My reasoning here is that somebody took the time and effort to write something to either improve cloudstack or fix a problem. We should try to include this if we reasonably can, every contribution is valuable. That said i would be curious to know if anyone is relying on this at the moment. --Alex -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, February 26, 2014 9:54 PM To: dev@cloudstack.apache.org; Damoder Reddy Subject: Re: developers and mysql Immediately if there are no specific licensing issues we should maintain the status-quo. The fact is that some other HA solutions will not work as all the schema related scripts are mysql engine specific. When we decide to move the mysql dependency out of cloudstack we should do it for all such dependencies. If there is an agreement here we can file a ticket to track this. -abhi On 27/02/14 11:16 am, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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
RE: developers and mysql
Hugo, Felton is release name in citrix. I think Santhosh meant 4.4. --Alex -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Thursday, February 27, 2014 4:35 AM To: dev@cloudstack.apache.org Subject: Re: developers and mysql We don't need to do anything for upgrade testing, in the release this feature is disabled, so there will be no issues when upgrading a stock release. However it might be worth mentioning that if the admin switched to the HA procedure he should either disable this before upgrading or make sure he uses the noredist build when upgrading. I'm not familiar with felton, what is that? Cheers, Hugo On 27 feb. 2014, at 10:02, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: Does this all warrant a process sign off of upgrade testing? HA working in production and upgrading to felton with changes below? Thanks! Santhosh From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@trippaers.nl] Sent: Thursday, February 27, 2014 3:51 AM To: dev@cloudstack.apache.org Subject: Re: developers and mysql Done commit a0f932437c9ac9a0a82cc9b45b1aa6f17e8a478a Author: Hugo Trippaers htrippa...@schubergphilis.com Date: Thu Feb 27 09:48:55 2014 +0100 Move mysql ha strategy to a plugin. Activate this plugin using the mysqlha profile or the noredist flag On 27 feb. 2014, at 09:25, Hugo Trippaers trip...@gmail.com wrote: On 27 feb. 2014, at 09:09, Alex Huang alex.hu...@citrix.com wrote: Abhi, It's not licensing issue that troubles me. It's the fact that mysql's been made a compile dependency when it wasn't before. It encourages people to adopt more mysql functionality into the cloudstack code. Eventually that means we get more and more tied in with mysql once the trend has started. Agreed, that is a risk. We need to keep paying attention that new additions don't introduce something we are not comfortable with. We maybe could make a jenkins check that will alert if the dependency list changes from a previous compile. Should be possible with a little creative scripting. I would prefer the entire file is not in CloudStack as it really has nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion of this being put into pluginin enabled by noredist and mysql is only dependent upon in that plugin's pom.xml. My reasoning here is that somebody took the time and effort to write something to either improve cloudstack or fix a problem. We should try to include this if we reasonably can, every contribution is valuable. That said i would be curious to know if anyone is relying on this at the moment. --Alex -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, February 26, 2014 9:54 PM To: dev@cloudstack.apache.org; Damoder Reddy Subject: Re: developers and mysql Immediately if there are no specific licensing issues we should maintain the status-quo. The fact is that some other HA solutions will not work as all the schema related scripts are mysql engine specific. When we decide to move the mysql dependency out of cloudstack we should do it for all such dependencies. If there is an agreement here we can file a ticket to track this. -abhi On 27/02/14 11:16 am, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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
RE: developers and mysql
I would prefer the entire file is not in CloudStack as it really has nothing to do with CloudStack itself. But, I'm fine with Hugo suggestion of this being put into pluginin enabled by noredist and mysql is only dependent upon in that plugin's pom.xml. My reasoning here is that somebody took the time and effort to write something to either improve cloudstack or fix a problem. We should try to include this if we reasonably can, every contribution is valuable. That said i would be curious to know if anyone is relying on this at the moment. +1 My thought exactly. Thanks for getting that in. --Alex
Re: developers and mysql
On Thu, Feb 27, 2014 at 4:02 AM, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: Does this all warrant a process sign off of upgrade testing? HA working in production and upgrading to felton with changes below? Thanks! Santhosh What is felton?
Re: developers and mysql
Never mind - I see that was asked and answered. On Thu, Feb 27, 2014 at 10:25 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 27, 2014 at 4:02 AM, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: Does this all warrant a process sign off of upgrade testing? HA working in production and upgrading to felton with changes below? Thanks! Santhosh What is felton?
Re: developers and mysql
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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com wrote: Great, John - thanks again! On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com wrote: Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.comailto: j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto: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 mailto:trip...@gmail.commailto: trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto: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 mailto:alex.hu...@citrix.commailto: alex.hu...@citrix.commailto: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.orgmailto:dev@cloudstack.apache.orgmailto: 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.commailto:rajani.karut...@citrix.commailto: rajani.karut...@citrix.com wrote: Can we move the mysql-connector-java dependency to the parent
Re: developers and mysql
Actually - I get this same error in master, as well. Consistent at least. :) On Thu, Feb 27, 2014 at 12:37 PM, Mike Tutkowski mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.com wrote: Great, John - thanks again! On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com wrote: Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.co mailto:j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto: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 mailto:trip...@gmail.commailto: trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto: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 mailto:alex.hu...@citrix.commailto: alex.hu...@citrix.commailto: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.orgmailto:dev@cloudstack.apache.org mailto: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
Re: developers and mysql
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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com wrote: Great, John - thanks again! On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella j...@stratosec.comailto:j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com wrote: Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.comailto:j...@stratosec.co mailto:j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.commailto:sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto: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.commailto:trip...@gmail.com mailto:trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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.commailto:alex.hu...@citrix.com mailto:alex.hu...@citrix.commailto: alex.hu...@citrix.commailto:alex.hu...@citrix.commailto: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.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org mailto: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
Re: developers and mysql
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 j...@stratosec.co 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 mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com wrote: Great, John - thanks again! On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella j...@stratosec.comailto: j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.commailto: mike.tutkow...@solidfire.com wrote: Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.comailto: j...@stratosec.co mailto:j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.commailto: mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto: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.commailto: trip...@gmail.com mailto:trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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.commailto: alex.hu...@citrix.com mailto:alex.hu...@citrix.commailto: alex.hu...@citrix.commailto:alex.hu...@citrix.commailto: 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.orgmailto:dev@cloudstack.apache.orgmailto: dev@cloudstack.apache.org mailto: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
Re: developers and mysql
OK, just an FYI - MySQL did appear to be corrupted after my upgrade to Mac OS 10.9.2. After re-installing MySQL, I can now run CloudStack again. Thanks :) On Thu, Feb 27, 2014 at 2:15 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: 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 j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com wrote: Great, John - thanks again! On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella j...@stratosec.comailto: j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.commailto: mike.tutkow...@solidfire.com wrote: Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.comailto: j...@stratosec.co mailto:j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.commailto: mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto: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 mailto:trip...@gmail.com mailto:trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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 mailto:alex.hu...@citrix.com mailto:alex.hu...@citrix.commailto: alex.hu...@citrix.commailto:alex.hu...@citrix.commailto: 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.orgmailto:dev@cloudstack.apache.orgmailto: dev@cloudstack.apache.org mailto: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
Re: developers and mysql
@cloudstack.apache.orgmailto: dev@cloudstack.apache.org mailto: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.commailto:rajani.karut...@citrix.commailto: rajani.karut...@citrix.commailto: rajani.karut...@citrix.commailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto:da...@gnsa.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto: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.comailto:j...@stratosec.comailto: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.nlmailto:h...@trippaers.nlmailto: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 -- Thanks and Regards, *Sonal Ojha* * Senior Engineer Product Development * SunGard IT Availability Mobile +91-9922412645* E-Mail: sonal.o...@sungard.commailto: sonal.o...@sungard.commailto: sonal.o...@sungard.commailto:sonal.o...@sungard.commailto: sonal.o...@sungard.commailto:sonal.o...@sungard.commailto: sonal.o...@sungard.com -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com o
Re: developers and mysql
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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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
Re: developers and mysql
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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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
Re: developers and mysql
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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.commailto: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.commailto: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.usmailto: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.commailto: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.orgmailto: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.commailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto: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.comailto:j...@stratosec.comailto: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.nlmailto:h...@trippaers.nlmailto: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
Re: developers and mysql
Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.co 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 mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.com mailto: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.commailto: 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.usmailto: 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.commailto: 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.orgmailto: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.commailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto: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.comailto:j...@stratosec.comailto: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.nlmailto:h...@trippaers.nlmailto:h...@trippaers.nl wrote: Heya, as the mysql dependency is now set
Re: developers and mysql
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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com wrote: Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.comailto:j...@stratosec.co 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 mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.commailto:sonal.o...@sungard.com mailto: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.commailto:trip...@gmail.commailto: trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto: da...@gnsa.usmailto: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.commailto:alex.hu...@citrix.commailto: alex.hu...@citrix.commailto: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.orgmailto:dev@cloudstack.apache.orgmailto: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.commailto:rajani.karut...@citrix.commailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto:trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto:da...@gnsa.usmailto: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.comailto:j...@stratosec.comailto:j...@stratosec.comailto: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
Re: developers and mysql
Great, John - thanks again! On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella j...@stratosec.co 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 mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com wrote: Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.comailto: j...@stratosec.co 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 mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto: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.commailto: trip...@gmail.commailto: trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto: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.commailto: alex.hu...@citrix.commailto: alex.hu...@citrix.commailto: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.orgmailto:dev@cloudstack.apache.orgmailto: 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.commailto:rajani.karut...@citrix.commailto: 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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto:da...@gnsa.usmailto: 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.comailto:j
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:trip...@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 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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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
RE: developers and mysql
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:trip...@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 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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId
Re: developers and mysql
StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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:trip...@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 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
Re: developers and mysql
Immediately if there are no specific licensing issues we should maintain the status-quo. The fact is that some other HA solutions will not work as all the schema related scripts are mysql engine specific. When we decide to move the mysql dependency out of cloudstack we should do it for all such dependencies. If there is an agreement here we can file a ticket to track this. -abhi On 27/02/14 11:16 am, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part of the mysql jdbc driver providing a specific strategy that works as per the documented HA procedure. I think moving it to a separate github project that generates the additional mysql connector jar should be ok (any licensing issues). We can then document that anyone configuring DB-HA as per the suggested procedure should download this and add it to the classpath. -abhi On 27/02/14 10:54 am, Alex Huang alex.hu...@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:trip...@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 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
Re: developers and mysql
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 mike.tutkow...@solidfire.com wrote: Great, John - thanks again! On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella j...@stratosec.co 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 mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com wrote: Awesome! Thanks, John! On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella j...@stratosec.comailto: j...@stratosec.co 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 mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com 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 sonal.o...@sungard.com mailto:sonal.o...@sungard.com mailto: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 mailto:trip...@gmail.commailto: trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto: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 mailto:alex.hu...@citrix.commailto: alex.hu...@citrix.commailto: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.orgmailto:dev@cloudstack.apache.orgmailto: 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.commailto:rajani.karut...@citrix.commailto: 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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb
Re: developers and mysql
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.hu...@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:trip...@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 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
RE: developers and mysql
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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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
Re: developers and mysql
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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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
Re: developers and mysql
Commit 67fc2f53 Cheers, Hugo Sent from my iPhone On 25 feb. 2014, at 22:44, 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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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
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 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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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
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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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
Re: developers and mysql
Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto: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.commailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto: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.comailto:j...@stratosec.comailto: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.nlmailto:h...@trippaers.nlmailto: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 Stratosechttp://stratosec.co/ - Compliance as a Service o: 415.315.9385 @johnlkinsellahttp://twitter.com/johnlkinsella
Re: developers and mysql
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=trueprepStmtCacheSize=517cachePrepStmts=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 wrote: Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto: 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 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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: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.comailto: j...@stratosec.comailto: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.nlmailto: h...@trippaers.nlmailto: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 Stratosechttp://stratosec.co/ - Compliance as a Service o: 415.315.9385 @johnlkinsellahttp://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 cloudhttp://solidfire.com/solution/overview/?video=play *(tm)*
Re: developers and mysql
Did you re-run mvn -P deps? On Feb 25, 2014, at 12:16 PM, Mike Tutkowski mike.tutkow...@solidfire.commailto: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=trueprepStmtCacheSize=517cachePrepStmts=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.comailto:j...@stratosec.co wrote: Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto:h...@trippaers.nlmailto: h...@trippaers.nlmailto: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.commailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto:trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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.comailto:j...@stratosec.comailto: j...@stratosec.comailto:j...@stratosec.comailto: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.nlmailto:h...@trippaers.nlmailto: h...@trippaers.nlmailto:h...@trippaers.nlmailto: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
Re: developers and mysql
I should point out that I'm having this issue on 4.3 (haven't tried to run master in a couple weeks). On Tue, Feb 25, 2014 at 1:16 PM, Mike Tutkowski 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=trueprepStmtCacheSize=517cachePrepStmts=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 wrote: Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto: 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 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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: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.comailto: j...@stratosec.comailto: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.nlmailto: h...@trippaers.nlmailto: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 Stratosechttp://stratosec.co/ - Compliance as a Service o: 415.315.9385 @johnlkinsellahttp://twitter.com/johnlkinsella -- *Mike Tutkowski* *Senior
Re: developers and mysql
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=trueprepStmtCacheSize=517cachePrepStmts=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.comailto: j...@stratosec.co wrote: Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto: h...@trippaers.nlmailto: h...@trippaers.nlmailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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.comailto: j...@stratosec.comailto: j...@stratosec.comailto:j...@stratosec.comailto: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.nlmailto: h...@trippaers.nlmailto: h...@trippaers.nlmailto:h...@trippaers.nlmailto: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
Re: developers and mysql
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=trueprepStmtCacheSize=517cachePrepStmts=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.commailto: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=trueprepStmtCacheSize=517cachePrepStmts=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.comailto: j...@stratosec.co wrote: Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto: h...@trippaers.nlmailto: h...@trippaers.nlmailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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.comailto: j...@stratosec.comailto: j...@stratosec.comailto:j...@stratosec.comailto: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.nlmailto: h...@trippaers.nlmailto: h...@trippaers.nlmailto:h...@trippaers.nlmailto:h...@trippaers.nl wrote: Heya, as the mysql dependency is now set to provided in all the
Re: developers and mysql
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=trueprepStmtCacheSize=517cachePrepStmts=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.commailto: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=trueprepStmtCacheSize=517cachePrepStmts=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.comailto: j...@stratosec.co wrote: Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto: h...@trippaers.nlmailto: h...@trippaers.nlmailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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.comailto: j...@stratosec.comailto:j...@stratosec.comailto: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
Re: developers and mysql
Ah - don’t think that’s been cherry-picked yet to 4.3... On Feb 25, 2014, at 12:23 PM, Mike Tutkowski mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com wrote: I should point out that I'm having this issue on 4.3 (haven't tried to run master in a couple weeks). On Tue, Feb 25, 2014 at 1:16 PM, Mike Tutkowski mike.tutkow...@solidfire.commailto: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=trueprepStmtCacheSize=517cachePrepStmts=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.comailto:j...@stratosec.co wrote: Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto:h...@trippaers.nlmailto: h...@trippaers.nlmailto: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.commailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto:trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto:da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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.comailto:j...@stratosec.comailto: j...@stratosec.comailto:j...@stratosec.comailto: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.nlmailto:h...@trippaers.nlmailto: h...@trippaers.nlmailto:h...@trippaers.nlmailto: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
Re: developers and mysql
Ah, not back ported to 4.3...that will do it. :) On Tue, Feb 25, 2014 at 1:59 PM, John Kinsella j...@stratosec.co wrote: Ah - don't think that's been cherry-picked yet to 4.3... On Feb 25, 2014, at 12:23 PM, Mike Tutkowski mike.tutkow...@solidfire.com mailto:mike.tutkow...@solidfire.com wrote: I should point out that I'm having this issue on 4.3 (haven't tried to run master in a couple weeks). On Tue, Feb 25, 2014 at 1:16 PM, Mike Tutkowski mike.tutkow...@solidfire.commailto: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=trueprepStmtCacheSize=517cachePrepStmts=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.comailto: j...@stratosec.co wrote: Yep that works - thanks! Will close 6157. On Feb 25, 2014, at 3:33 AM, Hugo Trippaers h...@trippaers.nlmailto: h...@trippaers.nlmailto: h...@trippaers.nlmailto: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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: trip...@gmail.commailto: trip...@gmail.commailto:trip...@gmail.commailto: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.usmailto: da...@gnsa.usmailto: da...@gnsa.usmailto:da...@gnsa.usmailto: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.comailto: j...@stratosec.comailto: j...@stratosec.comailto:j...@stratosec.comailto: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.nlmailto: h...@trippaers.nlmailto: h...@trippaers.nlmailto:h...@trippaers.nlmailto: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
developers and mysql
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
Re: developers and mysql
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 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
Re: developers and mysql
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 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 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
Re: developers and mysql
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 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 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 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
Re: developers and mysql
Hugo, fail to start latest master build on my machine, here is the 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=trueprepStmtCacheSize=517 cachePrepStmts=true at java.sql.DriverManager.getConnection(DriverManager.java:596) at java.sql.DriverManager.getConnection(DriverManager.java:215) Can you please tell me what needs to be done in order to fix it? Thanks, Alena. On 2/24/14, 10:11 AM, Hugo Trippaers 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 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 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 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
Re: developers and mysql
Sorry, forgot to mention the steps I¹ve done: On 2/24/14, 11:41 AM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Hugo, fail to start latest master build on my machine, here is the 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=trueprepStmtCacheSize=517 cachePrepStmts=true at java.sql.DriverManager.getConnection(DriverManager.java:596) at java.sql.DriverManager.getConnection(DriverManager.java:215) Can you please tell me what needs to be done in order to fix it? Thanks, Alena. On 2/24/14, 10:11 AM, Hugo Trippaers 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 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 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 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
Re: developers and mysql
Sorry, forgot to mention the steps I¹ve done: mvn install -P developer,systemvm -DskipTests cp mysql-connector-java-5.1.21.jar client/target/cloud-client-ui-4.4.0-SNAPSHOT/WEB-INF/lib/ mvn -pl :cloud-client-ui jetty:run And I still hitting the error below. Am I missing something? Thanks, Alena. On 2/24/14, 11:41 AM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Hugo, fail to start latest master build on my machine, here is the 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=trueprepStmtCacheSize=517 cachePrepStmts=true at java.sql.DriverManager.getConnection(DriverManager.java:596) at java.sql.DriverManager.getConnection(DriverManager.java:215) Can you please tell me what needs to be done in order to fix it? Thanks, Alena. On 2/24/14, 10:11 AM, Hugo Trippaers 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 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 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 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
Re: developers and mysql
Nope. That’s the current state of things. On Feb 24, 2014, at 2:28 PM, Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com wrote: Sorry, forgot to mention the steps I¹ve done: mvn install -P developer,systemvm -DskipTests cp mysql-connector-java-5.1.21.jar client/target/cloud-client-ui-4.4.0-SNAPSHOT/WEB-INF/lib/ mvn -pl :cloud-client-ui jetty:run And I still hitting the error below. Am I missing something? Thanks, Alena. On 2/24/14, 11:41 AM, Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com wrote: Hugo, fail to start latest master build on my machine, here is the 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=trueprepStmtCacheSize=517 cachePrepStmts=true at java.sql.DriverManager.getConnection(DriverManager.java:596) at java.sql.DriverManager.getConnection(DriverManager.java:215) Can you please tell me what needs to be done in order to fix it? Thanks, Alena. On 2/24/14, 10:11 AM, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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 Stratosechttp://stratosec.co/ - Compliance as a Service o: 415.315.9385 @johnlkinsellahttp://twitter.com/johnlkinsella
RE: developers and mysql
Hugo, I understand removing mysql jar during compile time by switching the scope to 'provided', but I don't understand why it's necessary to remove it from jetty run and deploy db. In a normal build, these two targets are not run. They're just convenience targets. --Alex -Original Message- From: Hugo Trippaers [mailto:trip...@gmail.com] Sent: Monday, February 24, 2014 10:12 AM To: dev@cloudstack.apache.org Cc: dev@cloudstack.apache.org Subject: Re: developers and mysql 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 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 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 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
Re: developers and mysql
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 iddeveloper/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopecompile/scope /dependency /dependencies /profile profile idproduction/id dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scopeprovided/scope /dependency /dependencies /profile Thanks, ~Rajani On 24-Feb-2014, at 11:41 pm, Hugo Trippaers trip...@gmail.commailto: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.usmailto: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.comailto: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.nlmailto: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
