Hi Devs,
I use config.ini and launch.ini files to configure the Equinox environment.
I have listed all the bundles with proper start level in config.ini. I also
org.eclipse.update.configurator_3.2.100.v20070322.jar. When some bundles
being added in config.ini, the prior bundle will be in STARTING
Are the bundles in the STARTING state using a lazy activation policy? The
bundle would have an Eclipse-LazyStart or Bundle-ActivationPolicy manifest
header. When a bundle uses a lazy activation policy it will wait in the
STARTING state for the first class to be loaded out of it (the so called
Hi,
I noticed in the last integration build that a new method
org.eclipse.ecf.core.util.StringUtils#String replaceAllIgnoreCase(String,
String, String) has been added since 3.4M6. It is located in the bundle
org.eclipse.ecf.identity.
This is considered to be a new API added after API freeze
This is another interesting issue of consuming components which may have a
process that does not strictly adhere to the eclipse one or may be at a
different stage in their release cycle.
IMO, since we are consuming a component that exports API, I would argue
that it is important for us consumers
Hi Olivier,
This utility method was added as part of a bug fix to one of our
provider bundles, and the committer didn't initially realize that the 6
ECF bundles going into the platform integration build were now under API
freeze.
When he realized that this method was added to a bundle under
Hi Olivier,
Olivier Thomann wrote:
Hi Scott,
This didn't cause any work for anybody except the build machine :-). The
check is done during each build. It was easy to detect it without any
extra work.
That's nice to know...maybe releng would be willing to share the scripts
to run the
Scott, here's how we run the tool in the build
target name=apiTooling
property name=reference value=
${buildDirectory}/apitooolingreference /
mkdir dir=${reference} /
property name=reference_location value=
