Invalid generation of SCR component xml after update to 2403

[castortech]

We are getting hundreds of changed xml files after a rebuild. Cleared those up but keep coming back.

The change is that it is removing the activate method registration

[HannesWell]

Thanks for this report, I can confirm that this happens.
@laeubi could you please have a look at this?

[laeubi]

activate is the default see the Specification:

activate Activate
Specifies the name of the method to call when a component configuration is activated. The default value of this attribute is activate. See Activate Method for more information.

also see here

The name of the activate method can be specified by the activate attribute. If the activate attribute is not specified, the default method name of activate is used

There are also numerous examples in the specification that show this pattern, therefore the component.xml is valid and the generator just removes redundant information now.

[castortech]

Ok, I was under the impression that it was needed to be called.

But in the same vein, why isn't this also happening for deactivate for which the specification is similar and the case in the image does have one of those.

[laeubi]

But in the same vein, why isn't this also happening for deactivate for which the specification is similar and the case in the image does have one of those.

The code is somewhat brittle and far from perfect, most likely it is not (yet) implemented that way, in the end you should considered to not check in the generated XMLs at all and let them generated by Tycho/PDE instead that way you won't notice subtile differences in the generated output.

[castortech]

The code is somewhat brittle and far from perfect, most likely it is not (yet) implemented that way, in the end you should considered to not check in the generated XMLs at all and let them generated by Tycho/PDE instead that way you won't notice subtile differences in the generated output.

That is an idea, but IMHO that kind of breaks with building exactly what you committed and tested.

[laeubi]

That is an idea, but IMHO that kind of breaks with building exactly what you committed and tested.

So you check in compiled class files into version control as well? :-)

[castortech]

I think you know what I meant, these are still sources.

[laeubi]

Only if you edit them by hand, if you use annotations (like here) the java files are the source of the result, just that it is a readable xml in contrast to a binary class file format.

[castortech]

Ok I'll buy that. Thanks

[castortech]

Well I guess there is more to this than just removing the files from git.

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin (default-package-plugin) on project com.castortech.util: /data/jenkins/workspace/iriscommon-3.0/com.castortech.util/build.properties: bin.includes value(s) [OSGI-INF/] do not match any files. -> [Help 1]

The only thing I found is this issue on github , where it seems to have a preference file in .settings and the build properties that contains a reference to the component. I am using workspace level setting so I don't have any file at the project level and the build.properties only specifies OSGI-INF/, .

So what am I missing here?

Thanks
Alain

[laeubi]

So what am I missing here?

The problem is that you can't version a folder, the usual workaround is to have a .gitignore in the folder you can find an example here:

https://github.com/eclipse-m2e/m2e-core/tree/master/org.eclipse.m2e.core/OSGI-INF

[castortech]

I did that but no success

Error:
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin (default-package-plugin) on project com.castortech.util: Component definition OSGI-INF/com.castortech.instrumentation.DiskUtils.xml not found! Neither /data/jenkins/workspace/iriscommon-3.0/com.castortech.util/OSGI-INF/com.castortech.instrumentation.DiskUtils.xml nor /data/jenkins/workspace/iriscommon-3.0/com.castortech.util/target/classes/OSGI-INF/com.castortech.instrumentation.DiskUtils.xml exists.

And here is what is there from git:

/data/jenkins/workspace/iriscommon-3.0/com.castortech.util/OSGI-INF$ ll
total 4
drwxr-xr-x 2 jenkins jenkins 24 Apr 19 08:46 ./
drwxr-xr-x 9 jenkins jenkins 303 Apr 19 08:48 ../
-rw-r--r-- 1 jenkins jenkins 21 Apr 19 08:46 .gitignore

cat .gitignore
/com.castortech.*.xml

Any idea what else is required?

[laeubi]

Have you enabled the tycho-ds-plugin or checked in the org.eclipse.pde.ds.annotations.prefs?
Then you should see that the XML are generated as part of the build.

[castortech]

Wow I finally got it done, but for one project.

We have our own org.eclipse.birt.report.viewer based on an older 4.7 version and I am getting errors about the component XML not being found after the DS plugin has run. I can see that it is valid and included in the manifest.

For now I have removed the .gitignore on this project but would still like to handle it like all other 350 projects. This project has no project specific DS annotation, but it does have specific project PDE settings.

[laeubi]

Can you share an example where it is not working?

[castortech]

I've been looking to try to identify what is different (and it is indeed different that our other projects), short of sharing the whole project.

I looked at .project, .classpath and nothing special there except for 2 source location

