First of all, each vote should not count equal, the two (Janne/Andrew) that contribute by far the most should have a the most weight, they both have strong opinions, unfortunately they are not equal. My vote is not worth that much, but I don't want to stay completely quiet.
ITEM 1: - I understand it is necessary, if it would be up to me it could be done right now, the JCR stuff can be committed to the trunk if that relieves Janne from the merging pain (3.0.0 does not work anyway right now). Perhaps Craig should tell us how "urgent" it is because of the incubation proces. Janne should advise us about this, if JCR is committed to the trunk, can we help make it work ? Or will it stay broken for months. ITEM 2: Let's just start with that, begin with the most obvious ones and keep an eye on each other so that we don't exaggerate it. ITEM 3: I really don't understand why this is so important, in a separate package or not. It is more important to store these classes/interfaces in a separate jar file, so that other developers only put this jar on their java compile classpath. If we make a decision now, we can evaluate after a couple of months, and then make a final decision ? If you agree on some of these points, let's make a clear appointment with a real date, when to evaluate. regards, Harry 2008/12/30 Janne Jalkanen <[email protected]> > Janne's reply regarding timing of the rename is worth respecting. I would >> like to see more communication to the group regarding the expected >> conclusion of the JCR work. I would not like to see JCR delay the project >> for more than a couple of months. One reason for a community of folks >> working on the project. So while there's no need to rush things that are >> coming up quickly, we should try to avoid losing momentum. >> > > *shrug* > > I can commit the JCR work to trunk right away. > > It just doesn't work, that's all. > > Refactoring interfaces from classes needs a corresponding class factory. >> Has this been thought through? There are good reasons for interfaces with >> factories, primarily driven by needing multiple independent implementations. >> But classes with exernally-written subclasses are also a good approach if >> most subclasses just need to change a small bit of behavior. >> > > Correct, and we use that pattern with filters, for example. > > Splitting the stable interfaces apart from the implementation doesn't >> necessarily need a new package name. Either org.apache.jspwiki or >> org.apache.jspwiki.api could be used. >> > > And the question is which one... > > /Janne >
