The Chemistry Development Kit

Dear Tomáš,

On Sun, May 20, 2012 at 7:06 AM, Tomas Pluskal <pluskal@...> wrote:
> That said, I would also like to share some hurdles we have experienced
> with embedding your projects into MZmine and perhaps make a few
> suggestions how to improve it.

Please do. As must be clear, the CDK project does not receive direct funding
(yet) for development, which means that all developed is primarily
triggered by specific needs by people using the CDK, rather than user
needs... I say primarily, because user support is in fact what the
community does get to too...

> First, the hurdles. It's basically two issues.
>
> 1) We use maven to build MZmine. According to your website
> (http://sourceforge.net/apps/mediawiki/cdk/index.php?title=Maven_repositories),
> there are two maven repositories holding CDK. Unfortunately, the
> Cambridge repository only contains CDK 1.4.7 and no JChemPaint
> release.

Yeah, I am looking into in installing Jenkins here in Maastricht, but
no one in the group has time at right this moment (education, etc)...
we actually have an open vacancy for a good/eager sysadmin :)

> The Ambit repository is down at the moment.

I asked Nina... it is confirmed; problems with a faulty network
configuration... it is being looked into.

> The last time it
> was online, I saw it contained JChemPaint 3.3.0, while the official
> download page for JChemPaint
> (http://sourceforge.net/projects/cdk/files/JChemPaint/) has the latest
> version of 3.2.0. Is 3.3.0 an official release? The versioning seems a
> bit unclear.

I am not sure about that. That is a question that Christoph should
answer...

> 2) It is quite hard to find where the source code comes from. The
> SourceForge's CDK project has both SVN and git repositories. These
> contain some duplicate content.

Indeed. We do not like deleting history, but git is the main
repository. The SourceForge and GitHub git repositories are mirrored,
with GitHub being the more up to date one (patches go there first).

> It is unclear where the code for a
> particular version of CDK comes from,

They all come from the git repository. There are two branches of
interest: cdk-1.4.x and master.

> and it is even more unclear in
> the case of JChemPaint, because it requires a patched version of CDK
> (CDK-JChemPaint), which seems to have its own versioning.

Yes. The CDK-JChemPaint is the development project, and like a
development branch. It is versioned indeed.

> Last time I
> tried to to find what CDK version is embedded into JChemPaint 3.2.0, I
> failed (http://sourceforge.net/mailarchive/message.php?msg_id=28118123).

The JChemPaint applet is done by the EBI team, and I do not know such
things either, and do not currently have the time to personally
investigate it... I am happy enough to get my own CDK/CDK-JChemPaint
(current) work progressing... like cleaning up code to meet the
standards of the main CDK library...

> Speaking for people who embed CDK or JChemPaint into their
> applications like us, I think it would make our lives much easier if
> you/your team could implement a few changes:
>
> 1) Separate CDK and JChemPaint completely. Make CDK a library and
> JChemPaint an application that is using the library as a dependency.

That is in fact the case... but I also know the situation is complex.
That is historical.

> The CDK-JChemPaint patch should be integrated completely into
> JChemPaint code base, as - correct me if I am wrong - it contains
> mostly additional code to CDK.

It's more complicated... if you need both the JChemPaint
applet/application code and the latest CDK, your in an unlucky
situation...

The full story is a conflict of interest, causing a (temporary) fork almost two
years ago... they are not really compatible, but we haven't had the
resources yet to merge the forks again. I do not know if
Christoph has the resources to update the JChemPaint
applet/application right now... if there are others who like to help,
that is most welcome, and we should synchronize efforts...

> It seems that someone has already created a patch to separate the CDK
> and JChemPaint build
> (http://sourceforge.net/mailarchive/message.php?msg_id=28891512), so
> the issue is mostly about integrating this into the official tree.

I do not know the current state of the JChemPaint
applet/application... but I do know this:

there is the CDK library, and the CDK-JChemPaint patch... the latter I
maintain, and consists of code *extending* (not changing) the CDK
library... the major part of the rendering stack has now been cleared
and is part of CDK 1.4.10... I will very soon release a new
CDK-JChemPaint which will then only contain all the code for editing
and editing feedback...

The JChemPaint applet/application uses a forked code base of
CDK-JChemPaint (the rendering/controller stack), and is not
easily rebased on either of the above... instead, this will require to
look at individual patches and decide what to do with it: ignore or
(back)port.

> 2) Use only git (or only SVN) for the code trees of both CDK and

The CDK library only uses git at this moment.

> JChemPaint,

I have to check how JChemPaint is developed, but am not the maintainer
of that, and not the person to decide of git or svn should be used...

> and remove the obsolete code repositories,

That won't work, as there are older code (branches) that I do not want
to remove.

What I can do instead, is add files to mark where they should be
looking instead for more up to date code... would that help?
Additionally, we should update wiki pages more... but again, we're
very much resource constrained, and then bug fixing takes priority...

> because these tend to confuse people. Everyone is busy, and although I would like to
> occasionally submit a small patch/bugfix to CDK, the difficulty of
> finding the right source tree with the latest code base simply turns
> me off..

Understood. Sad story is that without a pile of money, the CDK project
cannot prioritize these things...

> 3) Publish new releases of both CDK and JChemPaint into the Maven OSS
> Central repository
> (https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide).
> This would make it much easier for everyone, as the Ambit repository
> has been turning offline and online in a nondeterministic manner over
> last few months..

I do not know how to do this. You're making many suggestions now
that I will not have time for, but others may. By discussing it on
this list, everyone can see what is to be done, and who is doing what
already. That way, small contributions are worthwhile.

