On Jul 27, 2011, at 1:03 AM, Andreas Pieber wrote: > Hey Brian, > > On Tue, Jul 26, 2011 at 23:32, Brian Topping <[email protected]> wrote: > <snip/> > Understandable :-) I've scaned the changeset and the Brix code but TBH while > I understand what it should do I'll need a little bit more time to understand > the how in detail. I'm not quite sure right now what you like to achieve.
That's kind of you to look and if the project interests you, I'd be happy to give what I can to help you get better insight on the guts of it. But in general, if you took that deep an interest in every project that needed PW, I don't see how you could pay your rent every month! Let me formulate better questions through real code instead of leaving it for you to resolve. > Am I right assuming that you want to do something like: Brix provides a(n) > (I)BrixPlugin Interface with methods such as "Component > giveMeTheLogicToThisJCRNode(node)". Clients implement them and export them > with some additional parameters as OSGi services. Brix has a ServiceTracker > listening for all available services and call them all? In this case I'm not > quite sure where annotations come into play. Do you want to provide a "plain" > OSGi solution for the core or base it on e.g. Blueprint? Yes, this is the gist of it. As far as an implementation of it, sadly there are going to be folks that just want to keep linking statically. So whatever gets cooked would ideally allow for operation in such an environment. One possibility is something like a static service tracker that gets executed at startup in the static environment and can leverage unified plugin metadata. Beyond that, whatever is the current best practice for new environments probably makes the most sense. > > 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. > > Basically PW does not care much about the annotation. The only thing I want > to avoid here is to replicate all the Proxy and lookup code already done by > e.g. Aries. I have to take a look if I can embed some components here... Yes, of course. Just taking advantage of "beginner's mind" and asking for what seems obvious rather than what seems easy. > > 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. > > You're right. There seams to be no IRequestCodingStrategy any longer in the > Wicket master. Before this can be changed PW have to be splitted into the > following projects: > > 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) > > For this special case I think we may like to remove the RequestTarget from > the PageMounter and MountPointInfo interface. That way the simple > Bookmarkable usecase will run on both implementations. If you need to use the > more advanced use cases you can use interfaces extending PageMounter in > pw-14-impl and pw-15-impl. > > A sample using the current way will come quite soon. I'll update you once it > is finished. Still, technically it is quite simple: When an application > starts we also start a ServiceTracker [1] which adds/removes mount points as > they come/go. We'll have to have two different implementations in pw-14-impl > and pw-15-impl. Any additional hand on this, (ASAP I've splitted the > projects) will be very welcomed :-). > > [1] > https://github.com/ops4j/org.ops4j.pax.wicket/blob/master/service/src/main/java/org/ops4j/pax/wicket/internal/PageMounterTracker.java Very good, I'd be happy to contribute and use the Brix osgi-branch as a proof-of-concept for it. Sometimes it's a little challenging to have multiple chefs in the kitchen, but please don't hesitate to assign me grunt work. > > 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...) > > No problem with that. As long as we do not start to reinvent the wheel once > the boundaries are reached I'm absolutely fine with that. No worries. I think we're finding a very comfortable middle ground here :-) > > 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. :-) > > Well, the feedback I've got so far was: Correct English but very, very plain > :-) Well, this was somehow planed; nevertheless I'm very conscious about the > fact that I wont get the next Shakespear of technical writing so every help > from native English speakers is VERY welcomed! Yes, I try not to make suggestions unless I'm willing to contribute :-) I'll get logged into the wiki so I can add. > > > 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. :-) > > OH, about the commit access... You might want to read > http://team.ops4j.org/wiki/display/ops4j/Principles+of+Open+Participation+Software > :-). OPS4J is a no-barrier-community. Register for team.ops4j.org and you > should be able to edit any part of the Wiki. We have some trouble by now to > integrate this with github by now, but by providing a pull-request or posting > your username you get push access to all OPS4J repos (almost) immediately > (btw, I've added you to the commiter list for the OPS4J repos). Yes, and someone was kind enough to add me this morning as a member. Thanks! I'm honored to help with such a productive group and hope to make many great contributions. > > OK, to nail this down a bit. From my current point of view you need the > following features in the following priority: > > wicket 1.5 > jsr-330 > plain osgi-injection > > One question now is: would it be useful already to have 0.9 with support for > wicket-1.5 and 0.10 with jsr330 and plain osgi injection or is it required to > have everything at once? I've given the roadmap another look. Basically I can > schedule almost anything from 0.8 to some later release and start with the > splitting around KW 32. Wicket 1.5 is all I really need. Everything else is "wish list" and stuff that can come out of actual use cases. I should be able to help with the 1.5 port, but would prefer to have you set up the project structure and source separation beforehand. Does that make sense? Cheers, B > > WDYT? > > Kind regards, > Andreas > > > > 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 > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
