[MOBY-dev] Code updates in jMOBY

[Paul Gordon]

Hi Martin,
>> By package creep, I mean that in order to compile core MOBY classes into 
>> my non-MOBY cvs projects, I don't want to have to include lots of extra 
>> jars (I'm writing applets, which have severe memory restrictions).  For 
>> example, I moved JDOM specific code from Utils to JDOMUtils, and changed 
>> all references to those methods (very few actually) in CVS.
>>
>>     
>    Paul, you did changes that you do not know about consequences. For
> example changes in packages affect the number of jar files that are to be
> deployed to the Tomcat. But you have not changed this in build.xml files.
>   
There may be some confusion: I did not remove or add any packages, I 
simply moved code (4 methods) to a new class org.biomoby.shared.parser 
JDOMUtils.  For example, this cleaned org.biomoby.shared.data of the 
JDOM dependency you introduced in MobyProvisionInfo.  None of these 
changes involved the subpackages dashboard, rdf, registry or ui, so I 
don't think any changes to build.xml need to be made.

>> The functionality should not really be affected, if it is, let me
>> know.  For example the formatFault you mentioned is replaced by 3
>> lines that do essentially the same thing.
>>
>>     
>    Yes, now it is 3 lines of code but they are well separated and can be
> extended later for more sophisticated code. I would like to have them
> back please.
>   
I guess this becomes a philosophical question for the project as whole.  
Do you want to force anyone who want to use MOBY in their Java own 
program to bundle all of JAR files in lib with them in their deployments 
(e.g. otherwise I need know that I must have alltools2.jar in my 
classpath to use CentralImpl)?  I am coming at this (as you've asked me 
before) from the perspective of someone not using jMOBY as their primary 
CVS tree but rather as a library to use.  I carefully selected just a 
few parts (less than a dozen classes) to remove some small library 
dependencies from so that Seahawk (~2.7MB total) doesn't need to import 
a lot of external code to compile and run.

Please note, I have not touched the dashboard, datatype, rdf, registry, 
ui, and not even most of the classes in shared. There is really just a 
core set of common classes I'd like to keep clean, and hopefully others 
will too, under org/biomoby:

./client/CentralCachedCallsImpl.java
./client/CentralImpl.java
./client/rdf/vocabulary/DC_PROTEGE.java
./client/rdf/vocabulary/FetaVocabulary.java
./client/rdf/vocabulary/MobyResources.java
./client/rdf/vocabulary/Predicates.java
./client/rdf/vocabulary/ServiceDescriptionPredicates.java
./client/rdf/vocabulary/XMLTypes.java
./shared/*.java
./shared/data/*.java
./shared/extended/DataTypeParser.java
./shared/extended/NamespaceParser.java
./shared/extended/ServiceInstanceParser.java
./shared/extended/ServiceTypeParser.java
./shared/parser/MobyTags.java
./shared/schema/MElement.java
./shared/schema/MElementHashtable.java
./shared/schema/PrimitiveVector.java
./shared/schema/RdfParser.java
>    I am now busy to finish other moby project (perl one) I am working on
> because I am leaving for a meeting soon. So I cannot look in details what
> you did - but I really ask you to re-consider your changes. I feel greatly
> disturbed now.
>   
Besides the 4 methods moved to JDOMUtils, there actually are few 
changes. There are less than 20 lines of code affected, all related to 
formatting utilities and empty string checks.  I did not touch anything 
with fundamental functionality.  I don't think you need to be "greatly 
disturbed" :-)

Cool runnings,

Paul