* remove invalid tycho resolver config (not valid since many versions)
* fix PMD plugin configuration (config attribute was renamed in 3.18)
* remove duplicate versions already managed in pluginManagement section
* fix indentation
* move all not yet configured versions into pluginManagement of the
parent module to avoid further duplication
* consume the target platform as file, not as maven artifact (this
simplifies building a single module A LOT)
* remove invalid tycho-source-plugin configuration
* disable tycho consumer POM generation (not needed here, and avoids a
warning in each module)
* remove prerequisites. that's for maven plugins only, and this POM
already contains the better suited similar maven enforcer rule
* enforce UTF-8 for javadoc generation (the build fails on Windows
otherwise, trying to read some Japanese? characters with the Windows
default encoding)
Because javax.activation 1.2.2.v20221203-1659 is in SimRel (for now)
it gets picked by p2 over jakarta.activation-api 1.2.2 which provides
the same packages.
As and when we update to Jave EE 9 (IIUC) we should be able to solve this
in a cleaner way and not rely on the old orbit bundles. Also, if and
when all projects contributing to simrel remove 1.2.2.v20221203-1659 then
we can change too.
The other option is to try to force the jakarta.activation-api 1.2.2 into
simrel and the EPP packages, but if we accidentally end up with both in
a product then other things don't work, e.g. like this error:
<details>
<summary>frame work error details</summary>
```java
!ENTRY org.eclipse.cdt.debug.application 4 0 2023-11-20 15:06:47.456
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.cdt.debug.application [101]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
org.eclipse.cdt.dsf [116]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
org.eclipse.cdt.dsf.ui [119]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
org.eclipse.cdt.gdb [121]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.8.300.202309151124"; singleton:="true"
org.eclipse.cdt.dsf.gdb.ui [118]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="[7.0.0,8.0.0)"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
org.eclipse.cdt.dsf.gdb [117]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
-> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
org.eclipse.cdt.native.serial [141]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
-> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
Unresolved requirement: Require-Bundle: org.eclipse.tm.terminal.control; bundle-version="4.0.0"
-> Bundle-SymbolicName: org.eclipse.tm.terminal.control; bundle-version="5.5.100.202311142253"; singleton:="true"
org.eclipse.tm.terminal.control [506]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: jakarta.activation-api; bundle-version="[1.2.2,2.0.0)"
-> Bundle-SymbolicName: jakarta.activation-api; bundle-version="1.2.2"
jakarta.activation-api [30]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="4.2.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb.ui; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb.ui; bundle-version="7.2.0.202211062329"; singleton:="true"
org.eclipse.cdt.gdb.ui [122]
No resolution report for the bundle. Bundle was not resolved because of a uses constraint violation.
org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"] because it is exposed to package 'javax.activation' from resources jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"] and javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"] via two dependency chains.
Chain 1:
org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
require: (&(osgi.wiring.bundle=jakarta.activation-api)(&(bundle-version>=1.2.2)(!(bundle-version>=2.0.0))))
|
provide: osgi.wiring.bundle: jakarta.activation-api
jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"]
Chain 2:
org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
require: (&(osgi.wiring.bundle=jakarta.xml.bind-api)(&(bundle-version>=2.3.3)(!(bundle-version>=3.0.0))))
|
provide: osgi.wiring.bundle; bundle-version:Version="2.3.3"; osgi.wiring.bundle="jakarta.xml.bind-api"
jakarta.xml.bind-api [osgi.identity; osgi.identity="jakarta.xml.bind-api"; type="osgi.bundle"; version:Version="2.3.3"]
import: (osgi.wiring.package=javax.activation)
|
export: osgi.wiring.package: javax.activation
javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"]
at org.eclipse.osgi.container.Module.start(Module.java:463)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1852)
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1845)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1786)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1750)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1672)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)
```
</details>
The underlying problem here is that the debug application's "product" that
gets converted to a config.ini at CDT build time doesn't expose its
dependencies fully to p2, so we end up with a built product in EPP that
doesn't have everything listed in config.ini.
There is significant maintenance overhead and it is growing to keeping
standalone as it is now working. Other options should probably be considered,
such as using the config of the full product when launching.
Fixes#591
Includes updating to latest target platform. This should
also fix#591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.
Fixes https://github.com/eclipse-cdt/cdt/issues/591
Part of #548
Until https://github.com/eclipse-cdt/cdt/pull/495 can be resolved
fully, apply some of the required changes.
- wildwebdeveloper was out of date, however we don't really
need wwd in CDT, but some of our dependencies have requirements
that are fufilled (e.g. linuxtools)
- duplicate entry for hamcrest 2.2 removed (other entry was just
above it!)
This includes updating to 3rd party dependencies coming from Maven
so that everything resolves properly. In particular spifly
required asm, and by doing `includeDependencyDepth="direct"` that
dependency is included in the target platform.
Some bundles are bumped because dev happened between 11.2 release and
this version bump. The most significant change that happened
was the bump in Tycho version which changed ECJ version and
hence some class files changed
Part of #420
Wrong active build configuration for Core Build projects.
The CoreBuildLaunchBar tracker always made a non default build
configuration the active build configuration. In other words, it
always made the debug build configuration active.
This caused wrong build flags if a non core build launch configuration
was used to launch a core build project binary.
Fixed the CoreBuildLaunchBar tracker to set the build configuration
to active that matches the launchBar mode.
Fixes#378
This is an example of where we have somewhat an inversion of dependencies.
The existing CDT code assumes it knows about all types of editors
at compile time. In this case the LSP C Editor is a new type. However,
rather than creating a new extension mechanism here we are simply
adding the LSP C Editor to the known list as the LSP C Editor
is (or will soon be) part of CDT itself anyway (see #354)
By itself this change doesn't do anything, it needs the
change in https://github.com/Bachmann-electronic-GmbH/eclipse-cdt-lsp/pull/46/
Also-by: Gesa HENTSCHKE <Gesa.HENTSCHKE@bachmann.info>
When we update Tycho we pull in a new version of ECJ which means
we can get some differences in the class files even though
there is no difference in the source. This commit bumps
all the bundles that are affected by this.
This is kept as a separate commit from the Tycho update
because if we need to revert the Tycho update we would still
need to bump all these bundles to make jgit timestamp qualifier
happy.
Part of #320
See also #308
The previous commit in this series addresses the NPE that
can be hit. This code covers the case of the OP in #251
to actually find the correct expression to pass to GDB.
Improvement to #251
While working on #251 I had to understand what this code did,
I include the method javadoc in the hope it saves the next person
who touches this code some time.
In cases where an IASTName has no image location we were getting
NPEs in this code. See javadoc for getImageLocation for cases
when image location can be null. See #251's description for a
full case of when this can happen.
All other calls to IASTName.getImageLocation in CDT were also checked
and this was the only place in the code where the return value
was not checked for null.
Fixes#251
This change adds the ALL_FLAGS that does not limit tool options to
those declared as IOption::isForScannerDiscovery when launching the
compiler to discover compiler built-ins.
This is needed as many other flags, either entered manually in "Other
flags" or some of the existing flags with checkboxes such as "-ansi",
"-fPIC", and "-fstack-protector-all" which all affect scanner discovery
as they can all change what macros are built-in to the compiler.
The current solution has as a drawback that some settings, like -I and -D
then appear twice. For example in the "Includes" node in the "Project
Explorer"
My only reservation about this change is if there is an option
that can be specified successfully at build time, but when used
at scanner discovery time causes the compiler to fail, or return
incorrect results. Therefore I have added a new field,
excludeFromScannerDiscovery to tool options (buildDefinitions
extension point) that allows tool integrators to always exclude
a command line option from ALL_FLAGS. I have also added
a new "Other flags (excluded from discovery)" to the
"Miscellaneous" tab to allow compiler options to be entered
by the user.
Note that FileBasedErrorParserTests had to change because of some
Tycho incompatibility with JUnit's ParameterizedTest. It works
in the IDE, but not in maven.
The correct fix is to resolve the tycho settings, see Bug 569949
for a previous example. It may also be simply resolved by updating
to Tycho 3.0.0. However I want to get this change in as
at the moment CDT.setup is broken and that is impeding developers.
These binary parsers have been slated for deleting for
a while and are replaced with 64-bit compatible
versions.
Some methods still refereneced the 32-bit variants
and have been updated to the fully functioning
64-bit variant.
The older parser IDs are preserved (forever?) so that
old projects can be opened without needing to do anything.
The IDs now point at the new implementations.
See also Bug 562495
Steps:
======
1. Create a managed project and build it
2. Expand the built binary available in binary container in project explorer view
3. Now clean the project, clean will fail irrespective of number of tries you do
Reason:
=======
For finding the sources for binary, Elf instance is created and Section.mapSectionData creates MappedByteBuffer of channel which locks the file on Windows until its garbage collected, see following
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154
Solution:
=========
Made ISymbolReader AutoCloseable and user is responsible to properly close it. In case of dwarf reader, we remove all the references of ByteBuffer and call gc.
Warning in build.properties will be errors when they run
in the tycho build, like this:
```
Error: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin
(default-package-plugin) on project org.eclipse.cdt.core.tests:
/home/runner/work/cdt/cdt/core/org.eclipse.cdt.core.tests/build.properties:
bin.includes value(s) [test.xml] do not match any files. -> [Help 1]
```
So make them errors in the workspace so that the issue is
detected before push.
Some build.properties issues don't affect the build, but
are still indicative of a problem.
The adaptable type that was listed doesn't exist.
This is only used to get the correct icon/label for these
type of adapters, so the effect is minor.
Fixup for 9aee6c4850
* Correct the requirements according to the latest target platform
* Move to requiring Java 17
* Enable the profile in the Jenkinsfile to verify it builds
