Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty maven console in 2023-06 #1481

Closed
reckart opened this issue Jul 19, 2023 · 32 comments · Fixed by #1512
Closed

Empty maven console in 2023-06 #1481

reckart opened this issue Jul 19, 2023 · 32 comments · Fixed by #1512

Comments

@reckart
Copy link

reckart commented Jul 19, 2023

I have upgraded my m2e installation to 2.3.0 in Eclipse 2023-06 and now no longer get output in the Maven Console View. Relevant plugins seem to be installed.

M2E - Maven Integration for Eclipse	2.3.0.20230523-2033	org.eclipse.m2e.feature.feature.group	Eclipse.org - m2e
M2E - SLF4J over Logback Logging	2.1.2.20230523-2106	org.eclipse.m2e.logback.feature.feature.group	Eclipse.org - m2e

Is this (again) a known issue?
Is there a known fix or workaround?

Older similar issue: #182

@reckart
Copy link
Author

reckart commented Jul 24, 2023

ping?

@HannesWell
Copy link
Contributor

HannesWell commented Jul 24, 2023

Can you also list the versions of the slf4j.api and logback bundles?

And check (e.g. in the Host OSGi console) if the aries.spifly.bundle and logback bundles are started?
But since as far as I know in EPP the start levels have not been configured yet, I assume they are not started.

Probably either the EPP packages should include the corresponding auto-start configuration or we should add corresponding p2-instructions to auto-start those bundles required by m2e, i.e. logback.

@reckart
Copy link
Author

reckart commented Jul 24, 2023

Screenshot 2023-07-24 at 20 45 24 Screenshot 2023-07-24 at 20 45 43

... need to install the PDE tooling for the host console ... takes a moment

@reckart
Copy link
Author

reckart commented Jul 24, 2023

According to the OSGI console, logback seems to be resolved only and spifly does not even seem to be installed.

2627	reference:file:plugins/org.eclipse.m2e.logback_2.1.200.20230523-2106.jar
  RESOLVED    org.eclipse.m2e.logback_2.1.200.20230523-2106 [2627]
2544	reference:file:plugins/ch.qos.logback.classic_1.2.12.jar
  RESOLVED    ch.qos.logback.classic_1.2.12 [2544]
2545	reference:file:plugins/ch.qos.logback.core_1.2.12.jar
  RESOLVED    ch.qos.logback.core_1.2.12 [2545]

@reckart
Copy link
Author

reckart commented Jul 24, 2023

Hm, even if I manually start the logback bundles, the ...m2e.logback bundle still only stays resolved. Shouldn't that fragment be activated automatically once its fragment host ist started... 🤔

@HannesWell
Copy link
Contributor

OK, sorry I forgot that the 23-06 release contained logback 1.2.X, which works with slf4j-1.7 (which is why you see 1.7 in your installed plugin list). But the platform the already was shipped with slf4j-2 and therefore probably most bundles, especially the m2e.maven.bundle is wired to the later version.
In the current snapshots we have fully updated m2e to slf4j-2 and logback 1.4. You can try out the snapshots from:
https://download.eclipse.org/technology/m2e/snapshots/2.4.0/
But at the moment you then still have to activate aries and lockback maually.

spifly does not even seem to be installed.

This is actually not possible, because slf4j.api version 2 cannot resolve without it.

Shouldn't that fragment be activated automatically once its fragment host ist started... 🤔

Good question, IIRC one cannot activate/start a fragment, you can only start/activate the host bundle. E.g. a Fragment also cannot have a BundleActivator. But to be sure one should look that up in the OSGi spec:
https://docs.osgi.org/specification/osgi.core/8.0.0/

@reckart
Copy link
Author

reckart commented Jul 30, 2023

I have upgraded to the latest 2.4.0 SNAPSHOT. Using the ss command in the host osgi console, I still cannot find the Aries SpiFly plugin (searched for aries and spi, but no matches).

I can manually start the logback modules and they get activated:

3038	ACTIVE      ch.qos.logback.classic_1.4.8
	            Fragments=3056
3039	ACTIVE      ch.qos.logback.core_1.4.8

... but the m2e logback fragment remains in the resolved state:

3056	RESOLVED    org.eclipse.m2e.logback_2.2.0.20230625-0847
	            Master=3038

... also, I still do not get any log output in the Maven console.

@HannesWell Do you have any other ideas?

@HannesWell
Copy link
Contributor

I have upgraded to the latest 2.4.0 SNAPSHOT. Using the ss command in the host osgi console, I still cannot find the Aries SpiFly plugin (searched for aries and spi, but no matches).

