|
From: Dejan K. <dej...@nb...> - 2003-11-13 10:07:23
|
> I think that we should probably look at guidelines for 1.3, and try to > do as much as possible without breaking anything. I'm happy to move the > jfreereports stuff into a separate project, even for 1.3. It's not in > 1.2, so there are no issues with compatibility. > > In order to set the guidelines, a few questions: what constitutes a core > module (i.e.: one which goes into com.babeldoc.core.pipeline or > com.babeldoc.scanner)? Or a secondary (i.e.: it goes into e.g.: > com.babeldoc.sql.*), or a peripheral module (i.e.: into it's own CVS > project and separate jar files) Well these are the issues we should talk about. I am not very satisfied with current module organization. IMO, in core module there should be classes needed by other modules. For example, I would put scanner classes into core module. However, I would exclude all classes (scaner workers, pipeline stages, journal implementations) that need some additional jars or that are not used very often. All other modules should be developed, maintained and downloaded separately. > As far as the mechanics go, what about having a "contrib" top-level > project, into which any developer can place any experimental code. > Postgres do this, and it seems to work quite well. When something in > contrib is considered to have matured enough, and be demanded enough, to > be in the core system, it's migrated from contrib into the main project. > > Thoughts... I agree. I would even create this as separate CVS project so we can grant CVS commit rights to everyone who wants. By the way, what exactly will do your new pipeline stage (jfreereport)? Dejan > > MikeA > > PS: I added a stack of directories before branching, I'm not sure if > they appear on the HEAD now. Anybody getting the new directories when > they "cvs update"? |