Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Generated configuration file overwrites specified properties


I updated the examples, one of the links they are downloading from was out of date.

Yes, if you have metadata for your own product then this problem would be solved.
The config.ini and eclipse.ini files are updated by p2 because they often need to change when new stuff is installed or existing bundles are updated.

If you already have a build process which produces your features and plugins, it should be simple to modify the "ADT Part 2" example to package them together with the CDT & Eclipse Platform into a product.  
In that example the "adt.feature.builder/product/adt.product" describes the product.  You can search for references to "mylyn" and replace those with your own feature.  Alternatively this example can also build your feature directly if you were to replace the "adt.feature".

-Andrew



From: Richard Horbach <richard.horbach@xxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date: 03/24/2010 07:10 AM
Subject: Re: [equinox-dev] Generated configuration file overwrites specified        properties
Sent by: equinox-dev-bounces@xxxxxxxxxxx





We have a different model of building and installing the product. We do
not use ant nor the Eclipse environment to build the product. For
installing required items, we do not depend on Eclipse.

Our (GUI) product -part of a complete C Compiler toolchain- is build on
top of Eclipse and CDT. The plugins are build from the command line,
using the java compiler and the jar program. The complete Compiler
product is installed using install shield. All plugins, including CDT
and Eclipse platform plugins, are installed at installation time in the
plugins directory, no need for downloading or updating. We ship a
feature.xml file in the features/myproduct directory, that sums up all
self developed plugins. Furtermore we supply an eclipse.ini and the
config.ini, the one I mentioned earlier, in the configuration directory.
These files are not generated, but put together manually.
That is basically all. Until now it was not necessary to create p2
metadata (and admittedly, we did not investigate the p2 mechanism very
thorough yet), so we have no metadata available for our product, just
the feature.xml.

I want to avoid that the configuration settings are regenerated, and
that the org.eclipse.platform.ide product is used. If I have the p2
metadata available, than this problem would be solved, right?

(FYI: the examples you are referring to, do not build anymore.)

Thanks,
Richard

Andrew Niefer wrote:
>
> How did you build this product?
> The metadata for the product generally specifies the settings for
> these properties.
>
> Here it looks like you are getting the settings that are specified by
> the org.eclipse.platform.ide product.  Are you just taking the
> platform.ide and copying your stuff over top of it?
> It sounds like the p2 metadata just has the platform.ide settings, on
> first start p2 discovers the bundles you copied on top of everything
> reconciles the install for you, this would cause the configuration
> settings to be regenerated.
>
> I would suggest taking a look at these two examples I wrote last year:
>
http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html
>
>
http://aniefer.blogspot.com/2009/07/adt-part-2-more-like-epp.html
>
> It is probably simplest to build things as described in the second
> post (ADT part 2: More like the EPP), though it would be good to read
> the first post as well.  They both contain references to examples in
> cvs that you can download and run.
>
> -Andrew
>
>
> From:                  Richard Horbach <richard.horbach@xxxxxxxxxx>
> To:                  equinox-dev@xxxxxxxxxxx
> Date:                  03/23/2010 10:01 AM
> Subject:                  [equinox-dev] Generated configuration file overwrites
> specified        properties
> Sent by:                  equinox-dev-bounces@xxxxxxxxxxx
>
>
> ------------------------------------------------------------------------
>
>
>
> We start our product, based on Eclipse, with our own splash screen. In
> the configuration directory we therefore have specified the following
> properties in the config.ini file:
> - eclipse.product=com.mycompany.myproduct.ide
> - osgi.splashPath=platform\:/base/plugins/com.mycompany.myprod uct
> - osgi.configuration.area = @user.home/.eclipse/configuration
>
> When starting the product for the very first time, the proper splash
> screen shows up. Therefore, the local config.ini file was read and
> parsed correctly. When closing the application again, a new created
> configuration file is written (written by EquinoxFwConfigFileParser) to
> the location specified in 'osgi.configuration.area'. This generated
> config.ini file however, contains wrong/overwritten properties:
> - eclipse.product=org.eclipse.platform.ide
> - osgi.splashPath=platform\:/base/plugins/org.eclipse.platform
>
> If I now restart the product for a second/next time, the default Eclipse
> splash screen is shown; The setting in the configuration area apparently
> takes precedence over the local setting.
>
> I have this problem since I switched over from Eclipse 3.5.0 to version
> 3.5.2. In Eclipse 3.5.0 this mechanism worked well, since no entries for
> 'eclipse.product' and 'osgi.splashPath' were written back.
>
> Should I log a bug in bugzilla for this issue, or could there be
> something wrong with my configuration?
>
> Regards,
> Richard Horbach
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
>  

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



Back to the top