Hi Pete, Thanks a lot for your time and response! One quick question though!
Debugging is very easy but I didn't know it for a while because it's not so obvious how to point your app to the target platform directory where your maven jars are copied, AND at the same time at the project for the source. This threw me for a while and I only found it by accident one day. Can you please elaborate on this? for instance If I have a .eba (or bunch of bundles comprising my project) can I run them in a container and debug them? How do I specify the required bundles (is it similar to the assembly - Aries samples) It will be nice I can some how deploy my app bundles and specify the dependencies so that the dependencies are automatically provisioned from maven? Please elaborate! Thanks Matt On Fri, Apr 29, 2011 at 3:11 PM, Pete Carapetyan <[email protected]>wrote: > Would you mind sharing your tooling information with me please? A detailed >> step by step information of how you set your environment up will be great. >> > > I'm probably taking this on the road within a year, so to avoid competing > with my future self I'll speak in generalities. > > >> I'm still trying to find the optimum way setting this up for my client. >> Any detailed info will be great. >> > > I've only got a year into this effort which sounds like a lot but there > were so many mis-steps and screw-ups along the way that it really isn't so > much time. I expect things to stay fluid through 2011 as I learn more > things, and abort processes which can be replaced with better ones as has > happened so many times in the past few months. > > My standard eclipse setup includes: > - eclipse pde/rap download whatever it's called > - m2eclipse added > - groovy eclipse plugin > - bndTools plugin > - others but not pertinent to this discussion (svn etc) > > Notably I avoided the spring IDE like the plague, not because it's > necessarily bad but because the spring group has been very hot/cold on all > things OSGi and their tooling did some very heavy handed stuff to my osgi > projects early on, and I never got over it. Kind of pissed me off. > > I started with pax construct but had to make so many changes I quickly > abandoned this tool, took the resulting output as templates and created my > own templating system using groovy. Took me a few weeks, mostly mind numbing > troubleshooting and refining the pax created templates - but also in just > the mechanics of groovy templating. It has been extremely successful, and > the nice thing is that every time I "fix" a problem I find it is fixed on > all future modules too, as the fix goes to the template first. > > In addition to refining the templates to meet my needs, I also refined the > array of 5 parent pom.xmls and the project pom.xml. This was a reasonable > investment of time. > > Abandoned Pax Exam after a few months of using it very successfully to get > my project template setups all debugged. Abandoned not because Pax Exam is a > problem - it wasn't, but because running everything in RCP is how my app > works so that constitutes all the OSGi testing I need to do. The rest of the > testing I do is plain vanilla spring/junit testing (detailed on another > thread on this list recently). So far I have had no problem with this > approach, though my next focus will be to bring in the google WindowTester > and run that against my working app - maybe that for 2012. > > Bnd and bndTools is works in tanden with the Eclipse PDE to keep me out of > OSGi hell - but I lost what seems like half year to learning > the idiosyncrasies of how it all works together. If you don't have a half a > year, you can shorten that dramatically by engaging Neil Bartlett or anyone > of similar competence to get you out of the occasional jam. My big downfall > was a "uses" clause and some very deep dependencies in JMS several bundles > deep that kicked my ass for many weeks - Neil met with me over the web, > found the problem in seconds and had it fixed in less than 2 hours using > some voodoo with the profile.properties > file org.osgi.framework.system.packages=[long list]. OSGi can be a real mind > twister, for all it's benefits. > > The other thing that killed me - absolutely - was that for some reason I > didn't get that the felix maven plugin almost but not quite completely > ignores MANIFEST.MF and creates it's own. So I kept fixing import/export > problems and they built without the fix. Anyone could have told me how > stupid I was, but there was no anyone here to tell me so I just kept making > that same mistake for a long time, and it never did work. Very humbling. It > will make a great blog someday. > > If you are using eclipse:eclipse that is a very bad sign and you need to > move to m2eclipse immediately :) no kidding. > > The general rule that I use is never use a PDE project when I can use a > maven project instead - even if I have to take PDE bundles and mavenize them > to get it done. I think I also covered this in a related thread on this list > recently. > > I get most of my bundles from springsource osgi bundle but have had make > some custom - have used both PDE and bndTools, both work great but bndTools > will save you if you know how to use it. > > Neil showed me a combination of logging bundles with slf4j that works in > OSGi great, this was a big pain until he showed me that combination. > > I use, and then alternately do not use, Nexus on Tomcat as my maven > repository server. It alternates on and off - I found some bug with > springsource repo on amazon that messed things up for a while but I still > fire it up to do imports when I need it then turn it back off and comment > out my settings.xml accordingly. > > If you're going to use IOC that is another whole set of problems to debug > but once I got my syntax and semantics understood it's super easy. I follow > the Spring suggested practice of keeping OSGi spring in completely separate > files - so each bundle has two spring context.xml files. If you want a > non-spring OSGi approach Neil's BndTools examples include a really nice > version of the acute IOC which is OSGi specific I believe. Not sure. I got > it working easily. > > Put this elsewhere on this thread but it is critical if you are doing > eclipse apps that you include maven instructions to use the maven dependency > plugins to copy your jar to the target platform lib. Doing this by hand is > no good because you will invariably forget sometimes. > > Debugging is very easy but I didn't know it for a while because it's not so > obvious how to point your app to the target platform directory where your > maven jars are copied, AND at the same time at the project for the source. > This threw me for a while and I only found it by accident one day. > > Well this should be enough for now Matt - I've got pages and pages and > pages of notes and I'd have to stop somewhere, so maybe this is as good a > place to stop as any. > > >> For instance I'm starting with pax construct as well. Using Pax exam for >> my itests. Also I would like to determine best/easy way to debug the apps >> and looks like you have found a nice way (which I would like to follow as >> well) to do so. >> >> Best of luck Matt! > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > >
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
