[MOBY-dev] Java packages conversation

[Paul Gordon]

Hi Eddie,

    A couple of thoughts:

-What about the data templates and instances?  Is org.biomoby.shared 
going away?  Should there be a org.biomoby.data instead?

-Where should server side or combines server/client objects (e.g. 
MobyRequest) go?

>Hi,
>
>Martin & I thought that our conversation might interest
>others in the list, so here it is:
>
>------------Eddie-------------------
>
>Hi,
>
>I have been trying to think of a package hierarchy that
>would be useful for jMoby now and in the future. I have come
>up with the following draft, and was hoping for criticism.
>
>Below you will find the package structure I think might
>work:
>
>#######################
>org.biomoby.central.
>	registry.
>		retrieval.
>		_to_be_named_later.
>			register
>			deregister
>	client.
>		perlConverts.
>		execution.
>			invocation
>		ui.
>			commandline.
>			graphical.
>				swing
>				applets
>				servlets.
>					lsid
>					jResource
>				plugins.
>					taverna
>		dom.
>	testing.
>###########################
>
>Anything that you think is missing? I hope to be able to
>slot the current classes into these packages a little at a
>time.
>
>In the package perlConverts I was hoping to slot in java
>versions of Perl scripts that have been already created,
>like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
>cgi-bin/types/Namespaces.
>
>In the package dom, I thought that people may be comfortable
>with a particular version of dom (w3c.dom, jDom, etc) and so
>I thought it might be nice to separate implementations.
>
>I think that the rest of the hierarchy is pretty straight
>forward and doesn't need explanation, although I could be
>wrong. 
>
>Also, I do not have as much knowledge about Moby as many of
>you do and I may have missed some obvious things, so please
>let me know.
>
>Thanks,
>
>Eddie Kawas
>
>------------Martin----------------
>
>   Thanks for the overview.
>   I have just a few questions:
>
>   1) Does the new proposal require changes in the current
>(existing) packages? If yes, in which?
>
>   2) Are you going to create package 'slots' now - and only
>later to populate them, or are you proposing to create them
>only when you have something to be there?
>
>   3) perlConverts: I do not feel comfortable with this
>name. Do users need to know (from the package name) the
>reason why a package was created?
>I think that better is to name a package by its
>functionality, not by the origin. But again, I would perhaps
>let people to create their package names in a less
>structured (less detailed) way than you are proposing (which
>I will explain when I have answers for the two previous
>questions)
>- so if somebody wants to keep te origin in the package
>name, I am not basically against it. Let's return to these
>comments later.
>
>   4)
>  
>
>>In the package dom, I thought that people may be
>>    
>>
>comfortable with a 
>  
>
>>particular version of dom (w3c.dom, jDom, etc) and so I
>>    
>>
>thought it 
>  
>
>>might be nice to separate implementations.
>>
>>    
>>
>   Again, I think that this details should be (if one wants
>to have several separate implementations) *below* package
>where a dom is used. You ut it under 'client' - but what if
>I need to use a dom in a class belonging to a registry
>package, or to a commandLine package? The 'dom' 
>name should be there - in more than one place.
>
>  
>
>>I think that the rest of the hierarchy is pretty straight
>>    
>>
>forward and 
>  
>
>>doesn't need explanation, although I could be wrong.
>>
>>    
>>
>   5)
>   Well, if you publish rules you need to explain them
>anyway. So why not to do it now :-) It would be good to have
>few lines defineg what should go into individual packages.
>
>   Cheers,
>   Martin
>
>-------------Eddie--------------
>
>  
>
>>   1) Does the new proposal require changes in the current
>>(existing)
>>packages? If yes, in which?
>>    
>>
>Yes, however, I am not sure which classes will be moved
>where. I tried to see what classes we had and then I tried
>to create a slot that it might fit into.
>
>
>  
>
>>   2) Are you going to create package 'slots' now - and
>>    
>>
>only later to 
>  
>
>>populate them, or are you proposing to create them only
>>    
>>
>when you have 
>  
>
>>something to be there?
>>    
>>
>I was thinking of creating them now. Is this a bad idea?
>
>
>  
>
>>   3) perlConverts: I do not feel comfortable with this
>>    
>>
>name.
>I agree. I think I did that out of sheer laziness.
>
>
>  
>
>>   4)
>>    
>>
>>>In the package dom ...
>>>      
>>>
>You are right, this should be below a package when DOM is
>used, not in client.
>
>Thanks,
>
>Eddie
>
>
>------------Martin----------------
>
>  
>
>>>   1) Does the new proposal require changes in the
>>>      
>>>
>current
>  
>
>>>(existing)
>>>packages? If yes, in which?
>>>      
>>>
>>Yes, however, I am not sure which classes will be moved
>>    
>>
>where.
>  
>
>   Well, I am reluctant to make these changes - at least in
>the code written (mainly) by me - unless there is a good
>reason for that. Changes in package names (in existing code)
>are evil - if the code is already used by others. Sorry for
>that...
>
>  
>
>>>   2) Are you going to create package 'slots' now - and
>>>      
>>>
>only later 
>  
>
>>>to populate them, or are you proposing to create them
>>>      
>>>
>only when you 
>  
>
>>>have something to be there?
>>>      
>>>
>>I was thinking of creating them now. Is this a bad idea?
>>
>>    
>>
>   I always liked such idea - but (in my experiences) it
>simply never worked (unless you are in a strict industrial
>environment). Therefore, I suggest to live with a compromise
>- to "dictate" only relatively high-level package names, and
>let people to create their own below.  
>Therefore, I have started only with
>org.biomoby.[client|shared|registry] - and we need possibly
>something for support for service providers (I am using now
>org.biomoby.service - but there are only some testing
>classes now).
>   Having said that, I think it is a good idea to write a
>document - and to publish it on the jMoby pages - that would
>suggest what package names (below the ones I mentioned
>above) could be used for specific purposes.  
>But not to create them in advance, and not to enforce it
>later. Just like hints. As always with hints, people will
>follow them if the hints are well explained and known to
>people.
>
>   Let me know if you are uncomfortable with the high-level
>package names as they exist now - and let's discuss what to
>do with them. BTW, your
>proposal:
>
>org.biomoby.central.
>        registry.
>                retrieval.
>                _to_be_named_later.
>                        register
>                        deregister
>
>cannot work easily. Simply because it is too detailed. There
>may be classes (such as CentralImpl) that work cross the
>packages you defined. 
>No, I would definitely keep this part simpler - just
>org.biomoby.registry. 
>(But this was just an example, let's discuss it.)
>
>   Cheers,
>   Martin
>
>--------------Eddie---------------
>
>So you don't think that we should try and create a more
>detailed hierarchy. I thought that one would be nice,
>because we were stumbling upon users that had created almost
>duplicate code to that which was in jMoby. Ultimately, I was
>hoping to reduce code duplication in order to get people
>more on their way to doing useful things.
>
>I realize that changing package names is going to be messy,
>so we were proposing to do it slowly, maybe a package at a
>time with advance warnings. We could have even tried
>automating it with scripts that contain the mappings of
>where current classes are and where they would be after the
>'refactor'-ing.
>
>What do you think?
>
>Eddie
>
>PS: I am all for creating a document that outlines what
>should be placed where, etc.
>
>------------Martin----------------
>
>  
>
>>I thought that one would be nice, because we were
>>    
>>
>stumbling upon users 
>  
>
>>that had created almost duplicate code to that which was
>>    
>>
>in jMoby.
>  
>
>   This is obviously bad and we should perhaps contact these
>people and try to convince them to re-use existing code (I
>am working now, for example, with Sophie Durand
><sophie.durand at infobiogen.fr> to convince her to re-use some
>exiting code for her classes). But I believe that changing
>package names will not help to achieve it. We need different
>ways to convince them.
>
>  
>
>>We could have even tried automating it with scripts that
>>    
>>
>contain the 
>  
>
>>mappings of where current classes are and where they would
>>    
>>
>be after 
>  
>
>>the 'refactor'-ing.
>>
>>    
>>
>   I agree that it would be useful to provide a refactoring
>tool - if we need to refactor. But, as I said, I do not
>think that refactoring will help us now.
> 
>   Sorry for not agreeing with you on the package name
>changes. But I still believe that providing hints how to
>name their code would be very helpful.
>
>   Martin
>
>PS. Btw, feel free to reproduce our conversation on the
>biomoby-dev list if you wish. M.
>
>--
>Martin Senger
>
>-----------Eddie-------------
>
>Thanks for your comments, I think that I should rethink this
>whole issue and then get back to you.
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>  
>