Menu
▾
▴
jsynthlib-devel
|
From: Joe E. <jo...@em...> - 2011-09-08 16:30:13
|
Just wanted to get some opinions/preferences from the group: 1 - When I move all of the stuff from "core" into "org.jsynthlib", how should it be organized? I'm planning all of the "*ConfigPanel" stuff moving into org.jsynthlib.config, and probably all of "*Widget" going into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably going into org.jsynthlib.utils. There's a lot more stuff, however, that needs a home. Any suggestions for further categorization are welcome. I'm thinking that we might also want a dedicated package for the classes which the synthdrivers use for superclasses (ie, PatchEditorFrame, LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers which were subclassing some fairly strange frames... possibly because they were the first ones that they came across which seemed like they'd work or something. 2 - Some of the classes have their *type* implied in the name. For example, there's an abstract class called "AbstractLibraryFrame" and there are some interfaces called "IDriver" and "IBankPatch". These aren't really the way the base Java libraries do it and, personally, I find it confusing (I keep asking myself "What the heck is an 'abstract library'?"). My preference would be to rename AbstractLibraryFrame to just LibraryFrame, and IDriver to just Driver, etc. Any objections? - Joe |
|
From: William Z. <wrz...@po...> - 2011-09-09 00:48:15
|
My first suggestion is to move all source code into /src. Optionally, synthdrivers can be move to /src-synthdrivers or just /synthdrivers in preparation for the plugin framework. Synths should be repackaged as well, so the final directory will actually be /synthdrivers/org/jsynthlib/synthdrivers/*. On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker <jo...@em...> wrote: > > 1 - When I move all of the stuff from "core" into "org.jsynthlib", how > should it be organized? I'm planning all of the "*ConfigPanel" stuff > moving into org.jsynthlib.config, and probably all of "*Widget" going > into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably > going into org.jsynthlib.utils. There's a lot more stuff, however, that > needs a home. Any suggestions for further categorization are welcome. > I'm thinking that we might also want a dedicated package for the classes > which the synthdrivers use for superclasses (ie, PatchEditorFrame, > LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers > which were subclassing some fairly strange frames... possibly because > they were the first ones that they came across which seemed like they'd > work or something. > These are all excellent ideas. I might suggest an 'app' package for the main JSynthLib app, windows, menus, etc. 2 - Some of the classes have their *type* implied in the name. For > example, there's an abstract class called "AbstractLibraryFrame" and > there are some interfaces called "IDriver" and "IBankPatch". These > aren't really the way the base Java libraries do it and, personally, I > find it confusing (I keep asking myself "What the heck is an 'abstract > library'?"). My preference would be to rename AbstractLibraryFrame to > just LibraryFrame, and IDriver to just Driver, etc. Any objections? > I agree. I myself favor systems like "interface Driver" and "abstract class DriverBase". The system is then carefully coded to only require Driver so people can write fully custom implementations, but DriverBase is available as a starting point. I understand the reasoning behind names like IDriver and CDriver, but I always need the docs around when I code, so I've never found that trick useful. -Bill Zwicky |
|
From: denis q. <dqu...@fr...> - 2011-09-09 12:45:56
|
I don't read all the mails, but have you think of using Maven to build modules (libraries) instead of having one big build project ? Maybe you could have one project for the core, one for the synthdrivers etc. Just a suggestion as maven is used all the time in java projects. It helps to separate code entities and reuse them with the dependancies system. -- Denis > My first suggestion is to move all source code into /src. Optionally, > synthdrivers can be move to /src-synthdrivers or just /synthdrivers in > preparation for the plugin framework. Synths should be repackaged as well, > so the final directory will actually be > /synthdrivers/org/jsynthlib/synthdrivers/*. > > On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker<jo...@em...> wrote: > >> 1 - When I move all of the stuff from "core" into "org.jsynthlib", how >> should it be organized? I'm planning all of the "*ConfigPanel" stuff >> moving into org.jsynthlib.config, and probably all of "*Widget" going >> into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably >> going into org.jsynthlib.utils. There's a lot more stuff, however, that >> needs a home. Any suggestions for further categorization are welcome. >> I'm thinking that we might also want a dedicated package for the classes >> which the synthdrivers use for superclasses (ie, PatchEditorFrame, >> LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers >> which were subclassing some fairly strange frames... possibly because >> they were the first ones that they came across which seemed like they'd >> work or something. >> > These are all excellent ideas. I might suggest an 'app' package for the > main JSynthLib app, windows, menus, etc. > > 2 - Some of the classes have their *type* implied in the name. For >> example, there's an abstract class called "AbstractLibraryFrame" and >> there are some interfaces called "IDriver" and "IBankPatch". These >> aren't really the way the base Java libraries do it and, personally, I >> find it confusing (I keep asking myself "What the heck is an 'abstract >> library'?"). My preference would be to rename AbstractLibraryFrame to >> just LibraryFrame, and IDriver to just Driver, etc. Any objections? >> > I agree. I myself favor systems like "interface Driver" and "abstract class > DriverBase". The system is then carefully coded to only require Driver so > people can write fully custom implementations, but DriverBase is available > as a starting point. > > I understand the reasoning behind names like IDriver and CDriver, but I > always need the docs around when I code, so I've never found that trick > useful. > > -Bill Zwicky > ------------------------------------------------------------------------------ > Why Cloud-Based Security and Archiving Make Sense > Osterman Research conducted this study that outlines how and why cloud > computing security and archiving is rapidly being adopted across the IT > space for its ease of implementation, lower cost, and increased > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: frankster <jsy...@te...> - 2011-09-09 14:07:04
|
Its funny you should say this because I was talking to my friend last week, and he was saying that maven now is what ant was 10 years ago. i.e. 10 years ago ant was the standard build system, but these days maven is. In the longer run it could be interesting to look into the benefits that maven would provide over ant (or even make). cheers, Frankie On 09/09/11 10:14, denis queffeulou wrote: > I don't read all the mails, but have you think of using Maven to build > modules (libraries) instead of having one big build project ? > Maybe you could have one project for the core, one for the synthdrivers etc. > > Just a suggestion as maven is used all the time in java projects. It > helps to separate code entities and reuse them with the dependancies system. > > -- > Denis > >> My first suggestion is to move all source code into /src. Optionally, >> synthdrivers can be move to /src-synthdrivers or just /synthdrivers in >> preparation for the plugin framework. Synths should be repackaged as well, >> so the final directory will actually be >> /synthdrivers/org/jsynthlib/synthdrivers/*. >> >> On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker<jo...@em...> wrote: >> >>> 1 - When I move all of the stuff from "core" into "org.jsynthlib", how >>> should it be organized? I'm planning all of the "*ConfigPanel" stuff >>> moving into org.jsynthlib.config, and probably all of "*Widget" going >>> into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably >>> going into org.jsynthlib.utils. There's a lot more stuff, however, that >>> needs a home. Any suggestions for further categorization are welcome. >>> I'm thinking that we might also want a dedicated package for the classes >>> which the synthdrivers use for superclasses (ie, PatchEditorFrame, >>> LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers >>> which were subclassing some fairly strange frames... possibly because >>> they were the first ones that they came across which seemed like they'd >>> work or something. >>> >> These are all excellent ideas. I might suggest an 'app' package for the >> main JSynthLib app, windows, menus, etc. >> >> 2 - Some of the classes have their *type* implied in the name. For >>> example, there's an abstract class called "AbstractLibraryFrame" and >>> there are some interfaces called "IDriver" and "IBankPatch". These >>> aren't really the way the base Java libraries do it and, personally, I >>> find it confusing (I keep asking myself "What the heck is an 'abstract >>> library'?"). My preference would be to rename AbstractLibraryFrame to >>> just LibraryFrame, and IDriver to just Driver, etc. Any objections? >>> >> I agree. I myself favor systems like "interface Driver" and "abstract class >> DriverBase". The system is then carefully coded to only require Driver so >> people can write fully custom implementations, but DriverBase is available >> as a starting point. >> >> I understand the reasoning behind names like IDriver and CDriver, but I >> always need the docs around when I code, so I've never found that trick >> useful. >> >> -Bill Zwicky >> ------------------------------------------------------------------------------ >> Why Cloud-Based Security and Archiving Make Sense >> Osterman Research conducted this study that outlines how and why cloud >> computing security and archiving is rapidly being adopted across the IT >> space for its ease of implementation, lower cost, and increased >> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >> > > ------------------------------------------------------------------------------ > Why Cloud-Based Security and Archiving Make Sense > Osterman Research conducted this study that outlines how and why cloud > computing security and archiving is rapidly being adopted across the IT > space for its ease of implementation, lower cost, and increased > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Roger W. <ro...@us...> - 2011-09-12 13:01:19
|
My suggestion is to use a Maven style directory structure. (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) src/main/java src/main/recources src/test/java (we do test, do we?) src/test/recources and so on. That will also separate production code from tests and such. I am not sure that Maven is the way to go for JSynthLib. I have been using Maven in my work for the last couple of years and I have seen Maven being bent over backwards to build a system. It is not a pretty sight. I think nothing beats Maven when it comes to dependency management and modularization but it is too easy to misuse Maven. I would rather look for something like Gradle (http://www.gradle.org/) when it comes to replacing Ant. I have not used it myself but I have hear people saying good things about it (people smarter than me so I trust them). And then we have Subversion... :-) Having used it in a setting where branching and merging is a daily activity, I know how Subversion performs. You don't really want to merge with Subversion. You do not really want to move files when you use branching and merging. And definitely not move files and edit in branches. I would rather try something like Git which was built for merging. I am so happy to see that this project has woken up again and I too started refactoring the application many years ago but the work was too overwhelming. I don't know how much time I can spend on this project but I will try to follow the development and inject my development experience whenever I can. Regards, Roger 2011/9/9 William Zwicky <wrz...@po...>: > My first suggestion is to move all source code into /src. Optionally, > synthdrivers can be move to /src-synthdrivers or just /synthdrivers in > preparation for the plugin framework. Synths should be repackaged as well, > so the final directory will actually be > /synthdrivers/org/jsynthlib/synthdrivers/*. > > On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker <jo...@em...> wrote: > >> >> 1 - When I move all of the stuff from "core" into "org.jsynthlib", how >> should it be organized? I'm planning all of the "*ConfigPanel" stuff >> moving into org.jsynthlib.config, and probably all of "*Widget" going >> into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably >> going into org.jsynthlib.utils. There's a lot more stuff, however, that >> needs a home. Any suggestions for further categorization are welcome. >> I'm thinking that we might also want a dedicated package for the classes >> which the synthdrivers use for superclasses (ie, PatchEditorFrame, >> LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers >> which were subclassing some fairly strange frames... possibly because >> they were the first ones that they came across which seemed like they'd >> work or something. >> > > These are all excellent ideas. I might suggest an 'app' package for the > main JSynthLib app, windows, menus, etc. > > 2 - Some of the classes have their *type* implied in the name. For >> example, there's an abstract class called "AbstractLibraryFrame" and >> there are some interfaces called "IDriver" and "IBankPatch". These >> aren't really the way the base Java libraries do it and, personally, I >> find it confusing (I keep asking myself "What the heck is an 'abstract >> library'?"). My preference would be to rename AbstractLibraryFrame to >> just LibraryFrame, and IDriver to just Driver, etc. Any objections? >> > > I agree. I myself favor systems like "interface Driver" and "abstract class > DriverBase". The system is then carefully coded to only require Driver so > people can write fully custom implementations, but DriverBase is available > as a starting point. > > I understand the reasoning behind names like IDriver and CDriver, but I > always need the docs around when I code, so I've never found that trick > useful. > > -Bill Zwicky > ------------------------------------------------------------------------------ > Why Cloud-Based Security and Archiving Make Sense > Osterman Research conducted this study that outlines how and why cloud > computing security and archiving is rapidly being adopted across the IT > space for its ease of implementation, lower cost, and increased > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Frankie F. <jsy...@te...> - 2011-09-12 13:33:58
|
On 12/09/2011 14:01, Roger Westerlund wrote: > > I am not sure that Maven is the way to go for JSynthLib. I have been > using Maven in my work for the last couple of years and I have seen > Maven being bent over backwards to build a system. It is not a pretty > sight. I think nothing beats Maven when it comes to dependency > management and modularization but it is too easy to misuse Maven. I > would rather look for something like Gradle (http://www.gradle.org/) > when it comes to replacing Ant. I have not used it myself but I have > hear people saying good things about it (people smarter than me so I > trust them). Interesting, I'm only familiar with ant - what are the problems with ant? > > And then we have Subversion... :-) Having used it in a setting where > branching and merging is a daily activity, I know how Subversion > performs. You don't really want to merge with Subversion. You do not > really want to move files when you use branching and merging. And > definitely not move files and edit in branches. I would rather try > something like Git which was built for merging. > I would be very happy to use git or mercurial instead of svn. frankie |
|
From: Roger W. <ro...@us...> - 2011-09-12 14:33:54
|
2011/9/12 Frankie Fisher <jsy...@te...>: > On 12/09/2011 14:01, Roger Westerlund wrote: >> >> I am not sure that Maven is the way to go for JSynthLib. I have been >> using Maven in my work for the last couple of years and I have seen >> Maven being bent over backwards to build a system. It is not a pretty >> sight. I think nothing beats Maven when it comes to dependency >> management and modularization but it is too easy to misuse Maven. I >> would rather look for something like Gradle (http://www.gradle.org/) >> when it comes to replacing Ant. I have not used it myself but I have >> hear people saying good things about it (people smarter than me so I >> trust them). > > Interesting, I'm only familiar with ant - what are the problems with ant? For starters, it uses XML as it's "language" and XML was made for machines to read so it is not the most human readable format available (imho). Have a look at Gant (http://gant.codehaus.org/) which is based on Ant to see the difference. Ant scripts tends to grow wildly and if you don't fully understand Ant then it is easy to start mixing target dependencies with antcalls and then you have a problem. You also have to do some backwards thinking to use conditional triggering of targets. Something that is so easy to do in a programming language with an if statement becomes really awkward in Ant. Also if you have a modularized application, which I would say that JSynthLib should be, then the Ant build scripts you would need to maintain would be quite some work. I still think that Ant is a good tool if used properly but the XML drags it down. Regards, Roger |
|
From: Joe E. <jo...@em...> - 2011-09-12 16:50:35
|
On 9/12/2011 6:01 AM, Roger Westerlund wrote: > My suggestion is to use a Maven style directory structure. > (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) > > src/main/java > src/main/recources > src/test/java (we do test, do we?) > src/test/recources Well, that's a little bit of a project-management directory structure. I'm not opposed to adding this, but I was mostly asking about the *package* structure of the java code (ie, how we're going to distribute files under the src/main/java folder) - Joe |
|
From: Roger W. <ro...@us...> - 2011-09-13 11:19:17
|
2011/9/12 Joe Emenaker <jo...@em...>: > On 9/12/2011 6:01 AM, Roger Westerlund wrote: >> My suggestion is to use a Maven style directory structure. >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) >> >> src/main/java >> src/main/recources >> src/test/java (we do test, do we?) >> src/test/recources > > Well, that's a little bit of a project-management directory structure. > I'm not opposed to adding this, but I was mostly asking about the > *package* structure of the java code (ie, how we're going to distribute > files under the src/main/java folder) I think both are equally important, project structure is easier, though, since you only have to set it once (normally). Package structure has to evolve as you go. I don't have a fresh view of the package tree but I recall that there was a monster package with too much different functionality combined. Packages should be quite small and focused on a limited functionality. I wish I had the time to dive into the code and have some ideas regarding this but right now is not the time for me. Regards, Roger |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X