Let's make sure we are on the same page here (some stuff I read in Sylvain's reply leads me to believe we are interpreting Martin's suggestion differently.)
Here is a new proposal ... 1.) Remove any reference to sandbox from myfaces-all.jar. Zero traces of sandbox in myfaces-all.jar. This means no faces-config, no TLD (including the all TLD) and no class files. 2.) Include sandbox.jar in both the nightly and release builds. This means that there will be no more "-Dskip.sandbox=true" and that the sandbox directories will always be available when building. The sandbox.jar will contain its own TLD and class files. That's how I understood Martin's proposal. Either way this is what I am proposing now. I am prepared to compromise by including sandbox stuff in the distro but my position is that it should not be part of all and that we shouldn't sandbox stuff in with the TLD or faces-config.xml for tomahawk. sean On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > One more thing about those TLDs. > > I find that having one big tld for each project is quite bad, as it's hard > to read and to maintain. It also promotes commit conflicts when 2 developer > are working concurrently on different components. > Maybe a better approach would be to have tld snipsets in each component's > directory, and to generate each tld in the build process. > > Any thoughts about this ? > > Sylvain. > > > On Mon, 2005-09-26 at 14:57 -0400, Sylvain Vieujot wrote: > > I too think it makes sens to release the sandbox into the myfaces-all.jar. > > But if we do that, then this jar needs to contain a faces-config.xml that > merges the ones from tomahawk & from the sandbox (build file, merge-sandbox > target). > The process for merging the faces-config.xml files & the tld is basically > the same. That's why I think of it as a logical step. > I don't see how removing it will improve the code. > I didn't knew we would keep the tld fragments in the sandbox's tld once > they are promoted to tomahawk, and that was the main idea behind the "all > tld". > But, are we sure it's the good solution to keep old components forever in > the sanbox tld. It'll be increasingly hard to maintain and to keep > synchronized with the one of tomahawk. > So, I prefer the path of having an all in one tld, but to clearly mark it > as unstable as it contains sandbox's components. > > Sylvain. > > On Mon, 2005-09-26 at 12:12 -0600, Bill Dudney wrote: > I like this approach too. sandbox.jar is separate but part of the > release. > > I'm equally OK with putting the sandbox stuff into the myfaces- > all.jar with a separate tld (i.e. don't do the 'all' tld). Users wont > be confused because its in a separate tld. > > I don't agree that its a lazy/not lazy thing, its just simpler to > have one jar file with the whole thing instead of multiple. > > TTFN, > > -bd- > > On Sep 26, 2005, at 11:57 AM, Sean Schofield wrote: > > >> Issue 2: making an exception for sandbox in the build: > >> > >> @Sean: Still, I think we shouldn't make an exception to the build for > >> the sandbox.jar when releasing - I'd say we just release it as well, > >> clearly indicating that this is experimental stuff. > >> > > > > I might be persuaded to accept this route. It would certainly be > > easier (we wouldn't have to worry about skipping the sandbox.) > > > > So we would get rid of myfaces all TLD and *not* include sandbox in > > myfaces-all.jar right? Everything would be in sandbox.jar and thar > > jar would be available in both the nightly and release builds? > > > > Is that what you are proposing? > > > > sean > > > > >
