Well, it's the second impression really... The first was a homepage
containing cryptic release notes and nothing resembling a mission
statement or a Getting Started guide.
In a discussion on the Wicket users list about a different approach I'd
started a while ago, Andreas provided links to some introductory notes
he'd just created, so I thought I'd just give it a try.
- Cloned the git repo, ran mvn install. Compiler error. (due to a bug in
JDK 1.6.0_24, but this is latest official one on Ubuntu :-(
- 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...
- After some trial and error and some dim remembrance of Pax Runner, O
found out that "stop 0" would let me terminate Gogo cleanly, and even
better, pax:provision -Dframework=equinox would run the whole thing in
Equinox. Much better!
- Why does it take what felt like half a minute for the framework to
shut down?
- I opened the samples in my browser, and they all looked ok, but I was
really more interested in the inner workings, so I took a look at the
source code:
- Little or no Javadoc in internal packages, somewhat more but not
enough in the API package.
- Separation of concerns is one of the OSGi mantras, but here we have a
mixture of unrelated things in one project. Supporting both Spring DM
and Aries Blueprint for dependency injection within the same bundle is
not my idea of modular design. Spring DM is obsolete and has been
superseded by Eclipse Gemini. Is there a hard dependency on Aries
Blueprint or can you work with other compliant Blueprint implementations?
- As a consequence, there are lots of optional package imports in the
manifest, which is usually a symptom of a lack of modularity, and also
dangerous, because an OSGi framework is free not to wire an optional
import, even when a matching package is available.
- I think both Spring support and Blueprint support should be refactored
into separate bundles.
- 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.
- Does Pax Wicket let you inject plain old services at all? Without
Spring DM, Blueprint or any other extension of OSGi core?
- At first, I didn't realize that Pax Wicket wraps all of Wicket in its
own bundle - I was fooled by the fact that vanilla Wicket is also
provisioned to the sample runtime. So the good news is that you don't
depend on the broken manifest of the official artifact, but in general I
don't think it's a good idea to wrap your dependencies instead of
importing them.
- 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...
- I'm not sure, but it seems Pax Wicket lets you install pages and
components as separate bundles and mount them into the web context of
your running application - if this is true, then I think that's really
the biggest value in this project and it would be nice to have a Wiki
page explaining the mechanics and giving some pointers into the sample code.
Best regards,
Harald
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
