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 <[email protected]>: > 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 <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Jsynthlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