This is really strange, because actually the logback bundle cannot be installed by p2 respectivly cannot be resolved at runtime by OSGi, so it really has to be present. Or you have another OSGI Service Loader Mediator Specification implementation available in your product, but I'm not aware of one besides spifly.

Could you check the m2e example product we provide at:
https://ci.eclipse.org/m2e/job/m2e/job/master/lastSuccessfulBuild/artifact/products/m2e-ide/target/products/

There the Maven console should work. If that's right we should check what's missing that the EPPs are in the same working state.

Btw. if it helps you, the Product's definition is:
https://github.com/eclipse-m2e/m2e-core/blob/master/products/m2e-ide/m2e-ide.product

@reckart
Copy link
Author

reckart commented Jul 30, 2023

Indeed.... it seems that org.eclipse.wst.server.preview_1.2.100.v202211091907 provides the osgi.serviceloader.registrar...

g! inspect capability osgi.extender 1929
org.eclipse.wst.server.preview_1.2.100.v202211091907 [1929] provides:
---------------------------------------------------------------------
osgi.extender; osgi.serviceloader.registrar 1.0.0 required by:
   org.eclipse.jetty.http_10.0.15 [2820]
   org.eclipse.jetty.webapp_10.0.15 [2829]
   ch.qos.logback.classic_1.4.8 [3038]
   org.eclipse.jetty.plus_10.0.15 [2823]
osgi.extender; osgi.serviceloader.processor 1.0.0 required by:
   org.eclipse.jetty.xml_10.0.15 [2830]
   org.eclipse.jetty.security_10.0.15 [2824]
   org.eclipse.jetty.util_10.0.15 [2827]
   slf4j.api_2.0.7 [2974]
   org.eclipse.jetty.http_10.0.15 [2820]
   org.eclipse.jetty.webapp_10.0.15 [2829]
   ch.qos.logback.classic_1.4.8 [3038]

@HannesWell
Copy link
Contributor

Indeed.... it seems that org.eclipse.wst.server.preview_1.2.100.v202211091907 provides the osgi.serviceloader.registrar...

Uff. Great investigation and good catch.

Looks like wst added these capabilities with https://git.eclipse.org/c/servertools/webtools.servertools.git/commit/plugins/org.eclipse.wst.server.preview/META-INF/MANIFEST.MF?id=92f9fafbca732e088c82a9aa69e3a5f5491591ec.
But I'm in high doubt they really provide an implementation. I have the impression, it was just added to make dependencies resolve.
Can you create a Bug-Report for wst and ask them for clearification and probably to remove these capabilities and use a real implementation of the ServiceLoader mediator instead? You can link me in the bug-report.

@reckart
Copy link
Author

reckart commented Jul 31, 2023

@HannesWell Hm... sure... any idea how I can find their issue tracker?

...?

@reckart
Copy link
Author

reckart commented Jul 31, 2023

Not sure if this is the right place ... but here's a bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=582259

@HannesWell
Copy link
Contributor

Not sure if this is the right place ... but here's a bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=582259

Yes, looks like they are still at Bugzilla, so that seems to be the right place. Lets see what they say. 👍🏽

@reckart
Copy link
Author

reckart commented Aug 8, 2023

I have checked out the WST code and try to do a local build without the registrar capability... however, when I rebuild, the qualifier of the created artifacts is not updated, e.g. the version of org.eclipse.wst.server.preview remains at 1.2.100.v202211091907. I can't figure out where this version comes from...

The build uses tycho and tycho seems to auto-generate this version into the repository metadata during the build... I don't find the string 202211091907 anywhere in the repository (except in the target folders)... @HannesWell do you maybe have an idea where this timestamp comes from?

@laeubi
Copy link
Member

laeubi commented Aug 8, 2023

Usually you need to disable baseline-replace or increase the micro version for your changes to be reflected.

@reckart
Copy link
Author

reckart commented Aug 8, 2023

@laeubi I only find strings such as Bundle-Version. 1.2.100.qualifier in the checked-in metadata... any pointers where I might find that "micro version"?

@laeubi
Copy link
Member

laeubi commented Aug 8, 2023

Bundle-Version. 1.2.100.qualifier

The 100 is the micro version: https://docs.osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html

@reckart
Copy link
Author

reckart commented Aug 8, 2023

@laeubi Thanks


For posterity:

  • Change the version in the POM, e.g. from 1.2.100-SNAPSHOT to 1.2.101-SNAPSHOT
  • Run mvn org.eclipse.tycho:tycho-versions-plugin:4.0.1:update-eclipse-metadata afterwards to sync the changes to the Eclipse/OSGI metadata files

I still don't understand where Tycho got the timestamp for the 1.2.100-SNAPSHOT from ... probably from some deployed repo. I would have thought that the timestamp would be updated on every local build (as way my experience e.g. from locally building the bnd tools suite).

