Richard,
Let us know if we can help.
Sure, as soon as I can find time to proceed with it and run into something where I need help.
Richard:Honestly, I actually put together the telnetconsole bundle because I didn't want to "cripple" telnetd-osgi into something that's no longer useful for a generic purpose. E.g. trying to figure a way around installing the configadmin bundle just doesn't make much sense to me when you need to configure it anyway.Dieter, I understand your concern, but perhaps I didn't explain the proposal very well. We weren't discussing something that would "cripple" telnetd-osgi, in fact the proposal was more about how it should be packaged.The proposal was to package it with the needed commons classes and probably the CM interfaces, thus it would be self-contained. By doing this, we make it possible to use it without CM (i.e., CM would be optional), but this will require no changes to telnetd-osgi functionality, it will still register a ManagedFactoryService like normal and everything will work exactly like it does now.The only difference is that by packaging it in a more self-contained way, a CM impl is not necessary and clients can inject their own configuration directly (i.e., with no CM impl available), thus reducing the dependency for those that don't need it. This would actually be possible even if a CM impl was present, unless you turned on security and forbid bundles from accessing the ManagedFactoryService.So, no crippling intended, just more "generic" flexibility. Hope that alleviates some of your concerns. We certainly aren't trying to run away with your project. :-)
Right. First of all, I wasn't really worried that you'd run away with anything :) I wouldn't do open source if I had such fears.
I think my concern was more a practical one; even it if it is packaging, somebody has to do it, and the sources have to be in some place. Somehow, I was thinking of a way to avoid the need to maintain too many versions of it at the same time (well not that there is much maintenance for the pre-OSGi ones anyway).
I am trying to help out, but I am also trying to keep my time and effort investment on a line where goals coincide. Honestly, I didn't understand well what your goal is and probably it was a little bit precipitated to assume I'd got to take responsibility for it already >)
So how would you suggest to proceed about this special packaging?
1. get the telnetconsole bundle into Felix (project):This should be straigthforward, but see the comments I made to Felix (M.).Agreed, we have to look into it.
Great.
2. iron out the problems with the telnetd-osgi and figure a way to have some of the extensions (I am using the templates extensively to generate output on a shell).Ok.There is still the possibility to have it inside or outside of Felix (project).From my point of view, I would at least suggest not to try and "cripple" it (i.e. this translates into: I won't do it, but the code is open source, and available since more or less 2 years, so anybody is welcome ;).Since it is just a packaging issue, we could easily do this with the maven bundle plugin.
I've got to understand better what you are trying to do. Maybe you or Felix find time to forward the analysis you have mentioned earlier?
3. provide the glue bundle I wrote (essentially a shell that is hooked into telnetd-osgi). This should rather be part of Felix (project). There is only my own source and all it needs is some Maven magic to build it "the Felix way".Yep.
Great. I get up the sources asap. Regards, Dieter
smime.p7s
Description: S/MIME cryptographic signature
