openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Repository structure
Date Mon, 08 May 2006 16:27:14 GMT
Hi Patrick,

On May 4, 2006, at 9:31 AM, Patrick Linskey wrote:

> Comments inline.
>
>> Before you check in code, it would be nice to discuss the
>> directory structure to facilitate development, release, and
>> documentation.
>
> Agreed, but given how long it's taken me to get to this point, I'm  
> not going
> to hold up check-in for that purpose. So some of this work might  
> have to
> take place after check-in. Happily, svn is move-intelligent.

Indeed.
>
>> It would also be good to decide what build tool to use. I
>> personally like maven for a project as complex as this one.
>> Especially if it depends on other projects (e.g. antlr, logging,  
>> etc).
>
> We currently use ant and manually maintain our dependencies. I can  
> see that
> maven could be something to move to at some point, but again I want  
> to lower
> the bar to getting the source into svn as far as possible.

Cool. Let me know how I can help, although I'd guess the lawyers have  
more to do with this than the technical folks.

>
>> docs/ everything that is used to display the site index.html
>> the main page downloads.html images/ images used on the site
>> team.html the development/test/doc team members releases/
>> pages for downloading releases ... other site pages
>
> Just for clarification, this is just the project HTML etc, and not the
> documentation for the product itself, correct? Clearly, the product  
> docs
> need to live in the trunk alongside the code so that it can be  
> branched etc.
> along with its corresponding code.

I could help with some of the infrastructure, like the web site. Geir  
set up our site and I think I could replicate it with some review by  
you guys.

By the way, the site should reference the JIRA and wiki. I don' t  
think these have been set up yet, have they?
>
>> trunk/
>> core contains the kodo core
>> spec contains the jsr220 jar artifacts from the spec
>> ejb contains the ejb container interface
>> se contains the java se implementation
>
> FYI, I avoid the word 'core' like the plague, since I still see the
> occasional core dump.

Sure, I understand.

> The structure that we've got so far looks like:
>
> util/ 	general utility (XML processing, logging, annotation utils,  
> etc.)
> kernel/ 	the Broker interface etc. What you're calling core.

I guess you came up with the name Broker late in the game. I think  
it's good that you refer to the broker instead of the kernel, as  
kernel is way too overloaded already.

Craig
>
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