Hi,
I guess this discussion is about publishing on ibiblio. We need to have distinctive jar file names that folks can use to figure out what to get. And there is not necessarily a 1-1 correspondence between what we build in Apache JDO and what binaries show up on ibiblio.
1. Is it agreed that ibiblio need not have a source distribution? I think if anyone needs the sources then they can download them directly from the svn repo on Apache.
So we have to come up with packaging that makes sense. And it isn't obvious to me that we want a jar file for each project in JDO. For example, we probably want to split out the current ri11 into a few projects when we migrate the code to 20, because we can use different pieces in different areas. Does this mean that each subproject would get its own jar on ibiblio? One example of this is the model which we expect can be used in a UI without needing the enhancer, runtime, fostore, or even the jdo.jar. This probably deserves its own jar file. But we have a number of utility classes that the other subprojects all need, and I don't think we should create a jdo2-utility-2.0-a1 just for 10 classes.
2. I agree that we should include "apache-jdo" when it's the apache implementation not the api or tck that we're distributing. So it's a matter of where we put the "apache-jdo" in the name. In the case of the model, perhaps something like "apache-jdo1-model-2.0-a1.jar" where the artifact-id is "apache-jdo1", the version is "2.0" and the vehicle is "-a1". And "apache-jdo2-fostore-a1.jar".
We need to decide on the names for the non-implementation jar file names as well. A side note: we should be careful not to call these "official JDO TCK" and "official JDO API". The "official" distribution can only come from the JCP web site where they can make sure that people click the license that carries some real restrictions. What we're building in Apache is fed into the JCP process but it's not a substitute for it.
3. For the binary distribution of the 2.0 TCK, how about "jdo2-tck-a1.jar" that doesn't reflect the Apache heritage. And "jdo2-api-a1.jar" for the specification api.
Craig
On Apr 14, 2005, at 11:34 AM, Brian Topping wrote:
Indeed, I think I said "implementation".
:b
Andy Jefferson wrote:
On Thursday 14 Apr 2005 19:09, Brian Topping wrote:
I'm also a bit concerned about the groupId WRT to it's name in the
listing for ibiblio. I believe 'jdo' is a bit too generic, and does
nothing to distinguish the apache JDO from other implementations as it
should.
I would suggest 'apache-jdo' at the very minimum for this. Any objections or better suggestions?
Depends which project's groupId you're referring to here. Apache JDO encompasses many things. The "jdo.jar" is a generic interface (under "api20"). It should be under "jdo" IMHO. It isn't an implementation. It's the definitive interface for that technology
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