> What do you think about this? I would be very happy to contribute some
> manpower to achieve these goals, if you decide to implement them.

I am sorry to inform you that it works the other way around: if you
contribute manpower, you are most welcome to implement your goals. All
comments touch on good points, but maintaining a project of this size
takes a lot of effort, and it cannot work other than people
contributing what they can... the current Maven support comes from
other volunteers, and I am sure if you talk to them you can come to a
mutual goal...

So, I am very happy with your interest!

Egon

PS. Nina told me she will as soon as possible upload 1.4.10 to the
Maven repository...

--
Dr E.L. Willighagen
Postdoctoral Researcher
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers

Dear Tomas,


On 21 May 2012 07:32, Egon Willighagen <egon.willighagen@...> wrote:

> Dear Tomáš,
>
> On Sun, May 20, 2012 at 7:06 AM, Tomas Pluskal <pluskal@...> wrote:
> > That said, I would also like to share some hurdles we have experienced
> > with embedding your projects into MZmine and perhaps make a few
> > suggestions how to improve it.
>
> Please do. As must be clear, the CDK project does not receive direct
> funding
> (yet) for development, which means that all developed is primarily
> triggered by specific needs by people using the CDK, rather than user
> needs... I say primarily, because user support is in fact what the
> community does get to too...
>
> > First, the hurdles. It's basically two issues.
> >
> > 1) We use maven to build MZmine. According to your website
> > (
> http://sourceforge.net/apps/mediawiki/cdk/index.php?title=Maven_repositories
> ),
> > there are two maven repositories holding CDK. Unfortunately, the
> > Cambridge repository only contains CDK 1.4.7 and no JChemPaint
> > release.
>
> Yeah, I am looking into in installing Jenkins here in Maastricht, but
> no one in the group has time at right this moment (education, etc)...
> we actually have an open vacancy for a good/eager sysadmin :)
>
> > The Ambit repository is down at the moment.
>
> I asked Nina... it is confirmed; problems with a faulty network
> configuration... it is being looked into.
>


Just to clarify, Ambit repository was down Sat night, 2012-05-19 18:00 CEST
until till 2012-05-20 8:30 CEST (Sunday), and is online since.  It was down
due to a network problem at the hosting university, but as it was weekend
night time in Europe, we didn't envisage major obstacles. I apologize for
the inconveniences in other parts of the world !

Let me know if you still have troubles accessing it.


> > The last time it
> > was online, I saw it contained JChemPaint 3.3.0, while the official
> > download page for JChemPaint
> > (http://sourceforge.net/projects/cdk/files/JChemPaint/) has the latest
> > version of 3.2.0. Is 3.3.0 an official release? The versioning seems a
> > bit unclear.
>
> I am not sure about that. That is a question that Christoph should
> answer...
>


The JChempaint maven artifact is compiled from the JChemPaint 3.3.0 trunk
against CDK 1.4.8 and CDK 1.4.9 . We provide three artifacts, JCP + CDK ,
JCP compiled against CDK 1.4.8 without CDK dependencies and  JCP compiled
against CDK 1.4.8 without CDK dependencies.
http://ambit.uni-plovdiv.bg:8083/nexus/index.html#nexus-search;quick~jchempaint


The JCP source was compiled as follows:

git clone git://github.com/cdk/cdk.git
cd cdk
git checkout -b cdk-1.4.5-copy cdk-1.4.5
git remote add ebicdk  http://www.ebi.ac.uk/steinbeck-srv/git/cdk
git fetch ebicdk
git log ebicdk/ebiPatches ^master
ant

wget http://cdk.svn.sourceforge.net/viewvc/cdk/jchempaint/?view=tar
mv index.html?view=tar jcp.tar.gz
gunzip < jcp.tar.gz | tar xvf -
cd jchempaint/trunk
cp ant.properties.template ant.properties
nano ant.properties (set cdk.dir=/home/vedrin/jcp/20120405/cdk)
nano build.xml (set <include name="org/openscience/jchempaint/**" /> for
target dist
ant


>
> > 2) It is quite hard to find where the source code comes from. The
> > SourceForge's CDK project has both SVN and git repositories. These
> > contain some duplicate content.
>
> Indeed. We do not like deleting history, but git is the main
> repository. The SourceForge and GitHub git repositories are mirrored,
> with GitHub being the more up to date one (patches go there first).
>

The CDK and CDK-JCP maven artifacts are created and deployed only for
releases, which are available for download at the sourceforge.net.  The
workflow is

1) download a release
2) compile by
ant
and
ant dist-pure
3) Use https://ambit.svn.sourceforge.net/svnroot/ambit/trunk/cdk-maven to
generate and deploy the artifacts.


>
> > It is unclear where the code for a
> > particular version of CDK comes from,
>
> They all come from the git repository. There are two branches of
> interest: cdk-1.4.x and master.
>
> > and it is even more unclear in
> > the case of JChemPaint, because it requires a patched version of CDK
> > (CDK-JChemPaint), which seems to have its own versioning.
>
> Yes. The CDK-JChemPaint is the development project, and like a
> development branch. It is versioned indeed.
>
> > Last time I
> > tried to to find what CDK version is embedded into JChemPaint 3.2.0, I
> > failed (http://sourceforge.net/mailarchive/message.php?msg_id=28118123).
>
> The JChemPaint applet is done by the EBI team, and I do not know such
> things either, and do not currently have the time to personally
> investigate it... I am happy enough to get my own CDK/CDK-JChemPaint
> (current) work progressing... like cleaning up code to meet the
> standards of the main CDK library...
>
> > Speaking for people who embed CDK or JChemPaint into their
> > applications like us, I think it would make our lives much easier if
> > you/your team could implement a few changes:
> >
> > 1) Separate CDK and JChemPaint completely. Make CDK a library and
> > JChemPaint an application that is using the library as a dependency.
>
> That is in fact the case... but I also know the situation is complex.
> That is historical.
>

