 Move META-INF and lose Bundle Dependencies in Eclipse? [message #816371] |
Thu, 08 March 2012 19:25  |
 Jason Levine
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
I'm starting to experiment with Virgo bundles in Eclipse, and I discovered today that if I have a web application bundle project I created with the EclipseRT new project wizard "Bundle Project", and I move my META-INF folder out of the WebContent/ folder, then I lose my Bundle Dependencies classpath library -- it appears that the Bundle Dependencies classpath library is hard-coded to look for WebContent/META-INF/MANIFEST.MF and then build the library from there, and I can't figure out any way to change what it's looking for.
(To explain why I'd like to move my META-INF folder: I'm developing this project as a Maven project, and would like to adhere to the standard packaging wherein the web content lives at src/main/webapp/ -- and thus, the META-INF folder would live at src/main/webapp/META-INF.)
I'm running the Eclipse Virgo Tools version 1.0.0.201106220519-M01, the SpringSource Tool Suite 2.7.1.201107091000-RELEASE, on Eclipse Indigo SR2 (build 20120216-1857).
And for further reference, the way I'm creating my project is:
1. New Project wizard, "EclipseRT" container, "Bundle Project";
2. Give the project a name, set the bundle properties and make sure to check "Web Application Bundle", set a path, and submit the wizard;
3. Open up the newly-created MANIFEST.MF (located in WebContent/META-INF/), add a dependency, and verify that the Bundle Dependencies library container shows up in the project;
4. Move the META-INF folder to src\main\webapp\META-INF, and then right-click on the project, go to the "Spring Tools" submenu, and choose "Refresh Bundle Classpath Container", and watch the Bundle Dependencies library disappear from the project;
5. Move the folder back to where it was, do the same refresh, and watch it reappear.
How do I move my META-INF folder to where it needs to be, and still maintain the Bundle Dependencies library?
Thanks in advance...
[Updated on: Thu, 08 March 2012 19:25] Report message to a moderator |
|
|
| Re: Move META-INF and lose Bundle Dependencies in Eclipse? [message #816445 is a reply to message #816371] |
Thu, 08 March 2012 21:44  |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Good question. I think I may have solved this somewhat inadvertently when we took some of the Spring tooling dependencies out. There was a lot of complex logic in there about where a manifest might properly be, and I took [that all] some of that out. Leo and I had a long chat over whether we needed to support these arbitrary locations. To me it seems fragile to assume a proper location for this stuff at all. Ideally we'd be using the binary build location of the MANIFEST.MF, but there is a chicken and egg problem there. We could deduce that from the classpath information and then walk back through the build, but that's fragile too. IIRC what we ended up with is looking for the first initial META-INF/MANIFEST.MF in any source directory, which isn't ideal either.
In any case, the behavior may have changed significantly from the release you're using. Could you try this with the snapshot? And then raise a bug if it is still occurring.
[Updated on: Thu, 08 March 2012 21:45] Report message to a moderator |
|
|
| Re: Move META-INF and lose Bundle Dependencies in Eclipse? [message #816942 is a reply to message #816445] |
Fri, 09 March 2012 12:52 |
Jason Levine
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Miles, I tried out the snapshot last night -- first of all, nice job breaking it out from all the Spring tooling dependencies! MUCH easier. 
Alas, though, the Bundle Dependencies container didn't work for me -- I suspect it's because the maven-standard web content location isn't actually defined as a source directory, so the logic you describe ("looking for the first initial META-INF/MANIFEST.MF in any source directory") won't find the manifest there.
I'm happy to raise a bug on this when I get to work later. In the mean time, there's a reasonable Maven workaround -- for all the bundles and libraries I include in my manifest, I also put them into my Maven POM with scope of "provided". The two downsides are that it's another step to do for Eclipse to be able to find them, and I lose some granularity (since I can specify subpackages of libraries in the manifest as bundles, but am limited to including the entire library in Maven). But no biggie.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.01880 seconds
] 
Search
Help
Register
Login
Home
But seriously, I'm not sure that there is a sound reason for searching in source dirs only -- again the bottom-line issue is whether they would end up in the actual built application, but again it is sort of backward for us to have to deduce that for all of the different configurations when any builder can arbitrarily define a different way of doing this. It may be a better solution to scan the whole directory structure if one is not discovered on the source pass. But again I haven't really looked at this code recently so the might be something simpler going on.