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<[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 > ------------------------------------------------------------------------------ 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
