> 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 well. > > 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 condition. 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. Thanks, Karl --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
