1
0
Fork 0
mirror of https://github.com/eclipse-cdt/cdt synced 2025-08-16 20:55:44 +02:00
cdt/debug/org.eclipse.cdt.debug.application.product/debug.product

248 lines
12 KiB
Text
Raw Normal View History

<?xml version="1.0" encoding="UTF-8"?>
<?pde version="3.5"?>
<!--
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
Copyright (c) 2015, 2024 Contributors to the Eclipse Foundation
This program and the accompanying materials
are made available under the terms of the Eclipse Public License 2.0
which accompanies this distribution, and is available at
https://www.eclipse.org/legal/epl-2.0/
SPDX-License-Identifier: EPL-2.0
-->
2024-10-08 12:52:15 -04:00
<product name="Stand-alone C/C++ GDB Debugger" uid="org.eclipse.cdt.debug.application.product" id="org.eclipse.cdt.debug.application.product" application="org.eclipse.cdt.debug.application.app" version="12.0.0.qualifier" type="mixed" includeLaunchers="true" autoIncludeRequirements="true">
<aboutInfo>
<image path="/org.eclipse.cdt.debug.application/icons/about.png"/>
<text>
%aboutText
</text>
</aboutInfo>
<configIni use="default">
</configIni>
<launcherArgs>
<programArgs>-data @noDefault
</programArgs>
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
<vmArgs>-Dosgi.requiredJavaVersion=21
-Dosgi.dataAreaRequiresExplicitInit=true
-Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=false
-Declipse.e4.inject.javax.warning=false
-Dorg.slf4j.simpleLogger.defaultLogLevel=off
-Dsun.java.command=Eclipse
-Xms100m
-Xmx512m
-XX:+UseG1GC
-XX:+UseStringDeduplication
--add-modules=ALL-SYSTEM
-Djava.security.manager=allow
</vmArgs>
<vmArgsMac>-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Xdock:icon=../Resources/Eclipse.icns
</vmArgsMac>
</launcherArgs>
<windowImages i16="/org.eclipse.cdt.debug.application/icons/cc16.png" i32="/org.eclipse.cdt.debug.application/icons/cc32.png" i48="/org.eclipse.cdt.debug.application/icons/cc48.png" i64="/org.eclipse.cdt.debug.application/icons/cc64.png" i128="/org.eclipse.cdt.debug.application/icons/cc128.png" i256="/org.eclipse.cdt.debug.application/icons/cc.png"/>
<launcher name="cdtdebug">
<linux icon="../org.eclipse.cdt.debug.application/icons/cc.xpm"/>
<macosx icon="../org.eclipse.cdt.debug.application/icons/cc.icns"/>
<win useIco="true">
<ico path="../org.eclipse.cdt.debug.application/icons/cc.ico"/>
<bmp/>
</win>
</launcher>
<vm>
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
<linux include="false">org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21</linux>
<macos include="false">org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21</macos>
<windows include="false">org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21</windows>
</vm>
<license>
<url>http://eclipse.org/legal/epl/notice.php</url>
<text>
Eclipse Foundation Software User Agreement
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
November 22, 2017
Usage Of Content
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
THE ECLIPSE FOUNDATION MAKES AVAILABLE SOFTWARE, DOCUMENTATION, INFORMATION
AND/OR OTHER MATERIALS FOR OPEN SOURCE PROJECTS (COLLECTIVELY &quot;CONTENT&quot;). USE OF
THE CONTENT IS GOVERNED BY THE TERMS AND CONDITIONS OF THIS AGREEMENT AND/OR THE
TERMS AND CONDITIONS OF LICENSE AGREEMENTS OR NOTICES INDICATED OR REFERENCED
BELOW. BY USING THE CONTENT, YOU AGREE THAT YOUR USE OF THE CONTENT IS GOVERNED
BY THIS AGREEMENT AND/OR THE TERMS AND CONDITIONS OF ANY APPLICABLE LICENSE
AGREEMENTS OR NOTICES INDICATED OR REFERENCED BELOW. IF YOU DO NOT AGREE TO THE
TERMS AND CONDITIONS OF THIS AGREEMENT AND THE TERMS AND CONDITIONS OF ANY
APPLICABLE LICENSE AGREEMENTS OR NOTICES INDICATED OR REFERENCED BELOW, THEN YOU
MAY NOT USE THE CONTENT.
Applicable Licenses
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
Unless otherwise indicated, all Content made available by the Eclipse Foundation
is provided to you under the terms and conditions of the Eclipse Public License
Version 2.0 (&quot;EPL&quot;). A copy of the EPL is provided with this Content and is also
available at http://www.eclipse.org/legal/epl-2.0. For purposes of the EPL,
&quot;Program&quot; will mean the Content.
Content includes, but is not limited to, source code, object code, documentation
and other files maintained in the Eclipse Foundation source code repository
(&quot;Repository&quot;) in software modules (&quot;Modules&quot;) and made available as
downloadable archives (&quot;Downloads&quot;).
- Content may be structured and packaged into modules to facilitate
delivering, extending, and upgrading the Content. Typical modules may
include plug-ins (&quot;Plug-ins&quot;), plug-in fragments (&quot;Fragments&quot;), and
features (&quot;Features&quot;).
- Each Plug-in or Fragment may be packaged as a sub-directory or JAR
(Java™ ARchive) in a directory named &quot;plugins&quot;.
- A Feature is a bundle of one or more Plug-ins and/or Fragments and
associated material. Each Feature may be packaged as a sub-directory in a
directory named &quot;features&quot;. Within a Feature, files named &quot;feature.xml&quot; may
contain a list of the names and version numbers of the Plug-ins and/or
Fragments associated with that Feature.
- Features may also include other Features (&quot;Included Features&quot;). Within a
Feature, files named &quot;feature.xml&quot; may contain a list of the names and
version numbers of Included Features.
The terms and conditions governing Plug-ins and Fragments should be contained in
files named &quot;about.html&quot; (&quot;Abouts&quot;). The terms and conditions governing Features
and Included Features should be contained in files named &quot;license.html&quot;
(&quot;Feature Licenses&quot;). Abouts and Feature Licenses may be located in any
directory of a Download or Module including, but not limited to the following
locations:
- The top-level (root) directory
- Plug-in and Fragment directories
- Inside Plug-ins and Fragments packaged as JARs
- Sub-directories of the directory named &quot;src&quot; of certain Plug-ins
- Feature directories
Note: if a Feature made available by the Eclipse Foundation is installed using
the Provisioning Technology (as defined below), you must agree to a license
(&quot;Feature Update License&quot;) during the installation process. If the Feature
contains Included Features, the Feature Update License should either provide you
with the terms and conditions governing the Included Features or inform you
where you can locate them. Feature Update Licenses may be found in the &quot;license&quot;
property of files named &quot;feature.properties&quot; found within a Feature. Such
Abouts, Feature Licenses, and Feature Update Licenses contain the terms and
conditions (or references to such terms and conditions) that govern your use of
the associated Content in that directory.
THE ABOUTS, FEATURE LICENSES, AND FEATURE UPDATE LICENSES MAY REFER TO THE EPL
OR OTHER LICENSE AGREEMENTS, NOTICES OR TERMS AND CONDITIONS. SOME OF THESE
OTHER LICENSE AGREEMENTS MAY INCLUDE (BUT ARE NOT LIMITED TO):
- Eclipse Public License Version 1.0 (available at
http://www.eclipse.org/legal/epl-v10.html)
- Eclipse Distribution License Version 1.0 (available at
http://www.eclipse.org/licenses/edl-v1.0.html)
- Common Public License Version 1.0 (available at
http://www.eclipse.org/legal/cpl-v10.html)
- Apache Software License 1.1 (available at
http://www.apache.org/licenses/LICENSE)
- Apache Software License 2.0 (available at
http://www.apache.org/licenses/LICENSE-2.0)
- Mozilla Public License Version 1.1 (available at
http://www.mozilla.org/MPL/MPL-1.1.html)
IT IS YOUR OBLIGATION TO READ AND ACCEPT ALL SUCH TERMS AND CONDITIONS PRIOR TO
USE OF THE CONTENT. If no About, Feature License, or Feature Update License is
provided, please contact the Eclipse Foundation to determine what terms and
conditions govern that particular Content.
Use of Provisioning Technology
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
The Eclipse Foundation makes available provisioning software, examples of which
include, but are not limited to, p2 and the Eclipse Update Manager
(&quot;Provisioning Technology&quot;) for the purpose of allowing users to install
software, documentation, information and/or other materials (collectively
&quot;Installable Software&quot;). This capability is provided with the intent of allowing
such users to install, extend and update Eclipse-based products. Information
about packaging Installable Software is available at
http://eclipse.org/equinox/p2/repository_packaging.html (&quot;Specification&quot;).
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
You may use Provisioning Technology to allow other parties to install
Installable Software. You shall be responsible for enabling the applicable
license agreements relating to the Installable Software to be presented to, and
accepted by, the users of the Provisioning Technology in accordance with the
Specification. By using Provisioning Technology in such a manner and making it
available in accordance with the Specification, you further acknowledge your
agreement to, and the acquisition of all necessary rights to permit the
following:
1. A series of actions may occur (&quot;Provisioning Process&quot;) in which a user may
execute the Provisioning Technology on a machine (&quot;Target Machine&quot;) with the
intent of installing, extending or updating the functionality of an
Eclipse-based product.
2. During the Provisioning Process, the Provisioning Technology may cause third
party Installable Software or a portion thereof to be accessed and copied to
the Target Machine.
3. Pursuant to the Specification, you will provide to the user the terms and
conditions that govern the use of the Installable Software (&quot;Installable
Software Agreement&quot;) and such Installable Software Agreement shall be
accessed from the Target Machine in accordance with the Specification. Such
Installable Software Agreement must inform the user of the terms and
conditions that govern the Installable Software and must solicit acceptance
by the end user in the manner prescribed in such Installable
Software Agreement. Upon such indication of agreement by the user, the
provisioning Technology will complete installation of the
Installable Software.
Cryptography
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
Content may contain encryption software. The country in which you are currently
may have restrictions on the import, possession, and use, and/or re-export to
another country, of encryption software. BEFORE using any encryption software,
please check the country&apos;s laws, regulations and policies concerning the import,
possession, or use, and re-export of encryption software, to see if this is
permitted.
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
Java and all Java-based trademarks are trademarks of Oracle Corporation in the
United States, other countries, or both.
</text>
</license>
<plugins>
<plugin id="slf4j.simple"/>
</plugins>
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
<features>
<feature id="org.eclipse.platform" installMode="root"/>
<feature id="org.eclipse.cdt" installMode="root"/>
<feature id="org.eclipse.cdt.autotools" installMode="root"/>
<feature id="org.eclipse.cdt.build.crossgcc" installMode="root"/>
<feature id="org.eclipse.cdt.cmake" installMode="root"/>
<feature id="org.eclipse.cdt.meson" installMode="root"/>
<feature id="org.eclipse.cdt.docker.launcher" installMode="root"/>
<feature id="org.eclipse.cdt.debug.gdbjtag" installMode="root"/>
<feature id="org.eclipse.cdt.debug.standalone" installMode="root"/>
<feature id="org.eclipse.cdt.debug.ui.memory" installMode="root"/>
<feature id="org.eclipse.cdt.launch.remote" installMode="root"/>
<feature id="org.eclipse.cdt.launch.serial.feature" installMode="root"/>
<feature id="org.eclipse.cdt.testsrunner.feature" installMode="root"/>
<feature id="org.eclipse.launchbar" installMode="root"/>
<feature id="org.eclipse.launchbar.remote" installMode="root"/>
<feature id="org.eclipse.tm.terminal.feature" installMode="root"/>
<feature id="org.eclipse.tm.terminal.connector.cdtserial.feature" installMode="root"/>
</features>
<configurations>
<plugin id="org.apache.aries.spifly.dynamic.bundle" autoStart="true" startLevel="2" />
<plugin id="org.apache.felix.scr" autoStart="true" startLevel="2" />
<plugin id="org.eclipse.core.runtime" autoStart="true" startLevel="4" />
<plugin id="org.eclipse.equinox.common" autoStart="true" startLevel="2" />
<plugin id="org.eclipse.equinox.event" autoStart="true" startLevel="2" />
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
<plugin id="org.eclipse.equinox.p2.reconciler.dropins" autoStart="true" startLevel="4" />
<plugin id="org.eclipse.equinox.simpleconfigurator" autoStart="true" startLevel="1" />
<plugin id="slf4j.simple" autoStart="true" startLevel="2" />
Change standalone debugger to no longer limit number of bundles The maintenance of having a streamlined standalone debugger that starts as fast as possible is no longer possible. See for example #591 - therefore when using standalone debugger, use the same sets of plug-ins/features as the product it is installed in uses. The side effect is that the standalone debugger in this use case will start slower and extra "stuff" will be present in this UI. For people just building the standalone debugger, provide a minimum feature set. This will be many more bundles than before, but should still provide a reasonably small set that starts well. This simplification also includes removing the the duplicates set of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These provided a simplified version of CDT's documentation targetted at just standalone debugger. However there are a few problems related to this duplication: - The two sets of docs were not kept in sync - The standalone docs appear in the online help, leading to duplicated entries - With the config.ini changes above, there is no way to exclude the main docs in the standalone case, so remove the duplicate A number of directly related clean-ups are included too: - Remove the `ConfigGenerator.java` that stopped being referenced in PR #761 - Complete the removal of `build-standalone-debugger-rcp` profile that was started in #761. There is a small drawback to not having this profile, the standalone debugger is very slow to build compared to the rest of CDT. If this becomes a problem, restoring this profile along with the changes made in #761 is reasonable. - bring debug.product's licenses up to date - modernize command line args to eclipse when using debug.product Fixes #781
2024-05-10 10:18:07 -04:00
<property name="osgi.bundles.defaultStartLevel" value="4" />
</configurations>
</product>