Just one comment from my side, which may had been lost in previous threads.

The main reason of us compiling JCP and providing it via the maven repository http://ambit.uni-plovdiv.bg:8083/nexus/index.html#nexus-search;quick~jchempaint was to have a JCP version, which DOES not include CDK classes.  These are jchempaint-nodeps artifacts


The reason is if JCP is embedded in applications, which already use a different CDK version as a dependency, or insist of using different CDK version than one distributed with JCP, it results in duplication of classes with same names and in the worst case different implementations, and which one would be loaded by Java classloader is chosen at random!  

This is a major trouble, errors hard to track, crashes, etc.  I understand that the original use case for JCP is a standalone application or applet, but as seen on this list, it is being embedded in other applications as well.  The only clean way would be to finally arrive at JCP using the CDK jars as external jars, much same as let's say XML or logging libraries. Until then we'll continue to try to compile JCP with the latest CDK and provide maven artifact without embedding JCP as dependencies.



On 29 May 2012 21:15, <ralf@ark.in-berlin.de> wrote:
On Tue, May 29, 2012 at 12:10:16AM +0200, Egon Willighagen wrote:
> Please make sure they do not exist in the CDK-JChemPaint patch!

About all those patches. I have started a wiki page.

Please contribute whenever you have time.

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Cdk-devel mailing list