The JChemPaint 3.3.0 artifacts are tested to work with CDK 1.4.8 and 1.4.9
(in fact we use and distribute them in our own software).


>
> > The CDK-JChemPaint patch should be integrated completely into
> > JChemPaint code base, as - correct me if I am wrong - it contains
> > mostly additional code to CDK.
>



> It's more complicated... if you need both the JChemPaint
> applet/application code and the latest CDK, your in an unlucky
> situation...
>


You could safely use cdk-jchempaint artifact 25
http://ambit.uni-plovdiv.bg:8083/nexus/index.html#nexus-search;quick~cdk-jchempaint

with cdk 1.4.8 and cdk 1.4.9, and cdk-jchempaint 18 with earlier cdk
artifacts.


> The full story is a conflict of interest, causing a (temporary) fork
> almost two
> years ago... they are not really compatible, but we haven't had the
> resources yet to merge the forks again. I do not know if
> Christoph has the resources to update the JChemPaint
> applet/application right now... if there are others who like to help,
> that is most welcome, and we should synchronize efforts...
>




>
> > It seems that someone has already created a patch to separate the CDK
> > and JChemPaint build
> > (http://sourceforge.net/mailarchive/message.php?msg_id=28891512), so
> > the issue is mostly about integrating this into the official tree.
>
> I do not know the current state of the JChemPaint
> applet/application... but I do know this:
>
> there is the CDK library, and the CDK-JChemPaint patch... the latter I
> maintain, and consists of code *extending* (not changing) the CDK
> library... the major part of the rendering stack has now been cleared
> and is part of CDK 1.4.10... I will very soon release a new
> CDK-JChemPaint which will then only contain all the code for editing
> and editing feedback...
>
> The JChemPaint applet/application uses a forked code base of
> CDK-JChemPaint (the rendering/controller stack), and is not
> easily rebased on either of the above... instead, this will require to
> look at individual patches and decide what to do with it: ignore or
> (back)port.
>

On the positive side,  the JChemPaint 3.3.0 trunk compiles with just few
warnings against CDK 1.4.8 and 1.4.9.
And this is what we already did, tested, and deployed as fully functional
JCP maven artifacts.
http://ambit.uni-plovdiv.bg:8083/nexus/index.html#nexus-search;quick~cdk-jchempaint

We'll be glad to provide further help.


>
> > 2) Use only git (or only SVN) for the code trees of both CDK and
>
> The CDK library only uses git at this moment.
>
> > JChemPaint,
>
> I have to check how JChemPaint is developed, but am not the maintainer
> of that, and not the person to decide of git or svn should be used...
>
> > and remove the obsolete code repositories,
>
> That won't work, as there are older code (branches) that I do not want
> to remove.
>
> What I can do instead, is add files to mark where they should be
> looking instead for more up to date code... would that help?
> Additionally, we should update wiki pages more... but again, we're
> very much resource constrained, and then bug fixing takes priority...
>
> > because these tend to confuse people. Everyone is busy, and although I
> would like to
> > occasionally submit a small patch/bugfix to CDK, the difficulty of
> > finding the right source tree with the latest code base simply turns
> > me off..
>
> Understood. Sad story is that without a pile of money, the CDK project
> cannot prioritize these things...
>
> > 3) Publish new releases of both CDK and JChemPaint into the Maven OSS
> > Central repository
> > (
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
> ).
> > This would make it much easier for everyone, as the Ambit repository
> > has been turning offline and online in a nondeterministic manner over
> > last few months..
>
> I do not know how to do this. You're making many suggestions now
> that I will not have time for, but others may. By discussing it on
> this list, everyone can see what is to be done, and who is doing what
> already. That way, small contributions are worthwhile.
>
> > What do you think about this? I would be very happy to contribute some
> > manpower to achieve these goals, if you decide to implement them.
>
> I am sorry to inform you that it works the other way around: if you
> contribute manpower, you are most welcome to implement your goals. All
> comments touch on good points, but maintaining a project of this size
> takes a lot of effort, and it cannot work other than people
> contributing what they can... the current Maven support comes from
> other volunteers, and I am sure if you talk to them you can come to a
> mutual goal...
>
>
I agree the overall setup of the CDK & JChemPaint is complicated, but we
hope the maven artifacts provide an easier way to use stable   releases. We
are discussing the possibility of maintaining snapshot releases of the
development branch as well.

I am glad the Maven repository is becoming an useful resource for the CDK
community.  I realise the information about how maven artifacts are
generated is missing (provided that CDK build is ant based), and we'll make
this information online shortly. Your feedback is very much appreciated!




> So, I am very happy with your interest!
>
> Egon
>
> PS. Nina told me she will as soon as possible upload 1.4.10 to the
> Maven repository...
>

Yes, it is ready for deployment, just needs to be completed with the
CDK-JCP release. Will be online by tomorrow.
We'll then try to compile JChemPaint trunk with 1.4.10. Help by JCP
developers is very much welcome!

Best regards,
Nina Jeliazkova