@reckart
Copy link
Author

reckart commented Aug 8, 2023

@laeubi Actually, when I increase the micro version, I do get a new version indeed, but the qualifier (timestamp) remains the same... E.g. now I have 1.2.101.v202211091907 instead of 1.2.101.v20230808hhmm... 😕 🤔

@reckart
Copy link
Author

reckart commented Aug 8, 2023

Worse... when I try to install the locally built "Preview Server Support" plugin, the update dialog tells me I need to uninstall the entire WST Server Adapters feature ... even though I built the repo from the top down (i.e. I didn't only build the "Preview Server Support" module, but everything)... 😞

Your original request has been modified.
  "Preview Server Support" is already installed, so an update will be performed instead.
Cannot complete the install because of a conflicting dependency.
  Software being installed: Preview Server Support 1.2.101.v202211091907 (org.eclipse.wst.server.preview 1.2.101.v202211091907)
  Software currently installed: WST Server Adapters 3.2.1400.v202307100404 (org.eclipse.wst.server_adapters.feature.feature.group 3.2.1400.v202307100404)
  Only one of the following can be installed at once: 
    Preview Server Support 1.2.100.v202211091907 (org.eclipse.wst.server.preview 1.2.100.v202211091907)
    Preview Server Support 1.2.101.v202211091907 (org.eclipse.wst.server.preview 1.2.101.v202211091907)
    Preview Server Support 1.2.0.v202208120424 (org.eclipse.wst.server.preview 1.2.0.v202208120424)
  Cannot satisfy dependency:
    From: WST Server Adapters 3.2.1400.v202307100404 (org.eclipse.wst.server_adapters.feature.feature.group 3.2.1400.v202307100404)
    To: org.eclipse.equinox.p2.iu; org.eclipse.wst.server.preview [1.2.100.v202211091907,1.2.100.v202211091907]

@reckart
Copy link
Author

reckart commented Aug 8, 2023

Ok, I have uninstalled the WST Server Adapters feature and reinstalled it, this time it installed the locally modified Preview Server Support plugin.

Now, the registrar is properly supplied by Aries:

org.apache.aries.spifly.dynamic.bundle_1.3.6 [3046] provides:
-------------------------------------------------------------
osgi.extender; osgi.serviceloader.registrar 1.0.0 required by:
   org.eclipse.jetty.http_10.0.15 [2820]
   org.eclipse.jetty.plus_10.0.15 [2823]
   org.eclipse.jetty.webapp_10.0.15 [2829]
   slf4j.nop_2.0.7 [2975]
osgi.extender; osgi.serviceloader.processor 1.0.0 required by:
   org.eclipse.jetty.http_10.0.15 [2820]
   slf4j.api_2.0.7 [2974]
   org.eclipse.jetty.xml_10.0.15 [2830]
   org.eclipse.jetty.security_10.0.15 [2824]
   org.eclipse.jetty.webapp_10.0.15 [2829]
   org.eclipse.jetty.util_10.0.15 [2827]

@reckart
Copy link
Author

reckart commented Aug 8, 2023

I can see that logback is active:

2544	ACTIVE      ch.qos.logback.classic_1.2.12
	            Fragments=2627
2545	ACTIVE      ch.qos.logback.core_1.2.12
2627	RESOLVED    org.eclipse.m2e.logback_2.1.200.20230523-2106
	            Master=2544

However, still not logging output in the Maven Console View.

... ok Aries was not started automatically... so I started it:

3046	ACTIVE      org.apache.aries.spifly.dynamic.bundle_1.3.6

Still no output in the Maven console...

Any other ideas?

Note that logback didn't seem to register with aries...

@reckart
Copy link
Author

reckart commented Aug 8, 2023

Btw. no luck running the M2E product either. No matter whether I extract it using macOS Finder or using tar on the command line, I get a corrupt application bundle that macOS refuses to run.

@dbarciela
Copy link

I am having this exact same issue. It happened after I updated m2e from from the latest release version to the latest snapshot version yesterday.
image

@HannesWell
Copy link
Contributor

Any other ideas?

Note that logback didn't seem to register with aries...

Usually you get a printout that tells that a certain service provider was registered with aries.
Can you ensure that aries is activated before logback? I'm not sure if this is necessary or if aries can also process already active bundles.

Btw. I prepare the necessary changes for the Eclipse SDK product to active aries initially:
eclipse-platform/eclipse.platform.releng.aggregator#1195

The EPP products hopefully adapt this soon, so that only logback needs to be actived too.
I'm contemplating to add p2-inf instructions to the m2e.logback fragment or feature to active logback automatically whenever the m2e.logback fragment/feature is installed.

@reckart I think it would probably help to speed up fixing the wst issue, if you provide a Gerrit Change with your changes. Feel free to add me to it.

Btw. no luck running the M2E product either. No matter whether I extract it using macOS Finder or using tar on the command line, I get a corrupt application bundle that macOS refuses to run.

Unfortunately I'm not very familiar with mac and don't have access to one and can therefore not help you much with this.
Alternatively you can setup an m2e development environment and check the runtime of the prepared launch config for the m2e-product (please note there is currently a validation error during launch that you can ignore).

@HannesWell
Copy link
Contributor

Any other ideas?

Note that logback didn't seem to register with aries...

Thinking about it again, I suspect it could be connected to apache/aries#233.
Can you check if you have the jakarta./javax.servlet bundle installed and if you see NoClassDefFoundError for ServletContainerInitializer in the console or error log?

If that's the case, I think we need to add jakarta.servlet as requirement to the m2e.logback feature until the aries issue is resolved.
I can then also add the p2-instructions. I'll try to do that this evening.

HannesWell added a commit to HannesWell/m2e-core that referenced this issue Aug 17, 2023
and add 'jakarta.servlet-api' as requirement to ensure its present until
Aries can handle its absense for logback:
apache/aries#233

Fixes eclipse-m2e#1481
HannesWell added a commit to HannesWell/m2e-core that referenced this issue Aug 18, 2023
and add 'jakarta.servlet-api' as requirement to ensure its present until
Aries can handle its absense for logback:
apache/aries#233

Fixes eclipse-m2e#1481
HannesWell added a commit to HannesWell/m2e-core that referenced this issue Aug 18, 2023
and add 'jakarta.servlet-api' as requirement to ensure its present until
Aries can handle its absense for logback:
apache/aries#233

Fixes eclipse-m2e#1481
@HannesWell
Copy link
Contributor

HannesWell commented Aug 19, 2023

I'm currently testing #1512 and the logback configuration from m2e looks good so far.
I just encountered other bad news: It looks like WebTools wasn't the only project that provides the osgi.extender; osgi.serviceloader...

g! inspect capability osgi.extender 1146
org.eclipse.rap.tools.launch.rwt_3.26.0.20230705-0942 [1146] provides:
----------------------------------------------------------------------
osgi.extender; osgi.serviceloader.registrar 1.0.0 required by:
   ch.qos.logback.classic_1.4.11 [1121]
   org.eclipse.jetty.http_10.0.15 [440]
   org.eclipse.jetty.plus_10.0.15 [443]
   org.eclipse.jetty.webapp_10.0.15 [449]
osgi.extender; osgi.serviceloader.processor 1.0.0 required by:
   ch.qos.logback.classic_1.4.11 [1121]
   org.eclipse.jetty.xml_10.0.15 [450]
   org.eclipse.jetty.http_10.0.15 [440]
   slf4j.api_2.0.7 [979]
   org.eclipse.jetty.security_10.0.15 [444]
   org.eclipse.jetty.webapp_10.0.15 [449]
   org.eclipse.jetty.util_10.0.15 [447]

I just created a PR to remove that from rap: eclipse-rap/org.eclipse.rap.tools#49

I also checked the latest SimRel Repo milestone and besides the two bundles in RAP and WST nobody else seems to fake these capabilities.

HannesWell added a commit that referenced this issue Aug 19, 2023
and add 'jakarta.servlet-api' as requirement to ensure its present until
Aries can handle its absense for logback:
apache/aries#233

Fixes #1481
@HannesWell
Copy link
Contributor

Everthing that m2e can do is so far done. I plan to provide the necessary changes to EPP to auto-start aries in the provided Eclipse Packages this weekend. And then we can only wait for RAP and WST to contribute their fixed bundles to the Eclipse Simultaneous Release.
For an Eclipse SDK based product that gets m2e.logback installed works out of the box.
We can further discuss the state if necessary in this issue and re-open it if it turns out to be something is missing at the m2e end.

@HannesWell
Copy link
Contributor

HannesWell commented Aug 20, 2023

FYI I have also created the PR in the Eclipse Packaging Project EPP (the one that provides the downloadable Eclipse Packages) to configure aries.spifly properly: eclipse-packaging/packages#43

So everything should be set up. We just have to wait until all parts are assembled.

@HannesWell
Copy link
Contributor

I just verified that the Maven-Console is again working with an out-of-the-box an 2023-09 M3 Eclipse IDE for Java and DSL Developers.

@reckart
Copy link
Author

reckart commented Sep 19, 2023

Yay!!! Upgraded to 2023-09 and the console is working again. Thanks for the fix!

@HannesWell
Copy link
Contributor

Great. Thanks for reporting back. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants