Thanks, good stuff! I'll look into your suggestions. unfortunately, spring dm won't go over well. at the beginning of this project I suggested using spring dm and was told it's "proprietary". but, could we use spring dm for junits w/o using the spring dm manifest style (I know they extended the OSGi manifest)?
do you write plain old junits ever (build the classpath manually instead of osgi-ified)? what ant task or gradle plugin do you use for executing your junits? On Mon, Jul 19, 2010 at 11:27 AM, Rene Groeschke <[email protected]> wrote: > Hi phil, > > Am 19.07.10 18:01, schrieb phil swenson: >> >> I am involved in a project where I think the build system is a huge mess. >> >> Here is the situation: >> >> We have a build that treats everything as eclipse plugins. I guess >> someone knew how to do a PDE eclipse plugin build and decided that >> everything should be done this way. So we are using PDE for >> everything. It's a build I don't understand very well as it's 1000s >> of lines of xml spread out across many build.xmls. >> >> JUnits are run by launching junits via eclipse. Apparently the >> thinking is that OSGi JUnits need the runtime to execute in. Or >> something. There is a truly heinous ant script to launch the eclipse >> sdk/osgi start process. never seen anything like it (tons of macrodef >> ant tasks).... >> >> The build repo is "p2" which I gather is an eclipse centric plugin >> repository. >> > > I'm not sure about the p2 repository layout, but If you want to resolve your > bundles stored at this p2, you could maybe loose the URLResolver to resolve > these dependencies. > see gradle cookbook at > http://communitymapbuilder.org/display/GRADLE/Cookbook#Cookbook-Customrepositorystructureanditsaccesspatterns > >> The OSGI runtime is a wrapped up Equinox. >> >> Eclipse projects are checked into source. The OSGi targets (for >> running the OSGi container in eclipse) are checked in as well. This >> is a huge problem for me as when bundles are updated the projects and >> targets typically don't compile/execute correctly. And it's a manual >> hack-fest to pull in the right bundles and get the projects compiling. >> >> >> Result of the current design: >> So what's happening is the build takes forever (40 mins on my box). >> The build is broken probably 80% of the time. It's very hard to >> understand. The eclipse project config settings are almost always out >> of sync with the current bundles. JUnits have to be executed inside >> OSGi. There is no way to execute individual JUnits in the build. >> >> To add new dependencies we manually edit the bundle manifest (eclipse >> wizard). Then we check in the manifest. Then we tell the build >> engineer what we want. He modifies the build somehow to pull in the >> correct bundles. And usually the build breaks for quite a while.... >> adding dependencies is very painful. >> >> >> I know I'm throwing a lot of stuff out there..... I want to try and >> prototype something in gradle for this to show a better approach. >> this boils down to a few questions. >> 1) what are best practices for running OSGi JUnits? >> > > IMHO the best practice for running OSGi JUnit and Integrationtests is using > Spring-DM. They offer a lot of support for testing osgi bundles. Have a look > at > http://static.springsource.org/osgi/docs/current/reference/html/testing.html > for further informations and examples. >> >> 2) what are best practices for how to deal with the manifest file? I >> see the gradle OSGi plugin generates the manifest file - which seems >> to be a better approach to me. But in this case what about your IDE? >> > > Generating or not generating is the most discussed topic when talking about > OSGi bundles. In general I prefere manually written manifest files if I'm > working on an OSGi app. If I just want to OSGifiy my libs I generate the > osgi manifest. >> >> How is the IDE going to know dependencies before you build your >> manifest via the build? >> 3) what are best practices for setting up the eclipse projects/targets >> from the build? I am not sure what all is stored in eclipse projects >> (I am more of an IntelliJ IDEA guy but was forced to use eclipse by >> this project setup). Seems like having the build generate the eclipse >> target and runtime configuration is better (and I'm aware of the >> eclipse project plugin for gradle). >> > > I tend to generate my eclipse project files. In the past we reused the > eclipse classpath file for our ci builds. Going this ways may save you one > manually entry in your build file but involves a lot of problems (just > classpath scope; what about your test dependencies ...). By now I generate > my eclipse workspace via gradle. If you want to use the gradle eclipse > project generation you have and want the PDE nature for your projects you > have to add this to your build file: > > eclipseProject { > natures += 'org.eclipse.pde.PluginNature' > buildCommands += 'org.eclipse.pde.ManifestBuilder' > buildCommands += 'org.eclipse.pde.SchemaBuilder' > buildCommands += 'org.eclipse.pde.ManifestBuilder' > } > > 4) what is the best place to ask OSGi questions? I've searched for >> >> forums and haven't really found anything useful. >> > > I like the spring + osgi google group at > http://groups.google.com/group/spring-osgi. There is a lot of osgi know how > there. > > > regards, > René > > -- > ------------------------------------ > Rene Groeschke > > [email protected] > http://www.breskeby.com > http://twitter.com/breskeby > ------------------------------------ > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