>
> --
> Dr E.L. Willighagen
> Postdoctoral Researcher
> Department of Bioinformatics - BiGCaT
> Maastricht University (http://www.bigcat.unimaas.nl/)
> Homepage: http://egonw.github.com/
> LinkedIn: http://se.linkedin.com/in/egonw
> Blog: http://chem-bla-ics.blogspot.com/
> PubList: http://www.citeulike.org/user/egonw/tag/papers
>
>
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>

Hi Egon,


The last time it
was online, I saw it contained JChemPaint 3.3.0, while the official
download page for JChemPaint
(http://sourceforge.net/projects/cdk/files/JChemPaint/) has the latest
version of 3.2.0. Is 3.3.0 an official release? The versioning seems a
bit unclear.

I am not sure about that. That is a question that Christoph should
answer...

I see, my bad, I thought that CDK and JChemPaint are being developed by the same people.


Indeed. We do not like deleting history, but git is the main
repository. The SourceForge and GitHub git repositories are mirrored,
with GitHub being the more up to date one (patches go there first).

I understand you do not want to delete history, but why not create an "archive" section somewhere out of sight and dump all the historical stuff in there? IMHO that would make it much easier for newcomers to get familiar with CDK development.


The JChemPaint applet/application uses a forked code base of
CDK-JChemPaint (the rendering/controller stack), and is not
easily rebased on either of the above... instead, this will require to
look at individual patches and decide what to do with it: ignore or
(back)port.

That indeed seems... complicated :)


2) Use only git (or only SVN) for the code trees of both CDK and
JChemPaint,

I have to check how JChemPaint is developed, but am not the maintainer
of that, and not the person to decide of git or svn should be used...

Perhaps it would be better if JChemPaint used its own source code repository, instead of mixing with CDK's. I mean, if the projects are separated, they should be separated completely, to avoid confusion. Just my five cents.


Best,

Tomas

===============================================
Tomáš Pluskal
G0 Cell Unit, Okinawa Institute of Science and Technology Graduate University
1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan
TEL: +81-98-966-8684
Fax: +81-98-966-2890

Hi Nina,

Thanks for all the answers!

The CDK and CDK-JCP maven artifacts are created and deployed only for releases, which are available for download at the sourceforge.net<http://sourceforge.net/>.  The workflow is

1) download a release
2) compile by
ant
and
ant dist-pure
3) Use https://ambit.svn.sourceforge.net/svnroot/ambit/trunk/cdk-maven to generate and deploy the artifacts.

Have you considered including these pom.xml descriptors into the official CDK source tree?
Perhaps we could create an ant task to deploy each new release into the maven repository automatically..


Best,

Tomas

===============================================
Tomáš Pluskal
G0 Cell Unit, Okinawa Institute of Science and Technology Graduate University
1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan
TEL: +81-98-966-8684
Fax: +81-98-966-2890

Hi Tomas,

On Mon, May 21, 2012 at 7:54 AM, Tomas Pluskal <pluskal@...> wrote:
> I see, my bad, I thought that CDK and JChemPaint are being developed by the
> same people.

Yes and no... that's complicated :)

But both historically have been international projects, with
independent teams working on them... I cannot looking into the
agenda's of other contributing groups...

>> Indeed. We do not like deleting history, but git is the main
>> repository. The SourceForge and GitHub git repositories are mirrored,
>> with GitHub being the more up to date one (patches go there first).
>
> I understand you do not want to delete history, but why not create an
> "archive" section somewhere out of sight and dump all the historical stuff
> in there? IMHO that would make it much easier for newcomers to get familiar
> with CDK development.

That is not as easy as it sounds in a Subversion world...

>> The JChemPaint applet/application uses a forked code base of
>> CDK-JChemPaint (the rendering/controller stack), and is not
>> easily rebased on either of the above... instead, this will require to
>> look at individual patches and decide what to do with it: ignore or
>> (back)port.
>
> That indeed seems... complicated :)

Yeah, large (multi-team) projects tend to be like that...

> Perhaps it would be better if JChemPaint used its own source code
> repository, instead of mixing with CDK's. I mean, if the projects are
> separated, they should be separated completely, to avoid confusion. Just my
> five cents.

The JChemPaint applet/application traditionally has been a separate
repository...

At the same time, you like to be able to work with the code at the
same time too, particularly of both are in a flux...

It's complicated, and there are many independent wishes... we try to
get those to align, but that sometimes doesn't work out as well as the
other time... e.g. keep in mind that the rendering/controller stack
must be output channel (AWT, Swing, SWT, SVG; and I hope we see
Android support too at some point) independent... and that we have
size limits... we need a small code base, so we have to be very
modular...

But complexity is a fact in the Open Source world, where you have many
stakeholders, more communication, which is harder too...

Egon

-- 
Dr E.L. Willighagen
Postdoctoral Researcher
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers

Hi Tomas,

On 21 May 2012 09:06, Tomas Pluskal <pluskal@...> wrote:

>  Hi Nina,
>
>  Thanks for all the answers!
>
>    The CDK and CDK-JCP maven artifacts are created and deployed only for
> releases, which are available for download at the sourceforge.net.  The
> workflow is
>
>  1) download a release
> 2) compile by
> ant
> and
> ant dist-pure
> 3) Use https://ambit.svn.sourceforge.net/svnroot/ambit/trunk/cdk-maven to
> generate and deploy the artifacts.
>
>
>  Have you considered including these pom.xml descriptors into the
> official CDK source tree?
>

If I remember right, an old version of it is in fact included, but haven't
been updated recently. Also it might slightly differ across CDK versions,
as new CDK modules are added/removed.


> Perhaps we could create an ant task to deploy each new release into the
> maven repository automatically..
>
>
It rather needs an ant/shell task to populate the jars (and rename where
appropriate). For the CDK itself there is no problem to be done
automatically,  perhaps not quite so for CDK-JCP (Egon could tell better),
but for the JChemPaint  I am afraid it will still be a manual update.

