Last week had an issue with a delivery to a client from our offshore team. The application is a OSGI based application using Spring DM and Spring MVC.
The team delivered the changes and I tried to build the par using both maven and directly from eclipse using STS. Both gave me the same exception:
Caused by: com.springsource.kernel.osgi.framework.ImportMergeException: cannot merge imports of package 'com.foo.bar' from sources 'Import-Bundle 'MyApp-1.0-SNAPSHOT-0-securityservices' version '1.0.0', Import-Bundle 'MyApp-1.0-SNAPSHOT-0-myapp_api' version '1.0.0'' because of conflicting values 'MyApp-1.0-SNAPSHOT-0-myapp_api', 'MyApp-1.0-SNAPSHOT-0-securityservices' of attribute 'bundle-symbolic-name'
After some research it seemed that the problem was in the MANIFEST.MF files generated using Bundlor. The point is that the projects suddenly all exported the package: com.foo and com.foo.bar as part of the ‘Export-Package’ entry.
The reason was that the packages seemed empty but the weren’t. The developer working on the project was using a Mac which lead to the creation of .DS-store files in the com and foo folders. Since the developer also managed to commit these files into SVN, I got these files as well during a fresh checkout. The issue was also less apparent since the files are hidden.
Knowing this, I simple cleaned all .DS-store files and regenerated the MANIFEST files again. This solved the issue.
After a search on google, it seemed that the issue is already resolved and only affects Bundlor tool version 1.0.0.M6. The solution in the tool was to add .DS-store files in an ‘exclude-from-export’ list so these files were not added for export. The only thing that I didn’t find out yet is how to just update this component instead of the whole STS package. Open to suggestions
Hopefully this was helpfull for anyone who has the same issue.
I am working with Wicket Framework combined with OSGI, Spring DM and running on the DM server. Though everything is working fine, I am running into issues because the Springsourcetool plugin is synchronizing my changes to local server every time a change is saved. You can turn this off but you do need to see your changes on the server. Especially when you are tuning the layout.
You can also save the page as a local HTML page to experiment with some ui changes but still there is some merge work to be done afterwards.
Instead of doing that, I decided to switch over to Jetty during the ui development so there was less overhead for using DM server to redeploy all par bundles when saved.
The changes were very simple:
update the web.xml
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/jetty-applicationContext.xml</param-value>
</context-param>
<!--
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<context-param>
<param-name>contextClass</param-name>
<param-value>com.springsource.server.web.dm.ServerOsgiBundleXmlWebApplicationContext</param-value>
</context-param>
-->
Since I use spring DM to inject the beans using osgi:reference, I created an addtional jettyApplicationContext.xml where I replace the osgi:reference calls with standard bean definitions.
So originally I had:
<osgi:reference id="authenticationService" interface="com.componence.social.AuthenticationService"></osgi:reference>
in the jetty context file:
<bean id="iwinAuthenticationService" class="com.componence.social.services.impl.AuthenticationServiceMockImpl"></bean>
Now since Maven dependencies has caused that the project references are set, using a direct spring bean injection is a piece of cake.
Now you can use the Jetty plugin to start the web application as a standard server and changes are instantly shown within 2 seconds. This will definitely save you time and a lot of frustation!
Good luck!