incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <>
Subject Re: [VOTE] Release Apache ManifoldCF 0.1
Date Sun, 09 Jan 2011 14:30:35 GMT
> Not sure what you mean by "open" copy.

"Open" meaning not bound up in a war.

> There are also 2 copies of each of the war files, total 37M for one set.

Yes, that's known to me; so you are also suggesting that not just the
dependent jars be treated this way, but all the built artifacts as

> Sorry, but I still don't understand the complexity argument. Here's
> what I am suggesting:

I understand what you are suggesting.  The complexity comes from the
fact that the build is all conditionalized already in three different
dimensions.  Each connector may or may not be buildable, and the build
logic that assembles the final artifacts must pay attention to that

This is likely to be a complicated explanation, so bear with me.

(1) Each primary component (framework, each connector) has its own
dist area, and its own build.xml.
(2) Each component build.xml has several well-known build targets,
e.g. "build", "doc", "test" etc.  The rule is that the smarts for
deciding what jars need to run in what processes goes in each
component build, not in the main build.
(3) A major job of the main build.xml is to assemble all these
components together in a final artifact.
(4) Because there are two different models, there are already two
different sets of targets in the final build for doing that:
deliver-xxx-example, and deliver-xxx.
(5) Each deliver-xxx target blindly copies what is needed from the
xxx/dist area into the multiprocess area, and builds the wars from the
proper stuff in xxx/dist based blindly on what's in a particular
xxx/dist directory.
(6) Each deliver-xxx-example target blindly copies what is needed from
the xxx/dist area into the example area, AND also adds a registration
entry to a connectors.xml configuration file.
(7) Currently, the build image does NOT include xxx/dist at all, just
the main dist/ area.

Your suggestion, therefore, is tantamount to the following:
(1) Keep the xxx/dist area in the distribution, EXCEPT for the jars
which come from the dependencies and the jars which come from the
earlier components of the build.
(2) Do not include the dist/ area in the distribution.
(3) Do the delivery process under a separate "install" target.

The problems are (a) we have no way of knowing now what pieces for
each component came from upstream and which were built by the
component.  These would have to be separated out.  And, (b) by the
time we come around to doing the final "install" target, we've lost
the conditional information because we don't keep those directories
around in the distribution.

The alternative approach would be to revise the build so that all of
the pieces wind up in a "staging area", through an entirely separate
set of targets, which I'll call "deliver-xxx-staging".  That adds 50%
more targets, as you can see, and it also still has the (b) problem as
stated above.

I hope this clears up why I think your proposal adds significant complexity.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message