tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Tomcat 6 source organisation
Date Tue, 28 Feb 2006 22:31:04 GMT
Of course, this is a case where you need a separate module.

IMHO it is a bad sign when you have to do this - maybe you could use a
different
package name instead of same class names, or refactor a bit so you don't depend
on the class name.
But if for any reason you have to use the same classname, then use a
different module for
that code. JDK does this for platform-specific things in IO, awt, etc.

I think this should be the exception, not the rule.

Costin

On 2/28/06, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
> I would prefer to keep the module source tree separate.
> For example, the "ha" module (cluster2) uses the same classes as the
> "cluster", but they are being enhanced for performance and modularity.
> merging all this into one tree would be a pain in the neck.
>
> Filip
>
>
> Costin Manolache wrote:
> > On 2/28/06, Mark Thomas <markt@apache.org> wrote:
> >
> >> Remy Maucherat wrote:
> >>
> >>> Hi,
> >>>
> >>> I think it is time to decide how the source repository is going to be
> >>> organized, with the questions being:
> >>> - how many source folders do we need (Costin wanted one, while others
> >>> like Jacob seem to want "modules") ?
> >>> - do we continue to use Ant ?
> >>> - etc
> >>>
> >> I am +0 on any changes.
> >>
> >> Assuming some changes are made, there needs to be some thought given
> >> to where in the source tree we put the trunk/branch/tag structure
> >> before we start moving things around.
> >>
> >
> >
> > Well, single source tree means all source will be in one svn repo.
> >
> > My understanding is that you can label/tag/branch subdirs - and that a
> > tag is cheap enough that you can do it for the entire tree.
> >
> > I think it's better to tag the entire tree - not just the component,
> > so it's easier to reproduce ( since it has deps, etc ). That seems the
> > current practice.
> >
> >
> >
> >
> >
> >
> >
> >> There have also been various comments made that different components
> >> may be released on different release cycles. If this route is
> >> followed, there needs to be a reasonably clear idea of what these
> >> components might be as this will also have an impact on the best way
> >> to structure the source.
> >>
> >>
> >
> > I don't think the source structure should be related to release structure.
> >
> > >From one source tree you can generate as many jars and packages as you
> > want, in any structure or variation.
> >
> > Things like 'el' or 'jspc' or maybe cluster could chose to release -
> > either as a jar, or as a .tar.gz or anything else. Or maybe not - that
> > should be an independent decision from source tree layout or build
> > mechanism.
> >
> > Costin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message