John,

Great to see this CDK mavenizing effort.

One question - will all packages be available as maven modules, or only the "super modules" ?

Nina


On 20 January 2014 15:11, John May <john.wilkinsonmay@gmail.com> wrote:
Thank you both for the feedback it’s good to see what perhaps should and shouldn’t go together. 

I think the prediction module could be better described as qsar (with the renaming of the current qsar module) or else descriptors, since the module doesn't actually have code that makes predictions. In fact, I think it would even be OK if the descriptors were placed in the tools module

Yep that was the one i liked the least. With the qsars in tools that’s quite a large collection of disparate functionality. Actually as the descriptors could go in tools - maybe it makes more sense to have a descriptors modules that includes non-qsar descriptors (see below).

 * tool - yes. Does 'cip' really not go in base? I think 'isomorphism'
should be, although I appreciate that it might be superseded by SMSD?
Talking of which, I agree with Rajarshi that SMSD belongs in tools.
There are several packages and classes in there that could usefully be
moved to other places.

Out of interest why would you put CIP in base? I would say it’s a stereo-descriptor, that’s only useful for labelling absolute centres (not that useful). Also yes isomorphism should probably go in base and I've moved that.

* display - can't 'control' be in display? I know controlling is not
displaying, but..

So yeah it is mainly used by JChemPaint and Bioclipse when displaying structures but I’m not sure it fits in with the renderers. Would need to think more about that - CDK-JChemPaint adds a lot of classes to the module that might make it clearer where it should live.

With regards to the 'qm' module, that looks like a
partially-implemented effort. The renderer seems like something for
rendering orbitals or something.
The qm.math stuff could be packaged with 'group' ? Perhaps a module
(not a super-module) called 'math’.

That’s a possibility - we can do merges once all is in place. I think it might be better just to deprecate the code though - leaving it still in place for people to use but indicating this isn’t (and most likely won’t be) completed.

Oh, and for that matter -
shouldn't signatures be with inchi and smiles?

Are you able read signatures back as an AtomContainer? I would have thought these are more similar to hose codes that describe  (i.e. descriptors) the environment of each atom?

Here’s an updated hierarchy with a 'descriptors' module.  Not sure about ionpot and charges - ionpot is only used by qsarionpot and charges by qsarmolecular, ionpot and forcefield. Let me know how this feels:

base
annotation
atomtype
core
data
silent
datadebug
isomorphism
dict
interfaces
reaction
standard
valencycheck
tool - that manipulate intrinsic properties and asking questions about structures
builder3d
builder3dtools
forcefield
formula
fragment
group
hash - aux property but used for testing identity rather than describing something
pcore
sdg
smarts
smsd
structgen
tautomer

descriptors - that compute auxiliary attributes to be used for building models and screening 
fingerprint
ionpot - hmm.. there are already ion pot and charge qsar descriptors, these are kind of intrinsic but kind of only used in the qsars..?
charges 
  cip
signature
qsar
qsaratomic
qsarbond
qsarcml
qsarionpot
qsarmolecular
qsarprotein

storage 
io
ioformats
iordf
libiocml
libiomd
pdb
pdbcml
inchi
smiles

display
render
renderawt
renderbasic
renderextra

deprecated - old code that is not used in the library but is required for backwards compatibility, only included in downstream projects when needed

miscellaneous 
control
extra  
diff   
log4j  
qm     

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Cdk-devel mailing list
Cdk-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdk-devel