[MOBY-dev] Java packages conversation

[Eddie Kawas]

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