Re: [Babeldoc-devel] Temp branch

[Michael A. <mic...@ze...>]

Hi,

Yes,the contrib sub-project should definitely be open to as many people
as possible.  
But remember that contrib is only a breeding-ground for stable stuff. 
Current stable modules should exist within the main project, but not the
core.  And when contrib projects get stable enough, then they can
possibly be included in the main project, depending on demand (and
whether the developer team feels the module is worthwhile).  For the
main project, we can package the core system into one jar, and the
peripherals into another.  With respect, the entire system is 1.8MB in
jar files (not including the dependency files).  If we get a couple of
extra modules including in the core distro, is it really a problem?  For
me, I'm happy to have the whole thing (the main project, not contrib)
wrapped up in a single jar, and deploy that.

I think that we should ensure that by the time 1.3 is released, the
situation is no worse than it is now, and for 2.0, we rearrange.  Is
there a planned 1.4 release?

Cheers...


MikeA



On Thu, 2003-11-13 at 10:06, Dejan Krsmanovic wrote:
> > 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"?
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel