Very interesting stuff Marshall, I don't know pax-construct but the approach you're suggesting seems very clean and easy. I'll try to have a look tomorrow :) Tommaso
p.s.: If this approach can't make the trick I'm ok on keeping OSGi stuff out of the release, otherwise I think it'd be good to consider this as a good option 2011/8/22 Marshall Schor <[email protected]> > I'm beginning to get optimistic about OSGi and UIMA and Maven repository > integration. > > This is because I discovered the Maven Cookbook ( > http://www.sonatype.com/books/mcookbook/reference/ ) Chapter 1, and > pax-construct ( http://www.ops4j.org/projects/pax/construct/ ). > > With the "trick" of asking a wired bundle for a reference to its > classloader, > and then using that as the UIMA ResourceManger classloader, UIMA plays > nicely > with OSGi. > > The approach would be to create a custom application bundle that depends on > the > UIMA Runtime plus a top level aggregate (which would be in a separate > bundle, > and depend on its delegates, etc., recursively). > > Then you might be able to use the pax-construct command line tools to put > things > together, register components, etc., without writing extra code. > > And, (bonus) you can use Maven repositories to store the bundles, and have > maven > fetch them for you :-). > > This would be like the previous OSGi approach, minus all of its custom > approaches, replacing those with standard tooling (to be verified, we'll > see). > > I haven't actually tried any of this, but I don't see any showstoppers - > hence > I'm optimistic :-) (and maybe foolish?). > > -Marshall > > On 8/22/2011 3:01 PM, Jörn Kottmann wrote: > > On 8/22/11 8:57 PM, Marshall Schor wrote: > >> I think I'm now tilting toward leaving the OSGi packaging (with UIMA > framework > >> classes packaged with the annotator) out of the release. > >> > >> This is because it seems to me this is not the right way to do OSGi (as > is being > >> discussed), and realistically, I don't think it's very usable as > currently > >> packaged. I don't think we want to encourage this style of OSGi > adoption. > > +1, I also believe it is not a good idea to release this, because people > will > > then > > mistakenly assume that UIMA works nicely in an OSGi environment. > >> I would rather work toward a more functional packaging. > > > > +1, I will try to help here > >> Tommaso (and others who would like this to be released in its current > form, or > >> with the additional change of exporting the UIMA framework packages), > how > >> significantly will you be impacted if this isn't released at this time? > > > > I don't think it has an impact, because we only need to feel responsible > > for things we released. > > > > Jörn > > > > > > >
