db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: ArtifactId of jdo projects
Date Thu, 14 Apr 2005 22:04:40 GMT
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Mime
View raw message