> Having multiple jar files increases the chance of one of the jar files > being out of sync with another one of the files. I'd imagine that > the sandbox components are often dependent on a specific tomahawk > version.
Its not possible for them to be out of sync during the build and in the release bundles. That's all automated. I suppose its possible that someone might replace myfaces-all.jar and forget to replace sandbox.jar but its also possible that someone might accidentally update myfaces-api.jar but not myfaces-impl.jar. I don't really buy this line of reasoning. > > > On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > > Hello Sean, > > > > It's not a question of laziness. > > As said before, having one common jar is very useful when you develop a > > component there, and when it's moved in production later. > > I don't agree excluding it just because there was an unfortunate bug that > > hasn't been fixed in time for an important release. > > And the build process isn't that complex either. > > > > As for the confusion, I don't think our users are so stupide to have any > > confusion here. It's pretty clear I think. Furthermore they'll have to > > explicitly choose for this option, so when they do it they'll be fully > > aware. > > And we can put some more warnings it you think it's necessary. > > > > But to me this option is really very useful and will help raise the number > > and quality of the sandbox's components before moving them to tomahawk. > > > > Sylvain. > > > > > > On Sun, 2005-09-25 at 20:36 -0400, Sean Schofield wrote: > > I don't see how excluding sandbox stuff from myfaces-all.jar will take > > anything away from our users. If you want to use the sandbox stuff > > you just need two jars: myfaces-all.jar and sandbox.jar. > > > > Putting everything in myfaces-all.jar just allows you to be lazy and > > use one jar and one TLD. That convenience comes at a cost. The > > downside is confusion to our users because the jar is missing the > > sandbox stuff when released but its in the nightly. It also is a > > massive headache as far as the build is concerned and we have already > > seen how that has lead to a problem in the release. > > > > I like Sylvain's suggestion of excluding the sandbox from the build by > > default but I would go one step further and exclude it from > > myfaces-all.jar. Isolate the sandbox stuff in its own jar but make it > > available by building the source or downloading the nightly build. > > What is the problem with that? (other than a little extra work for the > > smaller groups of users using sandbox stuff) > > > > My 2 cents. > > > > sean > > > > > > > > On 9/25/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > I agree with Sylvain that the convenience of having all in a single > > > jar, with an according TLD is a good thing. > > > > > > I also agree with Sean that the sandbox is something that might be > > > unstable and insecure and should be considered as such by our users. > > > > > > Still, after very careful consideration, I think we should not take > > > away the possibility of our users to test and improve the sandbox, > > > knowingly doing so as the immaturity of the sandbox is clearly > > > published. > > > > > > Proposal: we clearly mark the sandbox as experimental (as we do of > > > today, and people seem to very well understand that) and do the same > > > with the sandbox as with tomahawk - create a jar, include it in the > > > myfaces-all.jar > > > > > > I think that our problems stem from making exceptions and extra work > > > in the build process, and not from including the sandbox just like the > > > tomahawk stuff. > > > > > > I believe we should put the work in defining the contract to our > > > users, and not in tweaking the build process! > > > > > > ... and I'd like to hear John Fallow's opinion here - the Oracle guys > > > are putting a lot of effort in their deployment and building process, > > > let's see what his opinion on this would be. > > > > > > regards, > > > > > > Martin > > > > > > On 9/25/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > > > > I'm not talking about shipping this in the releases, but for those that > > use > > > > the head, I think it's a good think as it'll improve the code of the > > > > sandbox. > > > > And those that'll use it will do it knowingly. > > > > > > > > So, I don't see this as a risk. Rather as a very useful option for the > > > > developers and advanced users. > > > > > > > > > > > > On Sat, 2005-09-24 at 22:34 +0200, Bruno Aranda wrote: > > > > I am not sure about that... if you do it too easy people will begin to > > > > use sandbox components in their production applications, and sandbox > > > > components are unstable by nature. It is better to promote a sandbox > > > > component to tomahawk once is mature, so people can use it in their > > > > applications. IMO, people will begin to miss the difference between > > > > the sandbox and tomahawk... > > > > > > > > My two cents, > > > > > > > > Bruno > > > > > > > > 2005/9/24, Sylvain Vieujot <[EMAIL PROTECTED]>: > > > > > With a separate sandbox, you can't have use <%@ taglib > > > > > uri="http://myfaces.apache.org/all"; prefix="x" %> > > > > > So, when a component moves from the sandbox to tomahawk, you have to > > > > change > > > > > all your tags. > > > > > > > > > > Also, for those like me who uses all the component, it's the same > > > > arguments > > > > > as using separate jars, or the myfaces-all.jar > > > > > > > > > > Except for the bug on release, preventing from using a myfaces-all > > like > > > > > jar, with the sandbox would be a big inconvenient. > > > > > I think it would just make it a bite more difficult to use the sandbox > > > > > stuffs, and gives less incentive in putting a new component there. > > > > > > > > > > An example is the fieldset component that I just did. > > > > > It's very easy to do, and doing it in the sandbox isn't a problem now > > > > > thanks to this taglib uri="http://myfaces.apache.org/all"; stuff. > > > > > Without this, I don't think I would have done it because it would be a > > > > mess > > > > > to use s: mixed to t: tags, and moving it later to tomahawk would have > > > > > broken my apps. > > > > > I would just have used the old htmlTag workaround instead. > > > > > I also started using and contributing to the inputSuggestAjax for the > > same > > > > > reasons. > > > > > Otherwise, I don't think I would have used it in real applications. I > > > > would > > > > > just have waited for it to be in tomahawk. > > > > > > > > > > Keeping things separate is usually a good thing, but in this case, we > > > > > should keep this flexibility. > > > > > It doesn't force the use of it and makes life much simpler. > > > > > > > > > > I really don't care on how we achive this. Replacing the skip.sandbox > > by > > > > an > > > > > include.sandbox seems the most straight forward, but even if we do a > > > > > separate target, or even a separate build file, I'm fine as long as we > > > > keep > > > > > this possible. > > > > > > > > > > Thanks, > > > > > > > > > > Sylvain. > > > > > > > > > > > > > > > On Sat, 2005-09-24 at 12:11 -0400, Sean Schofield wrote: > > > > > I agree that maybe we should exclude the sandbox by default. Other > > > > > than that, I disagree. I don't see any real advantage of mixing the > > > > > sandbox stuff into the other jars. I think it should be kept separate > > > > > and for those who want to use sandbox stuff before its released, just > > > > > add the extra sandbox.jar. What would be so hard about that? > > > > > > > > > > sean > > > > > > > > > > On 9/24/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > > > > > > As for the relases, you're right. > > > > > > But I also see great value still having a single jar with > > everything. > > > > > > I allows seamless migration from the sandbox to tomahawk. > > > > > > As such, it allows us to really test the sandbox. > > > > > > Otherwise, I'm afraid the components in the sandbox will be really > > less > > > > > > used and tested. > > > > > > > > > > > > So, I see several alternatives : > > > > > > 1) The first, which would be my favorite, is not to have a > > skip.sandbox, > > > > > > but rather an include.sandbox value (and omit it by default). > > > > > > 2) Make 2 targets : One that would generate the myfaces-all.jar with > > the > > > > > > sandbox, and one that would generate it without > > > > > > 3) Have 2 jars : myfaces-all.jar, and myfaces-all-withSandbox.jar > > for > > > > > > example. > > > > > > > > > > > > The fact that we have a single tld for example allows us for example > > to > > > > > use > > > > > > the x: prefix for every component (whether in the sandbox or not), > > and I > > > > > > think this is really important. At least, it is for me. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Sylvain. > > > > > > > > > > > > > > > > > > On Fri, 2005-09-23 at 13:20 -0400, Sean Schofield wrote: > > > > > > Apparently there is a problem with faces-config.xml in > > myfaces-all.jar > > > > > > of the current release. All of this confusion seems to be coming > > from > > > > > > the fact that sandbox is in myfaces-all.jar in the nighlty but not > > the > > > > > > release. We have the -Dskip.sandbox option and a bunch of other > > hacks > > > > > > in the build to make everything work the way it is now. > > > > > > > > > > > > I propose that we not include the sandbox stuff in the > > myfaces-all.jar > > > > > > anymore. I was always against this and I think the resulting > > > > > > confusion and series of hacks outweighs the argument of those that > > are > > > > > > lazy and don't want to include two jars in their ongoing projects. > > > > > > > > > > > > Sandbox is untested, undocumented, unvoted and unreleased code. It > > > > > > deserves its own jar with its own tld. Its already excluded from the > > > > > > release build (which I believe is correct) but the myfaces-all.jar > > in > > > > > > the nightly should mirror whats in the release. > > > > > > > > > > > > So the proposal is that dist-all generates a separate sandbox.jar > > with > > > > > > its own faces-config.xml and its own sanbox.tld. > > > > > > > > > > > > I propose we do this *before* any patch release. Also this will not > > > > > > affect SVN. It will be a build change only. > > > > > > > > > > > > sean > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > http://www.irian.at > > > Your JSF powerhouse - > > > JSF Trainings in English and German > > > > > > > >
