Hey All, Not trying to be a pain, but I would like to slip in some new functionality before the deadline if possible. I've updated LANG-580 (https://issues.apache.org/jira/browse/LANG-580) to include a patch. The patch adds an interface for registering events, an abstract class for publishing events, and an implementation that uses reflection to post events to methods by name. The patch also includes test cases. This JIRA entry was originally moved back to 3.1 since there wasn't a patch yet, but I'm hoping I got it done in time. If not, just let me know what I need to fix and push it back to 3.1.
Thanks. -Michael On Thu, Jul 1, 2010 at 12:00 PM, sebb <seb...@gmail.com> wrote: > On 1 July 2010 16:29, Henri Yandell <flame...@gmail.com> wrote: >> On Thu, Jul 1, 2010 at 2:13 AM, sebb <seb...@gmail.com> wrote: >>> On 1 July 2010 03:23, Henri Yandell <flame...@gmail.com> wrote: >>>> On Wed, Jun 30, 2010 at 1:38 PM, sebb <seb...@gmail.com> wrote: >>>>> On 30/06/2010, Henri Yandell <flame...@gmail.com> wrote: >>>>>> Here are example tarballs, jar and a site for a 3.0 beta: >>>>>> >>>>>> http://people.apache.org/~bayard/commons-lang-3.0-beta/ >>>>> >>>>> Is this basically the same code as in commons-lang-trunk? >>>> >>>> Yes - exactly the same. >>>> >>>>>> The site isn't intended to be ready - that can be done later. What it >>>>>> does right now is provide the relevant 3.0 reports. >>>>>> >>>>>> What I'd like to know right now is if it looks good and whether I >>>>>> should go ahead and tag 3.0-beta and do a real release build. I think >>>>>> we're ready to build a beta. I don't expect a lot of API change after >>>>>> this, and I don't know of any bugs in 3.0 that weren't in 2.x. >>>>>> >>>>>> So not a release vote, but looking for consensus from anyone (users, >>>>>> committers, pmc) that it's time to put a beta stake in the ground. >>>>> >>>>> In general I agree. >>>>> >>>>> However, I think it is essential to document the intended class >>>>> thread-safety. >>>>> >>>>> For example, the mutable package is not intended to be thread-safe >>>>> whereas concurrent is presumably intended to be. >>>> >>>> If you want to do that, then I can see delaying for a defined time. If >>>> it's just something you think someone else should do, I know it isn't >>>> my priority and not something I'd see as a release blocker for either >>>> a beta or for 3.0 itself. >>> >>> I'm happy to start adding comments to the classes and/or package.html files. >> >> Go for it :) > > I've already done the package files; decided it was quicker! > >>>>> The package.html files also need some work. >>>> >>>> They're pretty tiny, so shouldn't be much [unless you have visions of >>>> writing a lot in there]. >>> >>> Actually, when looked at in context, they are sufficient. >>> >>> Though it might be worth adding some details on thread safety to them. >> >> I think the class files are probably sufficient - having better >> package.htmls would then be a separate task and would presumably >> include covering thread safety. >> >>> == >>> >>> Given that we have changed all the package names, the Clirr report is >>> fairly useless. >>> Is it possible to use it to compare corresponding classes? >>> E.g. maybe use Shade to create a lang3 version of lang2 or vice-versa? >>> Or maybe Clirr has an option to alias classes? >> >> Or simpler; a mv of the lang3 directory to lang then running of the >> clirr report. I've had that setup and running, I just need to put a >> computer back where it used to be post some home improvement and get >> it pushing the page up to people.apache. >> >> Hen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
