Hey Brian, On Wed, Jul 27, 2011 at 19:35, Brian Topping <[email protected]> wrote:
> > On Jul 27, 2011, at 1:03 AM, Andreas Pieber wrote: > > 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. > > :-) I just scanned it for places which jump to me where PW could be useful (in addition I always like to read code from various people in my free-time. I see this as good programmer lecture :-)). No, this is too much code for my spare free time and while I like the idea of Brix I have not use cases right now. Still it would be really cool if you could record (and share) the commits with the changes required for introducing PW. This could be important a) to see where we could further improve PW, b) it's kind of a "marketing" argument if the number of changes are quite small/simple. > 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. > While "plain osgi" comes a little bit out of fashion (thanks to blueprint & spring) I still think it's quite simple to manage (see PW for example) but allows a "almost zero dep" policy. Therefore, IMO, if not required/defined otherwise this is still the way to go. > > > >> 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. > I think as long as all chefs in the kitchen pull into the same direction this shouldn't be of any problems. Nevertheless, thanks for the offer and I wont hesitate ;-) Everything else was discussed (again) on follow-up-mails. So I'll answer there. Kind regards, Andreas > </skip> > > > >> 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 > >
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