To add my two cents, I would like to see JChemPaint using CDK as a maven
dependency, then it will not matter at all where JChemPaint source code
resides.

Thank you,
Nina



>
>  Best,
>
>  Tomas
>
>   ===============================================
> Tomáš Pluskal
> G0 Cell Unit, Okinawa Institute of Science and Technology Graduate
> University
> 1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan
> TEL: +81-98-966-8684
> Fax: +81-98-966-2890
>
>
>
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>
>

On Mon, May 21, 2012 at 09:15:39AM +0300, Nina Jeliazkova wrote:
> To add my two cents, I would like to see JChemPaint using CDK as a maven
> dependency, then it will not matter at all where JChemPaint source code
> resides.

Well, even then it would matter, as JCP-3.3 is built upon
OSS and thus its source should be available to people 
interested like me. Else it's a licence breach, isn't it?

Regards,
ralf

On 21 May 2012 09:46, <ralf@...> wrote:

> On Mon, May 21, 2012 at 09:15:39AM +0300, Nina Jeliazkova wrote:
> > To add my two cents, I would like to see JChemPaint using CDK as a maven
> > dependency, then it will not matter at all where JChemPaint source code
> > resides.
>
> Well, even then it would matter, as JCP-3.3 is built upon
> OSS and thus its source should be available to people
> interested like me. Else it's a licence breach, isn't it?
>

There is no question that the source code should be available, and it is.

Using a modern dependency management mechanism just adds convenience.   One
could import in e.g. Eclipse any number of maven projects and tell the IDE
to resolve the dependencies either locally in the workspace, or from remote
repositories. This allows to work on two or more codebases simultaneously,
without worrying too much where the source code is hosted,  loading and
configuring jars and classpaths over and over again.

Besides one could and should include  sources for OSS projects in the maven
repository (and they are for CDK), and they become conveniently available
in the IDE for inspecting by just configuring the dependency in the pom.xml
file.

Best regards,
Nina


> Regards,
> ralf
>
>
>
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>

On 21 May 2012, at 07:54, Tomas Pluskal wrote:

> Hi Egon,
> 
>> 
>>> The last time it
>>> was online, I saw it contained JChemPaint 3.3.0, while the official
>>> download page for JChemPaint
>>> (http://sourceforge.net/projects/cdk/files/JChemPaint/) has the latest
>>> version of 3.2.0. Is 3.3.0 an official release? The versioning seems a
>>> bit unclear.
>> 
>> I am not sure about that. That is a question that Christoph should
>> answer...
> 
> I see, my bad, I thought that CDK and JChemPaint are being developed by the same people.
> 

Whatever that means!?

CDK and JChemPaint have a joint history of now 15 years (!) and they are both projects developed and maintained by a large and ever changing set of volunteers.
People move jobs and places and their needs and duties change. 
So the good old Zork rule applies - if you want something done, do it yourself :-)
(The latter sentence is not meant to be unfriendly - we help and have always helped wherever we can)
At the moment, for various reasons, we (as in: my team at the EBI) find ourselves unable to properly support CDK and JCP because we simply have no funding for it. 
I find this disturbing but cannot do much against it for now. 
I do, however, have plans to apply for funding (again) to change that situation. 

Kind regards, 

Chris

--
Dr. Christoph Steinbeck
Head of Cheminformatics and Metabolism
European Bioinformatics Institute (EBI)
Wellcome Trust Genome Campus
Hinxton, Cambridge CB10 1SD UK
Phone +44 1223 49 2640


What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..

On Mon, May 21, 2012 at 10:17:42AM +0300, Nina Jeliazkova wrote:
> On 21 May 2012 09:46, <ralf@...> wrote:
> 
> > On Mon, May 21, 2012 at 09:15:39AM +0300, Nina Jeliazkova wrote:
> > > To add my two cents, I would like to see JChemPaint using CDK as a maven
> > > dependency, then it will not matter at all where JChemPaint source code
> > > resides.
> >
> > Well, even then it would matter, as JCP-3.3 is built upon
> > OSS and thus its source should be available to people
> > interested like me. Else it's a licence breach, isn't it?
> >
> 
> There is no question that the source code should be available, and it is.

Excuse me for hijacking this thread.
Where is the source for

http://www.ebi.ac.uk/steinbeck-srv/jchempaint-nightly/jchempaint-3.3.0.jar

which appears to be the newest JCP.


ralf

I see, my bad, I thought that CDK and JChemPaint are being developed by the same people.


Whatever that means!?

What I meant was... Egon is clearly the leader of the CDK project, yet he does not seem to know the current status of JChemPaint development.
Therefore at least leadership-wise the two projects seem to be separated (of course I understand the developer groups overlap).
There is nothing wrong with that, it just slightly adds to the confusion - JChemPaint being published in the same folder with CDK (https://sourceforge.net/projects/cdk/files/), and CDK code being included in JChemPaint releases..


So the good old Zork rule applies - if you want something done, do it yourself :-)

Indeed, I understand that.. I also work on open-source.
My message was simply that if the leaders of CDK/JChemPaint could spend a bit of effort cleaning up the historical mess, it would enable other people to join the development more easily and actually implement what they want done :)
I am not saying it is impossible to implement things in the current state, I just think it turns people off... which is a pity for such useful projects as CDK and JChemPaint.

Best regards,

Tomas

===============================================
Tomáš Pluskal
G0 Cell Unit, Okinawa Institute of Science and Technology Graduate University
1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan
TEL: +81-98-966-8684
Fax: +81-98-966-2890

