Hi Elijah, Bricklaying is indeed harder that it seems, fortunately already experienced friends of mine are helping me - above all because I have a huge amount of work :P
I suggest you taking care about checkstyle errors once we have applied the generics patch - here at commons we tend to avoid massive commits that contain a large number of modifications, what I suggest you is adding new issues on JIRA where attaching new patches. I promise you I'll do some work during the weekend in order to review the patch and propose the upgrade - I'm not worried abou its acceptance, but every single decision here at ASF must be discussed and accepted before proceeding. Thanks a lot for your efforts and keep rockin'!!! All the best, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Aug 18, 2011 at 11:31 PM, Elijah Zupancic <eli...@zupancic.name> wrote: > Simo, > > Bricklaying is one of those things that seem simple, but actually can > be a bit complex. So, I hope you are having fun with your project. > > I just ran clirr against the 1.3 version and it showed only additions. > So, from its perspective it is backwards compatible. However, for the > one line that is incompatible, I believe that it is incompatible > because of a bug in the existing version. Do you think that it > warrants a deprecated annotation? > > Now, I just checked the check-style plugin report and it looks like I > will need to update the patch so that I get 0 check style errors. I > should have that updated this weekend. > > Thanks, > -Elijah > > On Thu, Aug 18, 2011 at 5:44 AM, Simone Tripodi > <simonetrip...@apache.org> wrote: >> Hi all/Elijah, >> sorry for replying so late but during these days I've been working as >> bricklayer at home, fixing some stuff :P >> >> About the binary compatibility breakage, I have a (maybe silly, >> hopefully not) idea: marking @Deprecated (and justifying why in the >> javadoc) the wrong method and adding the new correct one, if possible >> (take in consideration I'm not 100% familiar with chain so maybe I'm >> just inventing). >> >> That for the purpose to have 100% binary compatibility. Did you try to >> enable the clirr-plugin[1] for maven to see which are the differences >> with the previous chain version? >> >> Many thanks in advance, hope to hear from you soon!!! >> Have a nice day, all the best, >> Simo >> >> [1] http://mojo.codehaus.org/clirr-maven-plugin/ >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Wed, Aug 17, 2011 at 7:06 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>> BTW, please don't take the previous response as indicating any >>> negativity on my part. Feel free to prod us as long as possible, at >>> reasonable frequency. >>> >>> Matt >>> >>> On Wed, Aug 17, 2011 at 12:04 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>>> Be patient, while not being so patient that you allow us to forget it. >>>> >>>> Matt >>>> >>>> On Wed, Aug 17, 2011 at 12:01 PM, Elijah Zupancic <eli...@zupancic.name> >>>> wrote: >>>>> Hi Matt and Simo, >>>>> >>>>> I've attached the patch to the bug and fixed the issues mentioned with >>>>> faces. >>>>> >>>>> What other steps do I need to do now? >>>>> >>>>> Thanks, >>>>> -Elijah >>>>> >>>>> On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson <gudnabr...@gmail.com> wrote: >>>>>> Hi, Elijah-- >>>>>> >>>>>> I am neither a develop nor even a user of chain, so my comments will >>>>>> be high-level. Firstly, by all means upgrade to whatever JUnit 4 >>>>>> release version you like, e.g. 4.8.2. Next, I personally am a big fan >>>>>> of Mockito, so no complaints here on that account. I can't guarantee >>>>>> noone else would complain, but [chain] has been fairly unloved for a >>>>>> good while. As for JSF 2.1, is there something this achieves that >>>>>> wouldn't be equally well accomplished by simply upgrading to 2.0? >>>>>> This would give [chain]'s JSF support (which I personally hadn't >>>>>> realized existed) a potentially better combination of >>>>>> doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest >>>>>> possible applicability. >>>>>> >>>>>> Finally, as you don't seem to be a committer your final submission in >>>>>> this regard would be best recommended in the form of a JIRA issue, and >>>>>> your patches in (albeit large) patch form. In addition to this, the >>>>>> scope of these changes indicates it best IMO that you submit an >>>>>> Individual Contributor License Agreement governing your contributions >>>>>> to the ASF. See http://www.apache.org/licenses/#clas for details on >>>>>> how to do this. >>>>>> >>>>>> Regards and welcome, >>>>>> Matt >>>>>> >>>>>> On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic <eli...@zupancic.name> >>>>>> wrote: >>>>>>> I've just finished my proof of concept for an upgrade to Apache chain. >>>>>>> I would love to get this into a svn branch. I'm not quite sure what >>>>>>> the procedure is to do that, but the code can be found here for >>>>>>> review: >>>>>>> >>>>>>> http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz >>>>>>> >>>>>>> And here is a diff: >>>>>>> >>>>>>> http://elijah.zupancic.name/projects/uber-diff >>>>>>> >>>>>>> At a high level, I have incorporated the following features in this >>>>>>> proof of concept: >>>>>>> >>>>>>> * Global upgrade to the JDK 1.5 >>>>>>> * Added @Override annotations >>>>>>> * Upgraded to the Servlet 2.5 API >>>>>>> * Upgraded to the Faces 2.1 API >>>>>>> * Upgraded to the Portlet 2.0 API >>>>>>> * Upgraded the Maven Parent POM version >>>>>>> * Added generics support to Command so that Command's API looks like: >>>>>>> >>>>>>> public interface Command<T extends Context> { >>>>>>> ... >>>>>>> boolean execute(T context) throws Exception; >>>>>>> } >>>>>>> >>>>>>> * Servlet and Portlet packages now provide Genericized APIs. >>>>>>> * All dicey changes have been marked with a comment with my name: >>>>>>> (elijah) >>>>>>> >>>>>>> More or less the work to updated Chain was straight forward albeit >>>>>>> time consuming. >>>>>>> >>>>>>> If everyone is on board for this update, I would like to upgrade the >>>>>>> test cases to use a new version of JUnit. However, this leads to a few >>>>>>> questions: >>>>>>> >>>>>>> * What version of JUnit should I use? >>>>>>> * Would it be ok to use Mockito for mocking instead of the home grown >>>>>>> mocking classes already contained in the project? >>>>>>> >>>>>>> Please let me know what you think. Getting this far has been a couple >>>>>>> weeks worth of on and off work. >>>>>>> >>>>>>> Thanks, >>>>>>> -Elijah >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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 >>> >>> >> >> --------------------------------------------------------------------- >> 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
