Announcement Announcement Module
Collapse
No announcement yet.
Bundlor and M2Eclipse Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bundlor and M2Eclipse

    Hello,

    I have a Maven project designed with hierarchical submodules.

    With M2Eclipse you can import those submodules projects so that they look like normal Eclipse projects:
    http://docs.codehaus.org/display/M2E...Maven+projects

    On one of these submodules, I added the "OSGi Bundle Project Nature" to have support for template.mf generating automatically the /src/main/resources/META-INF/MANIFEST.MF file

    Unfortunately the MANIFEST.MF is not generated on the fly, even when using "Run generation of MANIFEST.MF file"

    So my 2 questions:
    - Is it a problem to use M2Eclipse instead of Q4Eclipse with Spring STS ?
    - Is it possible to debug/trace the output of the "Run generation of MANIFEST.MF file" action to see what's going on ?

    Many thanks

    Fred

  • #2
    After some tests today:

    1- Is it a problem to use M2Eclipse instead of Q4Eclipse with Spring STS ?

    No I don't think so

    2- Is it possible to debug/trace the output of the "Run generation of MANIFEST.MF file" action to see what's going on ?

    Basically I made some mistake in template.mf that prevented Import-Packages entries to be listed, but I still have some differences between the MANIFEST.MF generated using the "Update MANIFEST.MF" link from the template.mf editor and the MANIFEST.MF generated by the Bundlor Maven plugin.

    I think it's because of classpath resolution difference between the Eclipse workspace project and the packaged JAR; I have some compiled classes added as a "Class folder" within the Eclipse project and I think Bundlor doesnit take them in account.

    Could you document a bit more how Bundlor "scans any Java class it can find" ?

    http://static.springsource.org/s2-bu...detecting.java
    Last edited by frederic.conrotte; May 25th, 2009, 04:17 PM.

    Comment


    • #3
      @fredric

      I'll be happy to improve the documentation to be more specific (https://issuetracker.springsource.com/browse/BNDLR-256). In the meantime, let me describe to you what Bundlor actually does.

      In the Maven case, we take the JAR file that is created by the Maven build and analyze all class files contained in it. This means that if you do custom things to the build process we'll still be able to see and analyze them as long as they've made it into the JAR that is created by Maven.

      In the Eclipse case, it's a little different. Bundlor only keeps an eye on 'Source Folders' as Eclipse calls them. It actually scans the source code in that case, rather than the compiled bytecode, so special cases such as linked class folders won't actually be analyzed. If this feature is important to you, please open a JIRA issue on the dm Server Tools JIRA (https://issuetracker.springsource.com/browse/DMST) where the Bundlor Eclipse integration is managed.

      Comment


      • #4
        Thanks for your answer.

        Here is the issue:
        https://issuetracker.springsource.com/browse/DMST-79

        However for me it's conceptually wrong that the 2 modes (from Eclipse/using Maven) are working differently; it's decreasing developer productivity by producing possible errors during runtime/integration tests.

        Comment


        • #5
          I voted this issue up. We do a lot of automated building with maven+hudson and I would also like to see maven bundlor and STS bundlor manifest transformation behave as much alike as possible.

          Comment

          Working...
          X