On Mon, May 21, 2012 at 10:39 AM, Tomas Pluskal <pluskal@...> wrote:
> JChemPaint being published in the same folder with CDK
> (https://sourceforge.net/projects/cdk/files/),

Just to add to the confusion... CDK-JChemPaint != JChemPaint ...

JChemPaint is the applet/application and you download that from:

https://sourceforge.net/projects/jchempaint/

CDK-JChemPaint is the new rendering/controller stack used and
originating from JChemPaint...

That you download from the CDK project on SourceForge.

> My message was simply that if the leaders of CDK/JChemPaint could spend a
> bit of effort cleaning up the historical mess, it would enable other people
> to join the development more easily and actually implement what they want
> done :)

Oh, we love too... where can I send our bank account number?

> I am not saying it is impossible to implement things in the current state, I
> just think it turns people off... which is a pity for such useful projects
> as CDK and JChemPaint.

It would be great if you would like to help improve things... because
that's the only thing missing.

We do not deliberately make things difficult for people to start
with... we just do not have the resources to explain things in enough
detail, and to maintain all the info that we output and occasionally
gets outdated...

Seriously, people are getting a good deal, and everyone is more than
welcome to *buy* a license and get commercial support. People who are
that easily put off should realize that they are piggybacking on other
peoples work, and that with the proper incentive we can polish things
for them. We have been working on getting commercial support of the
ground. In that world, things are a lot smoother.

For us people who like access to a Java-based chemical editor, being
able to tweak it, we just get along and contribute bits ourselves...
that has taken the CDK where it is today.

But *importantly*: you can help the project, be part of it, and shape
the future of the both the CDK and JChemPaint!

Egon

-- 
Dr E.L. Willighagen
Postdoctoral Researcher
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers

JChemPaint being published in the same folder with CDK
(https://sourceforge.net/projects/cdk/files/),

Just to add to the confusion... CDK-JChemPaint != JChemPaint ...

JChemPaint is the applet/application and you download that from:

https://sourceforge.net/projects/jchempaint/

The address you mentioned has no files to download...
AFAIK the JChemPaint application files are together with CDK at https://sourceforge.net/projects/cdk/files/, at least until version 3.2.0.


My message was simply that if the leaders of CDK/JChemPaint could spend a
bit of effort cleaning up the historical mess, it would enable other people
to join the development more easily and actually implement what they want
done :)

Oh, we love too... where can I send our bank account number?

We both know the world is not ideal. I also receive no money for working on MZmine, and I spend a great deal of my free time doing that...


I am not saying it is impossible to implement things in the current state, I
just think it turns people off... which is a pity for such useful projects
as CDK and JChemPaint.

It would be great if you would like to help improve things... because
that's the only thing missing.

I would be very happy to help. In fact I hope that starting this discussion might help in some way..

Best,

Tomas

===============================================
Tomáš Pluskal
G0 Cell Unit, Okinawa Institute of Science and Technology Graduate University
1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan
TEL: +81-98-966-8684
Fax: +81-98-966-2890

On Mon, May 21, 2012 at 11:48 AM, Tomas Pluskal <pluskal@...> wrote:
> AFAIK the JChemPaint application files are together with CDK
> at https://sourceforge.net/projects/cdk/files/, at least until version
> 3.2.0.

Oops... I am so sorry! They are indeed. I was not aware of that. Well,
that even confuses me...

Egon


-- 
Dr E.L. Willighagen
Postdoctoral Researcher
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers

On 21 May 2012 11:15, <ralf@...> wrote:

> On Mon, May 21, 2012 at 10:17:42AM +0300, Nina Jeliazkova wrote:
> > On 21 May 2012 09:46, <ralf@...> wrote:
> >
> > > On Mon, May 21, 2012 at 09:15:39AM +0300, Nina Jeliazkova wrote:
> > > > To add my two cents, I would like to see JChemPaint using CDK as a
> maven
> > > > dependency, then it will not matter at all where JChemPaint source
> code
> > > > resides.
> > >
> > > Well, even then it would matter, as JCP-3.3 is built upon
> > > OSS and thus its source should be available to people
> > > interested like me. Else it's a licence breach, isn't it?
> > >
> >
> > There is no question that the source code should be available, and it is.
>
> Excuse me for hijacking this thread.
> Where is the source for
>
> http://www.ebi.ac.uk/steinbeck-srv/jchempaint-nightly/jchempaint-3.3.0.jar


My first reply in this thread contains all necessary instructions to
download and compile the JCP .

Best regards,
Nina


>
>
> which appears to be the newest JCP.
>
>
> ralf
>
>
>
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>

On Mon, May 21, 2012 at 03:39:11PM +0300, Nina Jeliazkova wrote:
> > http://www.ebi.ac.uk/steinbeck-srv/jchempaint-nightly/jchempaint-3.3.0.jar
> 
> 
> My first reply in this thread contains all necessary instructions to
> download and compile the JCP .

Indeed, many thanks. Now this is odd, after so many
pleas to contribute, I wanted to contribute to the Wiki
and append this information to the page

https://sourceforge.net/apps/mediawiki/cdk/index.php?title=Development

but even while I'm logged in I cannot edit the page.
The action you have requested is limited to users in one of the groups:
editor, admin.

I think if you want to be helped, you at least have to
provide the environment for it, and a Wiki that is non-editable
is a no-no for that.


ralf

On Mon, May 21, 2012 at 3:58 PM,  <ralf@...> wrote:
> Indeed, many thanks. Now this is odd, after so many
> pleas to contribute, I wanted to contribute to the Wiki
> and append this information to the page
>
> https://sourceforge.net/apps/mediawiki/cdk/index.php?title=Development
>
> but even while I'm logged in I cannot edit the page.

