Hi Cyrus,

Yes a necessary evil - I actually agree with you on all points but I would not point all the blame on maven here.

1. those dependancies were always there, none have been added. In fact I have even managed to eliminated some in cdk-base as we now have tooling that can understand what code belong in each module.

The ones you havenít heard of are test deps (previously in develjar), they are tagged as such in maven <scope>test</scope>.

old develjar https://github.com/cdk/cdk/tree/13c5dc2f369399e67ca53424470bfea9f1cc4dd8/develjar

commons-math is non-test but was also always there

old jar https://github.com/cdk/cdk/tree/13c5dc2f369399e67ca53424470bfea9f1cc4dd8/jar

One difference is that dependencies are now inherited. As an example if you add a dependencies on cdk-smiles - the required beam dependency needs to be included. Previously this had to be explicitly declared in the downstream model when really itís just an implementation detail.

2. Yes, but you should not need to change between modules often. If you find that is the case it is usually an indication that the boundary was poorly defined and two modules maybe should be one. The point of the separate source tree is they should group functionality and work in isolation. You now only need to rebuild the module you change. I donít care how cdk-io reads a molfile or cdk-smiles reads SMILES as long as it gives something back. I see it is a pain on the command line but at nearly 9000 files we really needed the structuring. 

3. Again yes, maven makes the reasonable assumption that if you have test failures something has broken. Unfortunately CDK tests have previously be used in place of feature requests as a Ďwill add laterí that of course never does. Iíve lost count but I believe itís approaching nearly 250 tests Iíve managed to fix in the last year. The remaining 26/28 failures (report) are either tests which were not resolved adequately (rejected at review) or feature requests. There are quite a few failures to do with mmff94 params and forcefields, having attempted to resolve them I donít believe it would be a great lost in simple deleting all of that code.

Actually, ZMatrixToolsTest should not fail indicating there is something broken in your build (most likely your vecmath dependency).

mvn -DskipTests=true install

You could also ignore failures.

Thanks,
John

On 22 Feb 2014, at 19:05, Cyrus Harmon <ch-cdk@bobobeach.com> wrote:


Well, maven may be a necessary evil in the java world, so perhaps I should just quietly accept the fact that this is the future of CDK development. Iím not really against this change, but I do feel I have a couple of gripes I need to get off of my chest.

1. WTF is up with all of the maven dependencies? What is hamcrest? mockito? euclid? commons-math? Do I really need all of this stuff to build the CDK? When dependencies were a pain in the ass, the were few and far between. Now that maven makes them easy, they seem to propagate exponentially and, to my eye, needlessly, but what do I knowÖ

2. Iím not a big fan of the partitioned source code model. I understand that there are GUIs (eclipse, e.g.) to help manage this, but if I want to go old-sk00l and use the shell, grep, cat, etcÖ to inspect the code, from, say, cdk/base/core/src/main/java/org/openscience/cdk/atomtype/ I have to backup 9 directories, then go down another 9 directories to get to interface. Do we really need a path 16 nodes long separating these two modules? I suppose this is really just a gripe about java.and.its.stupid.mapping.between.packages.and.directories and I should just accept this one too. Iím used to having my my source files at the top level of my project, or in src, or <module>, or src/<module>, or maybe src/<module>/<submodule> if you really want to get fancy and this all seems a bit crazy to me.

3. building mvn package fails for me:

A. ZMatrixToolsTest:

Running org.openscience.cdk.geometry.ZMatrixToolsTest
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.105 sec <<< FAILURE! - in org.openscience.cdk.geometry.ZMatrixToolsTest
testZmatrixToCartesian_arraydouble_arrayint_arraydouble_arrayint_arraydouble_arrayint(org.openscience.cdk.geometry.ZMatrixToolsTest)  Time elapsed: 0.044 sec  <<< FAILURE!
java.lang.AssertionError: expected:<-1.3664> but was:<-1.5854917504348642>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:494)
at org.junit.Assert.assertEquals(Assert.java:592)
at org.openscience.cdk.geometry.ZMatrixToolsTest.testZmatrixToCartesian_arraydouble_arrayint_arraydouble_arrayint_arraydouble_arrayint(ZMatrixToolsTest.java:45)


B. JMolTest

Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.369 sec <<< FAILURE! - in org.openscience.cdk.io.cml.JmolTest
testAnimation(org.openscience.cdk.io.cml.JmolTest)  Time elapsed: 0.113 sec  <<< FAILURE!
java.lang.AssertionError: expected:<34> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at org.openscience.cdk.io.cml.JmolTest.testAnimation(JmolTest.java:115)



C. RGroupQueryReaderTest

Tests run: 23, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 14.786 sec <<< FAILURE! - in org.openscience.cdk.io.RGroupQueryReaderTest
testRgroupQueryFile5(org.openscience.cdk.io.RGroupQueryReaderTest)  Time elapsed: 14.755 sec  <<< ERROR!
java.lang.OutOfMemoryError: Java heap space
at java.util.LinkedHashMap.createEntry(LinkedHashMap.java:424)
at java.util.LinkedHashMap.addEntry(LinkedHashMap.java:406)
at java.util.HashMap.put(HashMap.java:385)
at org.openscience.cdk.ChemObject.setProperty(ChemObject.java:241)
at org.openscience.cdk.isomorphism.matchers.RGroupQuery.findConfigurationsRecursively(RGroupQuery.java:347)
at org.openscience.cdk.isomorphism.matchers.RGroupQuery.findConfigurationsRecursively(RGroupQuery.java:418)
at org.openscience.cdk.isomorphism.matchers.RGroupQuery.findConfigurationsRecursively(RGroupQuery.java:418)
at org.openscience.cdk.isomorphism.matchers.RGroupQuery.findConfigurationsRecursively(RGroupQuery.java:418)
at org.openscience.cdk.isomorphism.matchers.RGroupQuery.findConfigurationsRecursively(RGroupQuery.java:418)
at org.openscience.cdk.isomorphism.matchers.RGroupQuery.getAllConfigurations(RGroupQuery.java:247)
at org.openscience.cdk.io.RGroupQueryReaderTest.testRgroupQueryFile5(RGroupQueryReaderTest.java:352)


Other than those gripes, this is a great idea! :)

thanks,

Cyrus

On Feb 20, 2014, at 2:27 AM, John May <johnmay@ebi.ac.uk> wrote:

Hi all,

As you may have seen the CDK is now built with maven. Iíve written a blog post with a few more details here and what changes: http://efficientbits.blogspot.co.uk/2014/02/cdk-now-built-using-maven.html.

Thanks,
John
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
Cdk-devel mailing list
Cdk-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdk-devel

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
Cdk-devel mailing list
Cdk-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdk-devel