Re: [Jsynthlib-devel] Two refactoring questions

[Roger W. <ro...@us...>]

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
>