First let me apologize since I have to use Outlook to access the mailing list from work. I know it mangles quoted replies, but I'm stuck with it. My comments are below. Please don't take offense, as I am only looking to make Cocoon even better than it already is.
Ralph > -----Original Message----- > From: Geoff Howard [mailto:[EMAIL PROTECTED] > Sent: Saturday, August 16, 2003 9:32 PM > To: [EMAIL PROTECTED] > Subject: Re: [ANN] Apache Cocoon 2.1 Released - binary?? > > > Ralph Goers wrote: > > Personally, I don't really care whether cocoon ships as a > binary or not. In > > fact, to ship as a binary, each of the blocks would need to > be in its own > > jar file. From a documentation perspective this might be > better as it is > > easy to see which blocks are being included in a product. > > The java classes are already in their own jars. The config > and webapp > files aren't and can't realistically be. Yes, the blocks are in their own jars. I'm OK with that, but that really isn't an issue for me. I simply meant that when building from source, since you have the option of excluding blocks the output could all go in one jar. With binaries you'd be required to separate them out (as is currently done) so people could remove ones they don't want if they choose. The config and webapp files are the real problem. > > > What I need is to be able to access a set of jars and a basic set of > > configuration files that I can then incorporate into MY > build (i.e. it is > > unacceptable to build my stuff as part of the cocoon > build). This means I > > need to create my own cocoon.xconf and sitemap.xmap that > has JUST my stuff. > > The sitemap.xmap and cocoon.xconf should only have > definitions for the > > cocoon core components. In fact, the default cocoon build > SHOULD NOT even > > build the samples web site as I certainly don't want that > as part of my > > product. > > This brings up a great point about the distribution quandry > that led to > dropping the binary. A new poster on the dev list (Jay Freeman) is > looking for the exact opposite. He wants the kitchen sink with the > exception of a few blocks, you want the bare bones probably with the > exception of a few blocks. There are many variations on those > requirements and we have to try to accomodate all of them. > The solution > we came up with (for now) is a build from source that lets you > include/exclude as much or as little as you want. Defining > "cocoon core > components" is way trickier and more subjective than one would think. What Jay wants sounds pretty much like what I want. Although he wants all the jars and I can live without them, that really isn't a significant difference. I can also live with them. I got his email and it looks pretty rational to me. As far as defining what is a core component, you have already done that. If I exclude all the blocks then what is left must be the cocoon core components. > > The current system allows for everything you are asking for: > - You don't need to create your own cocoon.xconf or > sitemap.xmap because > the build will exclude/include only what you have configured > into them. > - The samples are easy to exclude with the new build. Please enlighten me. I did a build where the only block I built was html. I still got all the samples - except the only blocks sample present was html. I also got a bunch of jars in WEB-INF/lib that I am sure I don't need. > - The documentation is easy to exclude with the new build. Why would I want to exclude the documentation? I just don't want it in my webapp, but I sure need it to write my Cocoon components. > - There is a new target you should investigate which can > handle cleaning > up or inserting anything else you need. See > http://wiki.cocoondev.org/Wiki.jsp?page=CustomConfigTarget > and the liked > xpatch page. I don't want to clean or insert anything else. I build all my stuff in my own project using Maven. We just want to bring in the cocoon framework and use our own web.xml and cocoon configuration files. I NEVER WANT TO TOUCH the cocoon.xconf and sitemap.xmap that are built with cocoon. > > Here is an outline of my own build: Pardon me for being rude, but I really don't care. I will not integrate my project into cocoon (i.e - use Cocoon's build to build my webapp). I WILL integrate the cocoon framework into my project. > > YMMV, > Geoff Howard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
