Hi Andreas, Continuing this thread from https://github.com/wicketstuff/core/issues/46#issuecomment-1646462.
> I'm not deep into Brix, but the question is: what exactly do you need. I > layed the roadmap as I thought it useful for users. If users step up and say > that they require feature X before feature Y I've no problem to change the > way. The only thing which needs to be finished first is the 0.8 release, > because it contains the entire lot of samples and API changes (the last one > for a longer time I hope). After that (mid to end of August) we can change > the road as required. If you could point me at the relevant parts of Brix > (or explain them to me) and show me how you intend to make this work we can > adapt the order of the issues to your need. BTW, I've registered for the > Brix mailing-list. We can continue this discussion there, on the Wicket or > on the OPS4J lists as you like. This afternoon, I believe I have the final bits committed to Brix for the OSGi imports and exports. It turned out to be far more complicated than I had imagined since Jackrabbit and Lucene are not built as bundles yet. This meant a lot of messy embedding to get things to work. Fortunately, someone on the team had already spent effort localizing Jackrabbit to a single module, so I was able to leverage that work. That work is visible at https://github.com/brix-cms/brix-cms/commit/821307696771299410d3de5a68e36f36ab424c73 and it's following commit where there are some cleanups (commented out stuff removed for easier reading). Regarding what Brix needs to use Pax Wicket, some idea of the basic architecture might help. As it stands, Brix master is a monolithic webapp broken down into about eight different Maven modules. Brix plugins are additional Maven modules -- essentially Wicket components with additional metadata that makes them renderable from data in a JCR (i.e. Jackrabbit) tree. In this manner, web content can be stored in the JCR tree, but that content can be augmented by Wicket components that provide dynamic functionality. This works spectacularly well for sites where the dynamic components in the site are relatively stable, since the content can be changed at will by content owners, mix and matched with dynamic components, and developers are not bothered with constantly building new versions and redeploying the server. In practice though, the components need to be tweaked pretty regularly, leading to a lot of extra overhead for small sites that wish to have high uptime. By this I mean that the sites need to be replicated and the servers redeployed one-by-one behind a load balancer. On the other hand, if components could be intelligently redeployed as services within an OSGi container, restarting should be a thing of the past, and smaller sites can dramatically reduce complexity by sticking with a single server that is directly connected to the internet. A lot of other features are also possible. So that should frame the needs of the project from the technical side. From a scheduling side, time is kind of tight to get this done. We're starting new projects with Brix and of course want to use these projects to add robustness to the public implementation. That being said, I'm comfortable that there's going to be far less risk moving forward now that the bundles have been defined, since major changes to module contracts are a lot of work to carry over to external projects. Whether or not the container can load or unload components at runtime is something that can be kicked down the road a bit (although I'm also excited to toy with it asap!) > > One of the challenges around OSGi is there are so many helpful solutions > > out there, some of which are not the best choice for new projects. Many of > > them are competing and many are complimentary. It's not always clear how > > they fit together, or sometimes if they are even still relevant. PW may be > > the "Victorinox of Wicket under OSGi", but if I can't figure out which > > blades to use and which ones to ignore (as in the parts that are used for > > deprecated environments) and do so in bounded time, I'm kind of back to > > square one. And like any open source dependency, one can't set expectations > > where one cannot make substantive contributions. > I've worked hard on this and the next (and hopefully almost final version of > the PW API) is much clearer and easier to understand as you might like to > convince yourself (JDoc will be completed soon too): > > https://github.com/ops4j/org.ops4j.pax.wicket/tree/master/service/src/main/java/org/ops4j/pax/wicket/api A few points of note on the API: 1. It would be great if PW could act as a catalyst for adoption of JSR-330. Harald's work also used this and lacking any impossible technical hurdles, we ought to use it for future compatibility. 2. IRequestCodingStrategy has been replaced by IRequestHandler. It's not terribly difficult to translate between them, but will likely result in a code base branch for PW. I don't think these are at all insurmountable. With some pointers to a working sample app that exercises some or all of the PW use cases, I may be able to grok what's going on in there and help with a branch. > > > > While I would hope to find that the sample app would present current best > > practices (and presume it will since the project is seeing a lot of > > investment), I'm still blocked on the 1.5 issue. > > > > Harald's work is very concise and it sounds like you've reviewed it. While > > it may be "missing a lot of the blades", it has a great foundation, and I > > can start with it now. > > > This is not so completely true. With Haralds approach you might do some > minor use cases, BUT there are various problems. For example: > Pages/Components could not be loaded via services; injection is only based > on OSGi services; internal Pages/Components could not be used. Serialisation > over bundle level is not solved. Serialisation of Bundle/Application > references are not solved. It does not run on plain OSGi HTTP services. > Please don't get me wrong. This is NOT against Haralds work. In neither way! > He did a great job in getting a minimal working solution up and running. The > only thing I'm talking about is that this wont be enough to get any real > application up and running where Components, Services, Injection and > Serialisation is splitted over multible bundles. If you like to do such > things you'll need something very similar to the PW core (and this is the > entire thing I'm talking about all the way :-)). Yes, I apologize that I may have written in a way that was hard to interpret. I completely appreciate that there are likely to be a large number of missing use cases as well as that wicketstuff-osgi is missing a lot of features and may have significant structural problems that are mostly resolved by PW. But to my point earlier, getting something running such that the bundle dependencies can be exercised and everything is in approximately the right place would help with immediate development. In other words, immediate forward motion is a primary concern for current stakeholders, even if I have to circle around and do it all again later (it's a good learning experience, for sure...) > > For the examples: This is one of the big goals for 0.8. By now I extend the > examples almost every day. Examples for Components in various bundles will > come by tomorrow or latest Thursday. Examples (and the documentation) are > available already for getting the things up and for injection. While > everything else is also running already I plan to finish all samples by end > of next week. Still, the quickstart guide (those things I think are most > interesting for most users) is already finished: > http://team.ops4j.org/wiki/display/paxwicket/Quickstart. Feedback is very > welcomed here. All samples and explanations work with the latest master > (guaranteed by pax-exam integration tests). Ok, I'll try to dig into your work. I did read some of the quickstart and it's a little hard to read for native english speakers. I'd be happy to help with edits in that regard. :-) > > As for the path to getting this integrated into Wicket, one of the things > > that I've seen time and again in Wicket is a resistance to complexity in the > > core. It's both why we have such a great framework and why getting OSGi in > > there may be a challenge. I don't know what the answer to this is, "one > > step at a time" is the best one I have for now. I'd like to believe Brix is > > a pretty good proof-of-concept for doing such an integration. > > > > I don't know if that background is helpful. I think I would use PW if > > 0.10.0 was out, and if I was a little further on the learning curve, would > > help try to make it a reality so we could all use it. And if the conversion > > over to PW makes sense at a later time, I'm all for it as well. > > > It's definitely not too early. I push PW 0.8 with all available free-time > trying to make the road clear to move in every direction required. If we > start talking about this now it is quite possible that a try to port Brix > based on PW 0.9 is already possible. I'm completely with you that more more > then "my own" proof-of-concepts and use cases are required to bring PW to a > broader base of users. So it would be very appreciated if we could continue > the conversions although PW 0.8 might not be a perfect fit for Brix. I'm very agnostic to how the problem is solved, I just need to get it done. wicketstuff-osgi also has the advantage that I have commit access there, so changes that are needed can be very easily implemented. I'm not religious about anything, but I am "lazy" and take the path of least resistance in all cases. :-) Cheers, B > > > > This discussion is very vital, please don't hesitate to ask if there's > > anything I can offer. > > > I think I did so already and hope for further responses ;-) > > Kind regards, > Andreas
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