The manifest is pretty standard except this part that has some more exotic options:

 Eclipse-LazyStart: true
 Eclipse-BuddyPolicy: registered
 Eclipse-BundleShape: dir
 Jetty-WarFolderPath: birt
 Jetty-WarResourcePath: birt
 Web-ContextPath: /viewer
 managedServerName: org.eclipse.birt.report.viewer.server
 Service-Component: OSGI-INF/org.eclipse.birt.report.viewer.utilities.WebViewer.xml,
  OSGI-INF/org.eclipse.birt.report.viewer.BirtReportViewerContextHelper.xml,
  OSGI-INF/org.eclipse.birt.report.servlet.ViewerServlet.xml,
  OSGI-INF/org.eclipse.birt.report.viewer.BirtReportWebContentContextHelper.xml,
  OSGI-INF/org.eclipse.birt.report.servlet.BirtEngineServlet.xml
 Bundle-ActivationPolicy: lazy
 Automatic-Module-Name: org.eclipse.birt.report.viewer
 Bundle-Activator: org.eclipse.birt.report.viewer.ViewerPlugin

Also the build.properties is different:

  src.includes = about.html
  bin.includes = META-INF/,\
                 .,\
                 about.html,\
                 about_files/,\
                 plugin.xml,\
                 viewer.jar,\
                 birt/,\
                 schema/,\
                 plugin.properties,\
                 jettyhome/etc/,\
                 OSGI-INF/,\
                 OSGI-INF/l10n/bundle.properties
  jars.compile.order = viewer.jar,\
                       birt/WEB-INF/lib/viewservlets.jar
  source.viewer.jar = src/
  output.viewer.jar = bin/
  source.birt/WEB-INF/lib/viewservlets.jar = birt/WEB-INF/classes
  output.birt/WEB-INF/lib/viewservlets.jar = bin/
  bin.excludes = birt/WEB-INF/classes/,\
                 birt/test1.rptdesign
  customBuildCallbacks=customBuildCallbacks.xml

But something interesting looking at the build log.
First I see the compile, which builds the 2 jars. The one with 16 sources is the one using the DS components:

[INFO] --- tycho-compiler:4.0.7:compile (default-compile) @ org.eclipse.birt.report.viewer ---
[WARNING] The effective compiler target level 11 is incompatible with the following OSGi execution environments: [JavaSE-1.8 (assumes 1.8)] @ MavenProject: irisba:org.eclipse.birt.report.viewer:4.7.0-SNAPSHOT @ /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/.polyglot.META-INF
[INFO] Compiling 16 source files to /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/target/viewer.jar-classes using Eclipse Compiler for Java(TM) 3.37.0.v20240215-1558
[INFO] Compiling 254 source files to /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/target/birt/WEB-INF/lib/viewservlets.jar-classes using Eclipse Compiler for Java(TM) 3.37.0.v20240215-1558

And then later we have in packaging (after tycho-ds:4.0.7:declarative-services as run) :

[INFO] --- tycho-packaging:4.0.7:package-plugin (default-package-plugin) @ org.eclipse.birt.report.viewer ---
[INFO] Building jar: /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/viewer.jar
[INFO] Building jar: /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/birt/WEB-INF/lib/viewservlets.jar
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:4.0.7:package-plugin (default-package-plugin) on project org.eclipse.birt.report.viewer: Component definition OSGI-INF/org.eclipse.birt.report.viewer.utilities.WebViewer.xml not found! Neither /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/OSGI-INF/org.eclipse.birt.report.viewer.utilities.WebViewer.xml nor /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/target/classes/OSGI-INF/org.eclipse.birt.report.viewer.utilities.WebViewer.xml exists. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:4.0.7:package-plugin (default-package-plugin) on project org.eclipse.birt.report.viewer: Component definition OSGI-INF/org.eclipse.birt.report.viewer.utilities.WebViewer.xml not found! Neither /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/OSGI-INF/org.eclipse.birt.report.viewer.utilities.WebViewer.xml nor /data/jenkins/workspace/irisba-3.0/org.eclipse.birt.report.viewer/target/classes/OSGI-INF/org.eclipse.birt.report.viewer.utilities.WebViewer.xml exists.

We can see that the packaging of the jar that has the DS component goes through without errors, but then it has issues packaging the viewservlets.jar

Does that help?

[castortech]

Surely not a Tycho issue, but more general PDE. While removing the component XML from git, they all got deleted locally along with adding the .gitignore files.

I ended up with problems running the application until I discovered 1 project where the component XML had not been generated. The Service-Component directive (only 1 component in this bundle) was in the Manifest but the file wasn't there. Clean & rebuild didn't work. I remove the manifest Service-Component entry and the entry got re-added as expected. There is a single workspace level configuration for PDE DS annotations and I can confirm that to be true here as well.

At the end, I had to recreate the file manually in order to work with the application again.

[laeubi]

If that happens it should work that you touch the java file once.

[castortech]

If that happens it should work that you touch the java file once.

Believe me I did, I even removed the @component and re-added it. It worked for the manifest but not the XML

[laeubi]

If that happens it should work that you touch the java file once.

Believe me I did, I even removed the @component and re-added it. It worked for the manifest but not the XML

Then this is a bug, there is some code that checks if the file is different and then don't write it again, the only think I could think of is that it was out of sync somehow with a bad cached state.