Am 06.07.2011 09:00, schrieb Andreas Pieber:
OK, sorry for the delay but long mails typically imply some work at least :)
Sure - and thanks for taking the time to answer my questions.
- I used Eclipse to compile the project and then ran mvn pax:provision.
- The sample started with a bunch of DEBUG messages and finally presented a
Gogo shell prompt. Now Gogo is just about the ugliest thing I've seen ever
since vi. No help and absolutely no usable documentation on its official
homepage. I tried "help", "exit", "close", "stop", "^D", no success. With
^C, I got back to my bash, but then I could restart the sample, apparent due
to a socket timeout or a background process still running...
Well, gogo& pax-construct. Sorry somehow I didn't want to provide a
gogo/construct instruction here.
Of course - I know Gogo is not part of Pax and I didn't expect anything
like that.
It's the Felix Gogo team who should do some homework and provide a
decent help function in Gogo itself and a Quick Reference on their website.
I took an instant dislike to Gogo when Glassfish 3.1 (which runs on
Felix by default) switched to Gogo all of a sudden, and as long as
Felix/Gogo don't improve their usability, I'll simply stick with Equinox.
The point I'm trying to make: a casual user of a piece of software
typically is not able or willing to correctly attribute any usability
issues to the main product or to one of its dependencies.
And this may be enough to turn this would-be user away from your project
and help confirm the prejudice that "OSGi is too hard for the average user".
- I think both Spring support and Blueprint support should be refactored
into separate bundles.
Well, you're stating the obvious. And still; it was something which
was not bothering me during the cleanup and extension of the old
pax-wicket through pax-wicket-0.6 and 0.7. Everything at it's time...
Now that things are really working (and I have valuable integration
tests showing this on on some of my larger projects) I'm brave enough
to start the internal refactoring (and splitting) of this framework...
We seem to agree on the strategic vision :-) I don't know anything
about the history of Pax Wicket and how much time you've spent working
with it before becoming the project lead, and of course you have to keep
it working and for existing users and make it better at the same time.
So I assume you know Pax Wicket inside out, but from my outside-in
perspective, the question is whether this is a project I should work
_with_ or even work _on_ or maybe neither, because it does a lot of cool
things but not really the ones I'm currently looking for.
Anyway, I'd be happy do discuss some of the internals in more detail,
and if there's a better place for this than this General list, just let
me know.
- Oh no, @PaxWicketBean - yet another injection annotation...
Why not simply use JSR-330 @Inject plus optional @Qualifiers? This would
give users the freedom to reuse their page or componenent bundles in plain
old WARs with CDI or Spring injection.
True; for the first inclusion of the injection framework I wanted
something as similar as possible to wickets SpringBean annotation. Now
that I know how this should look like and work for spring and
blueprint we can replace it with the JSR-330 annotation. Though
@Inject and @Qualifiers wont be enough. We'll also require @Named (you
cant inject by type from a blueprint context; only by name) and @Scope
(although in a spring-context (which I can autodetect) you may like to
inject plain osgi services or from a blueprint context in the same
bundle (spring& blueprint can live side-by-side)... Still I think
this is a good idea and should be quite easy: PAXWICKET-186.
Yes of course, @Named is also part of the game - I just mentioned it
pars pro toto to promote JSR-330.
By the way, there's a project trying to integrate CDI and OSGi, which
looks very interesting - it's still on my list of things to try...
https://github.com/mathieuancelin/weld-osgi
- Does Pax Wicket let you inject plain old services at all? Without Spring
DM, Blueprint or any other extension of OSGi core?
Since I had no use-case for this I had completely forgotten about this
feature :).
There's enough OSGi projects around built on plain OSGi core. Look at
Eclipse... In my old project, we'd moved from Activators to Declarative
Services, but we never used any DM or Blueprint.
- From the intro:
"Develop the easiest possible solution to integrate wicket with OSGi"
Well, I challenge you on that: wicket-osgi has 5 or 6 tiny classes which are
sufficient to support WABs with Wicket and OSGi service injection via
@Inject. Sure, Pax Wicket can do a lot more - but I was just looking for a
meal, and I didn't want to buy the restaurant...
Basically true. But some points here
1) Size does not matter in this case IMHO. "Easiness" from a user
point of view is not described at the size of a bundle but rather at
how easy it is to use and if it gets into your way.
I agree - this time, I was taking the developer perspective, not the
user perspective.
3) You're right currently wicket-osgi consists only of 5-6 small
classes. Still if you follow the requirements on the mail thread on
the wicket user list closely you know that this is not enough. To
support the entire serialization and injection stuff throughout
multiple bundles you'll end up with something REALLY similar to
pax-wicket. And I don't think that this is worth re-inventing the
wheel (although the existing wheel needs some fine-tuning).
Absolutely - I haven't got round to running my own examples with Pax
Wicket yet. Depending on the experience, there may be the following options:
1) It just works for me, and then there'd be no point in maintaining
wicket-osgi.
2) There is some mismatch, but refactoring Pax Wicket appears easier
than extending wicket-osgi.
3) The devil is in the details and cherry-picking things from Pax Wicket
into wicket-osgi as a kind of clean room reimplementation is more promising.
OK, long mail - long reply :) Thank you nevertheless for the detailed
report and I hope I was able to answer at least some of your
questions/tackle some of your problems. In addition I tried to
structure the roadmap for pax-wicket 0.8.0 according to the (as I have
to agree important points) mentioned in this mail. If you point your
browser to
http://ops4j1.jira.com/secure/VersionBoard.jspa?type=VB&selectedProjectId=10030&selectedBoardId=10681&colPage=1
you'll see the roadmap in the structure I think we should work on it.
After you log-in you should also be able to move issue up or down to
define their order. Feel free to add issues; add your comments to some
or re-prioritize them.
Fine - I'll take a closer look at that, hopefully this weekend!
Cheers,
Harald
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
