Re: [Jsynthlib-devel] Two refactoring questions

[denis q. <dqu...@fr...>]

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
>