What is your SF account? Thanx for the wonderful SPAM community, we
actually have a system where you need to be given explicit write
access...

> I think if you want to be helped, you at least have to
> provide the environment for it, and a Wiki that is non-editable
> is a no-no for that.

I do not believe we have any choice here... nothing we can do about
SPAM other than this :/

Please do let us know your SF account...

Egon

-- 
Dr E.L. Willighagen
Postdoctoral Researcher
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers

On Mon, May 21, 2012 at 04:07:31PM +0200, Egon Willighagen wrote:
> What is your SF account? Thanx for the wonderful SPAM community, we
> actually have a system where you need to be given explicit write
> access...

This is a sourceforge specialty, as github allows editing
by other registered users.

> I do not believe we have any choice here... nothing we can do about
> SPAM other than this :/

I have made no negative experiences at github.
My pages were probably too specialized to attract
such users. But I'm sure github would have dealt with
them immediately. So, I'm not of your opinion.

> Please do let us know your SF account...
> 
The account is rwst. Thanks in advance.


ralf

GitHub wiki++

John

On 21 May 2012, at 15:42, ralf@... wrote:

> On Mon, May 21, 2012 at 04:07:31PM +0200, Egon Willighagen wrote:
>> What is your SF account? Thanx for the wonderful SPAM community, we
>> actually have a system where you need to be given explicit write
>> access...
> 
> This is a sourceforge specialty, as github allows editing
> by other registered users.
> 
>> I do not believe we have any choice here... nothing we can do about
>> SPAM other than this :/
> 
> I have made no negative experiences at github.
> My pages were probably too specialized to attract
> such users. But I'm sure github would have dealt with
> them immediately. So, I'm not of your opinion.
> 
>> Please do let us know your SF account...
>> 
> The account is rwst. Thanks in advance.
> 
> 
> ralf
> 
> 
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel

On Mon, May 21, 2012 at 4:42 PM,  <ralf@...> wrote:
> I have made no negative experiences at github.
> My pages were probably too specialized to attract
> such users. But I'm sure github would have dealt with
> them immediately. So, I'm not of your opinion.

Look, I am not trying to say that SourceForge made the right choices...

Just consider how much work it is to move the full SourceForge project
to GitHub... that is what matters. If you like to move all wiki pages
to GitHub, then I am most certainly not against that. We have moved
wiki pages 3 times in the past; I (and others) have done or share
there, /me thinks...

Egon

-- 
Dr E.L. Willighagen
Postdoctoral Researcher
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers

On Mon, May 21, 2012 at 4:42 PM,  <ralf@...> wrote:
>> Please do let us know your SF account...
>>
> The account is rwst. Thanks in advance.

Added. Can you please test it?

Egon

-- 
Dr E.L. Willighagen
Postdoctoral Researcher
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers

Hi Egon,

We do not deliberately make things difficult for people to start
with... we just do not have the resources to explain things in enough
detail, and to maintain all the info that we output and occasionally
gets outdated...

I can see two factors playing a role here:

1) you want to keep the whole history of the project as it is, including unused/old branches and repositories

2) nobody has the time/resources to update developer documentation and provide tutorials for newcomers to the project

Neither of these would be a problem by itself, but IMHO it is the combination of these two factors that creates the general confusion.

Since the second point cannot be easily changed, have you considered whether keeping the complete history is really beneficial?

If CDK was my project, I would prefer to dump all the unused code/documents/data into a ZIP file somewhere in the website, and keep only cutting edge development in the source code repository. That way it would not be necessary to write documentation about how things are organized, because every newcomer willing to contribute a small patch could easily orient himself.

Perhaps it might be interesting to hear what other CDK developers think about this..?

Best regards,

Tomas

===============================================
Tomáš Pluskal
G0 Cell Unit, Okinawa Institute of Science and Technology Graduate University
1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan
TEL: +81-98-966-8684
Fax: +81-98-966-2890

On 22 May 2012 05:58, Tomas Pluskal <pluskal@...> wrote:

>  Hi Egon,
>
>  We do not deliberately make things difficult for people to start
> with... we just do not have the resources to explain things in enough
> detail, and to maintain all the info that we output and occasionally
> gets outdated...
>
>
>  I can see two factors playing a role here:
>
>  1) you want to keep the whole history of the project as it is, including
> unused/old branches and repositories
>
>  2) nobody has the time/resources to update developer documentation and
> provide tutorials for newcomers to the project
>
>  Neither of these would be a problem by itself, but IMHO it is the
> combination of these two factors that creates the general confusion.
>
>  Since the second point cannot be easily changed, have you considered
> whether keeping the complete history is really beneficial?
>
>  If CDK was my project, I would prefer to dump all the unused
> code/documents/data into a ZIP file somewhere in the website, and keep only
> cutting edge development in the source code repository. That way it would
> not be necessary to write documentation about how things are organized,
> because every newcomer willing to contribute a small patch could easily
> orient himself.
>
>  Perhaps it might be interesting to hear what other CDK developers think
> about this..?
>

Only the cutting edge is not quite good idea for a project with ~15 y
history and a library... there are plenty of software around the world,
which use older versions directly or as dependencies.   Plenty of
publications citing "we are using version XXX" , which might be 5 or more
years old.

>From personal experience : the first release of Toxtree [1] using CDK as a
dependency is from 2005. The 2009 Toxtree 1.60 , using a pre-release (<
1.0) CDK version from 2008 is still actively used and cited worldwide,
regardless that there are new versions from the all the subsequent years,
with newer CDK dependencies, and despite strong encouragements to upgrade.
 Definitely not everybody want to be on the bleeding edge, and usually for
