Something that I would really like is to have someone in charge of making releases for *any* of the Grok, Maxent, or Opennlp Common packages. I am too busy sorting out the code and I just do quick releases when particular milestones are reached and I don't bother to pass word along to Freshmeat and so on, nor do I do extensive testing.
So, it would be great if someone even just wanted to be part of the packaging and releasing of any of these packages. It wouldn't require any coding, but could be a good way of getting familiar with things in case you are interested in coding eventually. It would be a really bonus if someone could set up junit testing for the packages as well.
Anyway, just putting out the suggestion in case it perks someone's interest!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's not much, really. I have the Ant build.xml file set up to make it quite easy to make releases, but it would be nice if someone was independently checking that things worked okay before releasing. After making a release, it would be good to download and test the released file. Then, of course, announcing it on Freshmeat is a bonus. I sometimes do it, but I usually don't feel like it at the time since I'm glad to just have the new stuff available on sourceforge.
A release manager could also try to set schedules, and be in charge of bug tracking and such. I'm not doing that at all at present and it would be great to have.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My connection at home is too slow, so I won't be able to do it easily.
Looking at the task I see that there are several requirements:
1. Ensuring that the binary files (maxent, jars, wordnet data, etc.) present are in binary mode and that they work with the java implementation in cvs.
2. Coordinating releases among the various sub-projects, if a sub-project does not compile/work with the latest version of a required module, then the specific module version (e.g. opennlp-0.8.6.jar) required should be in the source path in the build.xml and run scripts.
4. We need to use the facilities that sourceforge offer more. Particularly the bug & feature request trackers.
5. I think it is a mistake to have the different opennlp projects as separate sourcefore projects, rather than sub-projects of opennlp. Having one cvs tree would help coordination. Having a single project would make it seem more active. There would only need to be one lib of required jars. It would be easier to administer. The sub-projects could still have their own build.xml files so could still be built separately. It would be easier to track and monitor the various discusion forums, news and releases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You make many good points --- just a few comments, though.
WRT (1) - yep, the binary files should be in binary mode, but no they don't necessarily need to be in sync with the CVS. For example, say I am working on Grok, and a bunch of changes happen to the opennlp.common classes. I really don't have time to make sure Grok works with the changes just yet, so I just use the opennlp.jar that is Grok's lib directory. This separation allows some slippage between development on a package and development on another package that uses it.
On (5), I have to disagree. We thought about this long ago, but we decided to make them separate so that each project was more autonomous. For example, neither the opennlp.maxent package nor the opennlp.common depend on one another, so why tie them into the same project space? Different developers work on each one, and it is nice to have the ability to allow access to one but not the other. They don't necessarily use the same libraries, so the shared lib directory isn't important
The separation is also important because of the fact that I mentioned above regarding the desirability of having a non-latest version of, say, opennlp.jar for compiling Grok. If it's all in the same tree, then each project has to stay on the bleeding edge.
So, it makes sense when you look at it from the perspective of the opennlp.common package since everything else depends on it, but from the perspective of the projects that are dependents, its better to be separate.
The other thing is that not all OpenNLP projects need to be Java, as the other discussion started by John Dowding demonstrates, so I wouldn't want to strap them into a pre-ordained paradigm.
A middle ground for some of these issues is not to have a separate project space, but still use different CVS modules. For example, the opennlp.hylo package started out in the main "opennlp" module, but has been separated out and now lives in the "Hylo" module, but both live in the OpenNLP project space.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Something that I would really like is to have someone in charge of making releases for *any* of the Grok, Maxent, or Opennlp Common packages. I am too busy sorting out the code and I just do quick releases when particular milestones are reached and I don't bother to pass word along to Freshmeat and so on, nor do I do extensive testing.
So, it would be great if someone even just wanted to be part of the packaging and releasing of any of these packages. It wouldn't require any coding, but could be a good way of getting familiar with things in case you are interested in coding eventually. It would be a really bonus if someone could set up junit testing for the packages as well.
Anyway, just putting out the suggestion in case it perks someone's interest!
Just what is required? How difficult is it to produce a release? How much time would it typically take?
It's not much, really. I have the Ant build.xml file set up to make it quite easy to make releases, but it would be nice if someone was independently checking that things worked okay before releasing. After making a release, it would be good to download and test the released file. Then, of course, announcing it on Freshmeat is a bonus. I sometimes do it, but I usually don't feel like it at the time since I'm glad to just have the new stuff available on sourceforge.
A release manager could also try to set schedules, and be in charge of bug tracking and such. I'm not doing that at all at present and it would be great to have.
My connection at home is too slow, so I won't be able to do it easily.
Looking at the task I see that there are several requirements:
1. Ensuring that the binary files (maxent, jars, wordnet data, etc.) present are in binary mode and that they work with the java implementation in cvs.
2. Coordinating releases among the various sub-projects, if a sub-project does not compile/work with the latest version of a required module, then the specific module version (e.g. opennlp-0.8.6.jar) required should be in the source path in the build.xml and run scripts.
3. Announcing releases
http://freshmeat.net/
http://www.jsurfer.org/
http://www.javalobby.org/
http://www.jars.com/
and possibly
http://industry.java.sun.com/
http://www.javaworld.com/news-reviews/jw-nr-products.shtml
4. We need to use the facilities that sourceforge offer more. Particularly the bug & feature request trackers.
5. I think it is a mistake to have the different opennlp projects as separate sourcefore projects, rather than sub-projects of opennlp. Having one cvs tree would help coordination. Having a single project would make it seem more active. There would only need to be one lib of required jars. It would be easier to administer. The sub-projects could still have their own build.xml files so could still be built separately. It would be easier to track and monitor the various discusion forums, news and releases.
You make many good points --- just a few comments, though.
WRT (1) - yep, the binary files should be in binary mode, but no they don't necessarily need to be in sync with the CVS. For example, say I am working on Grok, and a bunch of changes happen to the opennlp.common classes. I really don't have time to make sure Grok works with the changes just yet, so I just use the opennlp.jar that is Grok's lib directory. This separation allows some slippage between development on a package and development on another package that uses it.
On (5), I have to disagree. We thought about this long ago, but we decided to make them separate so that each project was more autonomous. For example, neither the opennlp.maxent package nor the opennlp.common depend on one another, so why tie them into the same project space? Different developers work on each one, and it is nice to have the ability to allow access to one but not the other. They don't necessarily use the same libraries, so the shared lib directory isn't important
The separation is also important because of the fact that I mentioned above regarding the desirability of having a non-latest version of, say, opennlp.jar for compiling Grok. If it's all in the same tree, then each project has to stay on the bleeding edge.
So, it makes sense when you look at it from the perspective of the opennlp.common package since everything else depends on it, but from the perspective of the projects that are dependents, its better to be separate.
The other thing is that not all OpenNLP projects need to be Java, as the other discussion started by John Dowding demonstrates, so I wouldn't want to strap them into a pre-ordained paradigm.
A middle ground for some of these issues is not to have a separate project space, but still use different CVS modules. For example, the opennlp.hylo package started out in the main "opennlp" module, but has been separated out and now lives in the "Hylo" module, but both live in the OpenNLP project space.