Thread: [Squirrel-sql-develop] Refactoring Plugin
A Java SQL client for any JDBC compliant database
Brought to you by:
colbell,
gerdwagner
From: Nathan V. <Nat...@su...> - 2007-05-05 14:21:27
|
Hi, I'm the developer of LiquiBase, a database refactoring manager = (www.liquibase.org = <https://mail.sundog.net/exchweb/bin/redir.asp?URL=3Dhttp://www.liquibase= .org> ). I am looking to start making IDE plug-in front-ends to it and = am thinking of starting with a SQuirreL plugin. I've gotten a good = start on it already and am impressed with how easy it is to develop and = integrate. =20 =20 My question is if you would be interested in having me contribute it = directly to SQuirreL, or if I should keep it independent? I see you = already have a refactoring plugin, but it appears to be just partially = done (version 0.2 if I remember right) but I don't know what future = ideas you have for that plug-in. =20 =20 I'd be fine keeping it independent, but thought I would offer it as a = way to improve the existing refactoring plugin, or as a different = refactoring option bundled with SQuirreL =20 Nathan |
From: Robert M. <rob...@gm...> - 2007-05-05 17:57:28
|
On 5/5/07, Nathan Voxland <Nat...@su...> wrote: > Hi, I'm the developer of LiquiBase, a database refactoring manager > (www.liquibase.org). I am looking to start making IDE plug-in front-ends to > it and am thinking of starting with a SQuirreL plugin. I've gotten a good > start on it already and am impressed with how easy it is to develop and > integrate. > > My question is if you would be interested in having me contribute it > directly to SQuirreL, or if I should keep it independent? I see you already > have a refactoring plugin, but it appears to be just partially done (version > 0.2 if I remember right) but I don't know what future ideas you have for > that plug-in. > > I'd be fine keeping it independent, but thought I would offer it as a way to > improve the existing refactoring plugin, or as a different refactoring > option bundled with SQuirreL > Nathan, The current refactoring plugin doesn't support all of the refactoring options that LiquiBase does. However it has been tested against ~20 different databases (See sql12/fw/src/net/sourceforge/squirrel_sql/fw/dialects/*). In my mind, neither one appears to have a clear advantage. I'm ok with having another Refactoring plugin (although we need a different name - maybe LiquiBase Refactoring Plugin?). Since LiquiBase is licensed under LGPL, it seems fine to me to distribute it along with SQuirreL. It seems that your goal (from this page: http://www.liquibase.org/refactoring_ide/index.html) is to build it in such a way that it is able to be included as a plugin in different IDEs. Might I suggest a third option to the two you gave? Perhaps you could maintain the core refactoring functionality in a library that gets included by the plugin in SQuirreL or whatever other IDE you write a plugin for. That way, you would have the source code for core functionality in just one place - your existing source code repository. Having the code in two places and maintaining both gets old pretty quick. We could then get you a SourceForge account to allow you maintain the SQuirreL plugin code that depends on the library. Does that sound workable to you? Rob |
From: Robert M. <rob...@gm...> - 2007-05-07 21:59:28
|
On 5/7/07, Nathan Voxland <Nat...@su...> wrote: > I think it would be best to keep the SQuirreL-specific code in the > SQuirreL repository. Anything that would be in there should be fairly > SQuirreL-specific and it would work best with your build and install > scripts. When it comes time to create the real NetBeans and Eclipse > plug-ins, I may keep them in separate repositories anyway. > > I have a question on what you prefer for laying out the UI. I use > IntelliJ, so their built-in visual editor is the easiest for me, but > would not be as easy for non-intelliJ users to work with. Would you > rather have me use jform or NetBean's Matisse, or is the IntelliJ one > fine? > I looked at Matisse a little while back, but it required GroupLayout which seemed NetBeans-specific at the time. However, now it's in the JDK (not sure if it's 1.5 or 1.6), so maybe it's time to look again. I would say, as long as the UI code that is generated is mostly self-contained and integrates well with the existing Swing code, I wouldn't be against it. I'm definitely thumbs down on integrating a UI framework that requires re-writing the existing UI code :) Rob |
From: Nathan V. <Nat...@su...> - 2007-05-08 14:40:08
|
The IntelliJ layout manager has its own library it depends on, but is self-contained. I'll see what Matisse requires now and if it doesn't require anything, I'll use that. If it still adds dependencies, I'll probably use IntelliJ for now, and after the UI stabilizes a bit, I may look at laying the controls out in a more standard way.=20 -----Original Message----- From: Robert Manning [mailto:rob...@gm...]=20 Sent: Monday, May 07, 2007 4:59 PM To: Nathan Voxland Cc: squirrel-sql-develop Subject: Re: [Squirrel-sql-develop] Refactoring Plugin On 5/7/07, Nathan Voxland <Nat...@su...> wrote: > I think it would be best to keep the SQuirreL-specific code in the > SQuirreL repository. Anything that would be in there should be fairly > SQuirreL-specific and it would work best with your build and install > scripts. When it comes time to create the real NetBeans and Eclipse > plug-ins, I may keep them in separate repositories anyway. > > I have a question on what you prefer for laying out the UI. I use > IntelliJ, so their built-in visual editor is the easiest for me, but > would not be as easy for non-intelliJ users to work with. Would you > rather have me use jform or NetBean's Matisse, or is the IntelliJ one > fine? > I looked at Matisse a little while back, but it required GroupLayout which seemed NetBeans-specific at the time. However, now it's in the JDK (not sure if it's 1.5 or 1.6), so maybe it's time to look again. I would say, as long as the UI code that is generated is mostly self-contained and integrates well with the existing Swing code, I wouldn't be against it. I'm definitely thumbs down on integrating a UI framework that requires re-writing the existing UI code :) Rob |
From: Stan B. <sb...@po...> - 2007-05-08 16:54:45
|
I have just checked it: Matisse requires a GroupLayout, which is not part of stand. API of java 1.5 (it is freely distributable), but has become part of Swing in 1.6. -- Stan Berka Nathan Voxland wrote: > The IntelliJ layout manager has its own library it depends on, but is > self-contained. I'll see what Matisse requires now and if it doesn't > require anything, I'll use that. If it still adds dependencies, I'll > probably use IntelliJ for now, and after the UI stabilizes a bit, I may > look at laying the controls out in a more standard way. > > -----Original Message----- > From: Robert Manning [mailto:rob...@gm...] > Sent: Monday, May 07, 2007 4:59 PM > To: Nathan Voxland > Cc: squirrel-sql-develop > Subject: Re: [Squirrel-sql-develop] Refactoring Plugin > > On 5/7/07, Nathan Voxland <Nat...@su...> wrote: > >> I think it would be best to keep the SQuirreL-specific code in the >> SQuirreL repository. Anything that would be in there should be fairly >> SQuirreL-specific and it would work best with your build and install >> scripts. When it comes time to create the real NetBeans and Eclipse >> plug-ins, I may keep them in separate repositories anyway. >> >> I have a question on what you prefer for laying out the UI. I use >> IntelliJ, so their built-in visual editor is the easiest for me, but >> would not be as easy for non-intelliJ users to work with. Would you >> rather have me use jform or NetBean's Matisse, or is the IntelliJ one >> fine? >> >> > > I looked at Matisse a little while back, but it required GroupLayout > which seemed NetBeans-specific at the time. However, now it's in the > JDK (not sure if it's 1.5 or 1.6), so maybe it's time to look again. > I would say, as long as the UI code that is generated is mostly > self-contained and integrates well with the existing Swing code, I > wouldn't be against it. I'm definitely thumbs down on integrating a > UI framework that requires re-writing the existing UI code :) > > Rob > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Squirrel-sql-develop mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop > > |
From: Nathan V. <Nat...@su...> - 2007-05-08 17:01:39
|
Then I'll start out trying to stick with standard swing APIs without using a layout tool. I'm not envisioning a lot of complex UIs, so that may not be too bad. I'll get a more fully working code-base and then look at moving it into the SQuirreL repository. I'll send along the code when I'm ready. Nathan=20 -----Original Message----- From: squ...@li... [mailto:squ...@li...] On Behalf Of Stan Berka Sent: Tuesday, May 08, 2007 11:55 AM To: squirrel-sql-develop Subject: Re: [Squirrel-sql-develop] Refactoring Plugin I have just checked it: Matisse requires a GroupLayout, which is not=20 part of stand. API of java 1.5 (it is freely distributable), but has=20 become part of Swing in 1.6. -- Stan Berka Nathan Voxland wrote: > The IntelliJ layout manager has its own library it depends on, but is > self-contained. I'll see what Matisse requires now and if it doesn't > require anything, I'll use that. If it still adds dependencies, I'll > probably use IntelliJ for now, and after the UI stabilizes a bit, I may > look at laying the controls out in a more standard way.=20 > > -----Original Message----- > From: Robert Manning [mailto:rob...@gm...]=20 > Sent: Monday, May 07, 2007 4:59 PM > To: Nathan Voxland > Cc: squirrel-sql-develop > Subject: Re: [Squirrel-sql-develop] Refactoring Plugin > > On 5/7/07, Nathan Voxland <Nat...@su...> wrote: > =20 >> I think it would be best to keep the SQuirreL-specific code in the >> SQuirreL repository. Anything that would be in there should be fairly >> SQuirreL-specific and it would work best with your build and install >> scripts. When it comes time to create the real NetBeans and Eclipse >> plug-ins, I may keep them in separate repositories anyway. >> >> I have a question on what you prefer for laying out the UI. I use >> IntelliJ, so their built-in visual editor is the easiest for me, but >> would not be as easy for non-intelliJ users to work with. Would you >> rather have me use jform or NetBean's Matisse, or is the IntelliJ one >> fine? >> >> =20 > > I looked at Matisse a little while back, but it required GroupLayout > which seemed NetBeans-specific at the time. However, now it's in the > JDK (not sure if it's 1.5 or 1.6), so maybe it's time to look again. > I would say, as long as the UI code that is generated is mostly > self-contained and integrates well with the existing Swing code, I > wouldn't be against it. I'm definitely thumbs down on integrating a > UI framework that requires re-writing the existing UI code :) > > Rob > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Squirrel-sql-develop mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop > > =20 ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Squirrel-sql-develop mailing list Squ...@li... https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop |
From: Nathan V. <Nat...@su...> - 2007-05-06 15:03:36
|
I forgot to hit "reply all" on this. ________________________________ From: Nathan Voxland Sent: Sun 5/6/2007 9:22 AM To: Robert Manning Subject: RE: [Squirrel-sql-develop] Refactoring Plugin You're right about the difference in the number of databases supported. = I'm hoping to support more eventually, but am just focusing on those = four for version 1.0. Because of that, I think you're right that = having both plug-ins is a good idea. =20 =20 I think you are thinking along the same lines as I was if LiquiBase = plugin code was included with SQuirreL. I designed LiquiBase to have a = core migrator jar that has no dependencies and contains just the = refactoring engine. As I build IDE plugins, I was going to keep the = code from them distributed independently of the core. I'm not sure how = much (if any) code can be shared between plug-ins that isn't part of the = LiquiBase core. I've started plug-ins for Eclipse and NetBeans, and they = abstract their UI components and actions enough that there may not be a = lot of commonality, we'll have to just see. Neither have a = well-developed, extendable database interface so I am planning on = focusing SQuirreL first, then see what I can abstract out. If there is = common plug-in classes, I'll keep those in my repository along with the = LiquiBase core. =20 =20 What you were suggesting is for me to keep the SQuirreL LiquiBase = plug-in code in my repository as well, and commit the compiled plug-in = jars to SQuirreL as new versions are completed. Is that right, or were = you suggesting I keep the SQuirreL-specific code in the SQuirreL = repository? I think either option would be fine. Keeping the SQuirreL = code in the SQuirreL repository may make it easier for other SQuirreL = developers to find bugs and hopefully make improvements, but keeping it = the SQuirreL code in the same repository as the base plug-in code may be = easier in the long run. I'm just looking for what would best allow us = to help improve each other's projects. =20 Nathan ________________________________ From: Robert Manning [mailto:rob...@gm...] Sent: Sat 5/5/2007 12:57 PM To: Nathan Voxland Cc: squ...@li... Subject: Re: [Squirrel-sql-develop] Refactoring Plugin On 5/5/07, Nathan Voxland <Nat...@su...> wrote: > Hi, I'm the developer of LiquiBase, a database refactoring manager > (www.liquibase.org). I am looking to start making IDE plug-in = front-ends to > it and am thinking of starting with a SQuirreL plugin. I've gotten a = good > start on it already and am impressed with how easy it is to develop = and > integrate. > > My question is if you would be interested in having me contribute it > directly to SQuirreL, or if I should keep it independent? I see you = already > have a refactoring plugin, but it appears to be just partially done = (version > 0.2 if I remember right) but I don't know what future ideas you have = for > that plug-in. > > I'd be fine keeping it independent, but thought I would offer it as a = way to > improve the existing refactoring plugin, or as a different refactoring > option bundled with SQuirreL > Nathan, The current refactoring plugin doesn't support all of the refactoring options that LiquiBase does. However it has been tested against ~20 different databases (See sql12/fw/src/net/sourceforge/squirrel_sql/fw/dialects/*). In my mind, neither one appears to have a clear advantage. I'm ok with having another Refactoring plugin (although we need a different name - maybe LiquiBase Refactoring Plugin?). Since LiquiBase is licensed under LGPL, it seems fine to me to distribute it along with SQuirreL. It seems that your goal (from this page: http://www.liquibase.org/refactoring_ide/index.html) is to build it in such a way that it is able to be included as a plugin in different IDEs. Might I suggest a third option to the two you gave? Perhaps you could maintain the core refactoring functionality in a library that gets included by the plugin in SQuirreL or whatever other IDE you write a plugin for. That way, you would have the source code for core functionality in just one place - your existing source code repository. Having the code in two places and maintaining both gets old pretty quick. We could then get you a SourceForge account to allow you maintain the SQuirreL plugin code that depends on the library. Does that sound workable to you? Rob |
From: Nathan V. <Nat...@su...> - 2007-05-07 15:43:15
|
Still forgetting "Reply to all"... -----Original Message----- From: Nathan Voxland=20 Sent: Monday, May 07, 2007 10:32 AM To: 'Robert Manning' Subject: RE: [Squirrel-sql-develop] Refactoring Plugin I think it would be best to keep the SQuirreL-specific code in the SQuirreL repository. Anything that would be in there should be fairly SQuirreL-specific and it would work best with your build and install scripts. When it comes time to create the real NetBeans and Eclipse plug-ins, I may keep them in separate repositories anyway. =20 I have a question on what you prefer for laying out the UI. I use IntelliJ, so their built-in visual editor is the easiest for me, but would not be as easy for non-intelliJ users to work with. Would you rather have me use jform or NetBean's Matisse, or is the IntelliJ one fine? Nathan -----Original Message----- From: Robert Manning [mailto:rob...@gm...]=20 Sent: Sunday, May 06, 2007 11:52 AM To: Nathan Voxland Subject: Re: [Squirrel-sql-develop] Refactoring Plugin On 5/6/07, Nathan Voxland <Nat...@su...> wrote: > I think you are thinking along the same lines as I was if LiquiBase plugin > code was included with SQuirreL. I designed LiquiBase to have a core > migrator jar that has no dependencies and contains just the refactoring > engine. As I build IDE plugins, I was going to keep the code from them > distributed independently of the core. I'm not sure how much (if any) code > can be shared between plug-ins that isn't part of the LiquiBase core. I've > started plug-ins for Eclipse and NetBeans, and they abstract their UI > components and actions enough that there may not be a lot of commonality, > we'll have to just see. Neither have a well-developed, extendable database > interface so I am planning on focusing SQuirreL first, then see what I can > abstract out. If there is common plug-in classes, I'll keep those in my > repository along with the LiquiBase core. That sounds very reasonable. > > What you were suggesting is for me to keep the SQuirreL LiquiBase plug-in > code in my repository as well, and commit the compiled plug-in jars to > SQuirreL as new versions are completed. Is that right, or were you > suggesting I keep the SQuirreL-specific code in the SQuirreL repository? I > think either option would be fine. Keeping the SQuirreL code in the > SQuirreL repository may make it easier for other SQuirreL developers to find > bugs and hopefully make improvements, but keeping it the SQuirreL code in > the same repository as the base plug-in code may be easier in the long run. > I'm just looking for what would best allow us to help improve each other's > projects. I was thinking you might include the compiled jar(s) that represent the core refactoring functionality as a library that the SQuirreL plugin code would use. From my perspective, the SQuirreL plugin code would naturally be best kept in the SQuirreL repository. It would allow us to build our installer and archives including it, so users wouldn't need to go find it and download it separately. But the choice is yours, obviously, you will be maintaining it primarily, so if it's more convenient to keep it all in one place, that is fine. I imagine you'll already have the NetBeans and Eclipse plugins' source code in the same repository, so I could see the reasoning behind keeping the SQuirreL plugin code there as well. The only thing I would advise you not to do, is to (attempt to) keep the same source code in two different repositories. I've done this before and realized that time is precious, and I didn't need to spend it keeping repositories in sync. Rob |
From: Stefan K. <sfk...@hs...> - 2007-06-13 19:55:03
|
Nathan, Rob, all I am interested in refactoring databases and would like to know the status and plans to enhance the original refactoring plugin (and possibly the other one)? Currently it seems to support mainly add, modify and drop for table, columns and pk. This corresponds to the structural refactorings - but there are more as it's nicely compiled here http://www.liquibase.org/supported_refactorings.html -- Stefan -- View this message in context: http://www.nabble.com/Refactoring-Plugin-tf3696577.html#a11107622 Sent from the squirrel-sql-develop mailing list archive at Nabble.com. |
From: Nathan V. <Nat...@su...> - 2007-06-14 20:19:31
|
Hi, there was a discussion on this list earlier about whether to add LiquiBase support to the existing refactoring plug-in, or create a different one. In case you didn't read through it all, the end result was that since LiquiBase doesn't support as many databases, it would be better to start it as a separate plug-in. Here's my current status on the LiquiBase plugin: I started with adding some sample table-level refactorings. They have dialogs that allow you to specify needed parameters, execute the change against your database, and save the change to a hard-coded change log file. I was in the process of figuring out the best way to handle preferences for the location of the changelog files and changelog classpaths as well as a good UI for handling column level refactorings when I decided to focus more of the LiquiBase core migrator and take a break from the plug-in. If you are interested in continuing where I left off, I'd be happy to send you the source code and more in depth thoughts on features it should have. Nathan -----Original Message----- From: squ...@li... [mailto:squ...@li...] On Behalf Of Stefan Keller Sent: Wednesday, June 13, 2007 2:55 PM To: squ...@li... Subject: Re: [Squirrel-sql-develop] Refactoring Plugin Nathan, Rob, all I am interested in refactoring databases and would like to know the status and plans to enhance the original refactoring plugin (and possibly the other one)? Currently it seems to support mainly add, modify and drop for table, columns and pk. This corresponds to the structural refactorings - but there are more as it's nicely compiled here http://www.liquibase.org/supported_refactorings.html=20 -- Stefan --=20 View this message in context: http://www.nabble.com/Refactoring-Plugin-tf3696577.html#a11107622 Sent from the squirrel-sql-develop mailing list archive at Nabble.com. ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Squirrel-sql-develop mailing list Squ...@li... https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop |