>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > I recently spoke with Gavin King (spec lead for JSR-299) about this JSR. In > addition to getting his agreement on both Matthias and James to be on the > EG, we talked a bit about their (Red Hat's) plans for the RI and TCK. Their > thinking is that the RI and TCK would be developed by Red Hat themselves > (since they are the company responsible for providing it) under some > reasonable open source license ... but Gavin would actually like it if there > was a second implementation being developed at the same time. That kind of > thing goes a long way towards catching design limitations and/or ambiguities > in the spec as it's being developed. > > So, I've got a question for us ... would we be interested (now or later) in > building *a* compatible implementation of this JSR, even though it wouldn't > be *the* RI? Instead, it would be a feature of Shale in addition to all the > other stuff we do. I'm pretty intrigued by this, and the ideas that JSR-299 > wants to deal with fit pretty nicely with what we've already started. It > would make sense for us to have this kind of functionality available inside > Shale. > > If we go this way, this seems like a good candidate for the sandbox during > development (since we wouldn't be able to ship a finished release of it > until the spec goes final). > > What do you think? Are we interested in putting this on our roadmap? (And > following up +1s with code? :-) >
+1 That would be a great addition. How about shale composites :-) > Craig > > PS: Another JSR we should keep an eye on is 303 (common annotations for > validation) that Jason recently submitted. If it gets accepted, we'll > likely want to support the result in Shale as well. Outstanding!
