Hi, guys,
Sorry to jump in so late. (Very, very late.... hmmmm)
I just wanted to say that I think there are 3 reasons why there hasn't been
much activity until it was picked up again recently from Andreas:
1. Conceptually difficult
2. Not much publicity / documentation / market
3. Very functional
1: Niclas Hedhman and Edward Yakop wrote the original codebase several years
ago. It has an interesting, but not-so-intuitive design. There are some good
docs that explain the concepts, but I think for most people, it's difficult to
wrap one's mind around it. Personally, I don't even use many of the concepts.
I've found that when I try to be too "smart" about things, when I need to
maintain the code years later, I always spend too much time trying to figure
out the "smart" code, so I prefer "dumb" but easy-to-understand code over smart
stuff. I find pax-wicket very useful even without those "smart" concepts,
though. YMWV.
2. I think the wicket + osgi user base is only starting to gain traction now.
pax-wicket was a little ahead of its time, so I'm not surprised that there
wasn't much interest. Now that more people are looking into the wicket + osgi
combo, I think there will probably be more interest in a project like
pax-wicket.
3. pax-wicket does exactly what I need it to do, so except for a few tweaks
here and there, I have been a 100% satisfied customer. Everything I do is based
on pax-wicket. Again, YMMV. Obviously, Andreas found that it was lacking.
Thanks to the open and low-barrier culture in ops4j, he was able to just pick
it up and run with it.
I've been looking forward to trying out the newer versions by Andreas; haven't
tried yet, so I can't comment. (I think I must be getting to be an old fart, as
I need to make a lot of changes, including the move to git that everybody else
seems to have already done... Anyway, I'll get there someday soon, I think, if
I can ever make the time.)
Brian and I started looking in to OSGi-yfing Wicket, sorry, Brian, I totally
dropped that ball. If we ever do get Brix bundleized, that would be truly
super. I'm really looking forward to being able to integrate Brix with my stuff.
Anyway, just a few random comments from a long-time pax-wicket user. Sorry that
I've fallen so far behind, not just in this thread, but in the development as
well.
I think what you guys are doing is great! Look forward to seeing where this
leads. Thanks for all your fabulous efforts. :-)
Cheers,
=David
On Jul 28, 2011, at 11:20 AM, Andreas Pieber wrote:
> Since we've discussed already about the mount points and the reference in
> NoBeanAvailableForInjectionException and PaxWicketInjector are only a
> documentation reference (which could be removed) we're left with the
> following three dependencies:
>> import org.apache.wicket.Application;
> Application.get().getApplicationKey();
>> import org.apache.wicket.Page
>> import org.apache.wicket.PageParameters;
> public interface PageFactory<T extends Page> {
> Class<T> getPageClass();
> T createPage(PageParameters params);
> }
>
> The question now: How often will they change (how often will we have to
> release a major version of PW no longer backward compatible in this case).
> Maybe just a feeling, but my guts are crying at me that if those classes and
> their usage changes it would be definitely a good idea to break backward
> compatibility and release another major release of PW. In addition I don't
> think this will happen too often (had happened by now). WDYT?
>
> Kind regards,
> Andreas
>
> On Wed, Jul 27, 2011 at 23:44, Brian Topping <[email protected]> wrote:
> Hi Andreas,
>
> Never worry about me anyway, I'm patient.
>
> Here's what I was looking at in the API folder:
>
>> Targets
>> String 'org.apache.wicket'
>> Found usages (8 usages)
>> InjectorHolder.java (1 usage)
>> (21: 8) import org.apache.wicket.Application;
>> MountPointInfo.java (1 usage)
>> (18: 8) import
>> org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy;
>> NoBeanAvailableForInjectionException.java (1 usage)
>> (19: 55) * Since the {@link
>> PaxWicketInjector#onInstantiation(org.apache.wicket.Component)} method does
>> not have a return value
>> PageFactory.java (2 usages)
>> (18: 8) import org.apache.wicket.Page;
>> (19: 8) import org.apache.wicket.PageParameters;
>> PageMounter.java (2 usages)
>> (20: 8) import org.apache.wicket.Page;
>> (21: 8) import
>> org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy;
>> PaxWicketInjector.java (1 usage)
>> (18: 8) import org.apache.wicket.Component;
>
> This is from org.ops4j.pax.wicket.api. Am I on the wrong path?
>
> Cheers, B
>
> On Jul 27, 2011, at 4:17 PM, Andreas Pieber wrote:
>
>> Hey Brian,
>>
>> Sorry for the short answer but I'm more the kind of early bird, so no longer
>> in front of my PC.
>>
>> Just one point here: y do you think that? The plain api in the api package
>> does not really depends on wicket. The util and the internal part will be
>> splitted into the impls (and the inject components). I have not tried by now
>> but I don't see any problems. Afaik without the code in front of me the api
>> is only dependent on the page class which is not likely to change and mount
>> part will be splitted. Anything i've missed?
>>
>> Btw, no problem at picking it up! Just thought it would be easier after 0.8
>> is finished :-)
>>
>> I'll write a full answer in about 6 hours after a little bit of sleep :-)
>>
>> Kind regards, Andreas
>>
>> On Jul 27, 2011 9:18 PM, "Brian Topping" <[email protected]> wrote:
>> > Hi Andreas,
>> >
>> > On Jul 27, 2011, at 1:03 AM, Andreas Pieber wrote:
>> >
>> >> wicket-bundle-parent as osginized wicket (removed from service)
>> >> pw-api
>> >> pw-14-impl
>> >> pw-15-impl
>> >> pw-spring
>> >> pw-aries
>> >> pw-osgi (to come)
>> >> pw-geronimo (to come)
>> >
>> > Ok, unless I'm missing the boat, this won't work. Problem is a bunch of
>> > the API interfaces depend on Wicket, which of course is going to vary
>> > between implementations.
>> >
>> > Since it doesn't make a lot of sense to have separate API projects, I'm
>> > going to duplicate them across the implementation projects until we have a
>> > chance to consider it more completely.
>> >
>> > I just found the IRC channel, will be on there as I can...
>> >
>> > :B
>> _______________________________________________
>> general mailing list
>> [email protected]
>> http://lists.ops4j.org/mailman/listinfo/general
>
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
>
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
