No problem, 

Once deps are downloaded once you can use -o for offline mode.

Yes we have started ignoring some tests, the trouble is some of current failures are fixable and would be good to fix. I think mostly it's things I can't resolve though.

Sent from my iPhone

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


On Feb 22, 2014, at 4:37 PM, John May <john.wilkinsonmay@gmail.com> wrote:

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>.

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


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.

Ok, that’s fine then. What I really hate is when maven starts downloading all sorts of stuff I’ve never heard of that don’t seem to be needed. If these really are dependencies of the project, then so be it! And I think it’s definitely better to get things like beam from a suitable maven repo than to bundle a .jar in the git repo (even if I have gripes with maven, it’s better than that! :) ).

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.

Hmm… interesting. I wonder if my project can start explicitly using the smaller cdk jars rather than just depending on the whole shebang. Definitely worth considering.

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.

Ok, it would be nice if these test were disable though. I see no problem using the source code as a place to store feature requests, but we shouldn’t report a failing test because of that!

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

hrm… isn’t maven supposed to pick this stuff up for me automagically?

mvn -DskipTests=true install

You could also ignore failures.

That’s the theory, yes. :)

Thank you for all your hard work on this! I don’t mean to come across as overly negative as clearly something like this needed to happen, but every time I find myself dealing with maven my blood pressure rises… Hopefully I can get things back to a working state quickly.

Cyrus

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

------------------------------------------------------------------------------
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