a reason.

I agree things could have been cleaned and documented and better.

Regards,
Nina

[1] http://toxtree.sourceforge.net/
[2] http://toxtree.sourceforge.net/download.html#Toxtree-v1.60


>  Best regards,
>
>  Tomas
>
>   ===============================================
> Tomáš Pluskal
> G0 Cell Unit, Okinawa Institute of Science and Technology Graduate
> University
> 1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan
> TEL: +81-98-966-8684
> Fax: +81-98-966-2890
>
>
>
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>
>

Only the cutting edge is not quite good idea for a project with ~15 y history and a library... there are plenty of software around the world, which use older versions directly or as dependencies.   Plenty of publications citing "we are using version XXX" , which might be 5 or more years old.

Well, that is exactly what the archive is for...

Tomas


===============================================
Tomáš Pluskal
G0 Cell Unit, Okinawa Institute of Science and Technology Graduate University
1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan
TEL: +81-98-966-8684
Fax: +81-98-966-2890

On Mon, May 21, 2012 at 08:21:54PM +0200, Egon Willighagen wrote:
> Just consider how much work it is to move the full SourceForge project
> to GitHub... that is what matters.

No need for that. Other projects are splitting repo/tracker/pages
too between sites. Inkscape.org is an example I know.
github can handle Mediawiki pages, so it would not be
difficult technically to move the cdk wiki pages to github/cdk/cdk.

So, as a possible next step I could move all wiki pages to
github which requires that I become member of the cdk org there.

However, atm there is not a JChemPaint project at SF, only
an SVN repo, a trac tracker (argh) and Wiki pages. It would
be much more worthwhile for users to have a single project
identifiable with all things related to jchempaint together,
and distinct from the cdk library, but Tomas said that already.

So, my preference would be to create a JChemPaint project
at github, either cdk/jchempaint (in which case I also need
to be member of cdk) or else. Then move the repo and wiki pages,
and last the tracker issues.

Opinions?

ralf

On 22 May 2012 10:22, <ralf@...> wrote:

> On Mon, May 21, 2012 at 08:21:54PM +0200, Egon Willighagen wrote:
> > Just consider how much work it is to move the full SourceForge project
> > to GitHub... that is what matters.
>
> No need for that. Other projects are splitting repo/tracker/pages
> too between sites. Inkscape.org is an example I know.
> github can handle Mediawiki pages, so it would not be
> difficult technically to move the cdk wiki pages to github/cdk/cdk.
>
> So, as a possible next step I could move all wiki pages to
> github which requires that I become member of the cdk org there.
>
> However, atm there is not a JChemPaint project at SF, only
> an SVN repo, a trac tracker (argh) and Wiki pages. It would
> be much more worthwhile for users to have a single project
> identifiable with all things related to jchempaint together,
> and distinct from the cdk library, but Tomas said that already.
>
> So, my preference would be to create a JChemPaint project
> at github, either cdk/jchempaint (in which case I also need
> to be member of cdk) or else. Then move the repo and wiki pages,
> and last the tracker issues.
>
> Opinions?
>


Not being JCP developer, just an user for a long time, I am absolutely for
it.  I believe this is the right moment, since the JCP 3.3.0 source at
trunk compiles smoothly with the latest stable 1.4.x versions, and
technically  should be trivial to copy the content of the EBI repository
into a github one. I have no idea whether there are other concerns besides
technical ones though.

Regards,
Nina



>
> ralf
>
>
>
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>

No other concerns. 

Cheers,

Chris

-- Sent from my iPhone

Am 22 May 2012 um 08:35 schrieb Nina Jeliazkova <jeliazkova.nina@...>:

> 
> 
> On 22 May 2012 10:22, <ralf@...> wrote:
> On Mon, May 21, 2012 at 08:21:54PM +0200, Egon Willighagen wrote:
> > Just consider how much work it is to move the full SourceForge project
> > to GitHub... that is what matters.
> 
> No need for that. Other projects are splitting repo/tracker/pages
> too between sites. Inkscape.org is an example I know.
> github can handle Mediawiki pages, so it would not be
> difficult technically to move the cdk wiki pages to github/cdk/cdk.
> 
> So, as a possible next step I could move all wiki pages to
> github which requires that I become member of the cdk org there.
> 
> However, atm there is not a JChemPaint project at SF, only
> an SVN repo, a trac tracker (argh) and Wiki pages. It would
> be much more worthwhile for users to have a single project
> identifiable with all things related to jchempaint together,
> and distinct from the cdk library, but Tomas said that already.
> 
> So, my preference would be to create a JChemPaint project
> at github, either cdk/jchempaint (in which case I also need
> to be member of cdk) or else. Then move the repo and wiki pages,
> and last the tracker issues.
> 
> Opinions?
> 
> 
> Not being JCP developer, just an user for a long time, I am absolutely for it.  I believe this is the right moment, since the JCP 3.3.0 source at trunk compiles smoothly with the latest stable 1.4.x versions, and technically  should be trivial to copy the content of the EBI repository into a github one. I have no idea whether there are other concerns besides technical ones though.
> 
> Regards,
> Nina
> 
>  
> 
> ralf
> 
> 
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
> 
> ------------------------------------------------------------------------------
> 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
> Cdk-devel@...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel

Maybe it's even better to have a jchempaint organization,
I don't know about this enough.

Egon, it just depends on you if you want to have it all under
cdk or not. If you don't have time, however, it might be better
I just go ahead with that jchempaint account. If I'm not mistaken,
ownership of a project is easily transferred.


ralf