[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[buckminster-dev] Re: settings working proposal
|
Hi Robert,
thanks a lot for writing this proposal. It is a complex issue and the
only way we can come up with a satisfying result that solves real life
problems is to have discussions like this.
Robert Dale wrote:
On the headless site, AFAICT there is no configuration file, just
command line options. So here's where we could potentially broaden the
scope of a settings file to allow for all the options outside of
credentials - the existing command line options, some or all of the
options available in the GUI preferences, interactivity. Being in
headless mode, this configuration file would be best suited in text
(xml). Where do we put this headless configuration file?
${user.dir}/.buckminster/headless.xml
The Buckminster headless has access to the same preferences that the UI
has. The drawback as I see it is that they are stored in the workspace
meta-data (and thus tied to one particular workspace) and not very easy
to change unless you start an IDE on that workspace. The proposed XML
gives a better overview and is easier to edit.
We have put some effort into the headless preferences framework
(getpref/setpref/lsprefs) commands in order to configure the preferences
but as the structure becomes deeper that approach is not really
feasible. It is OK for key=value constructs like targetPlatformPath=xxx
but not for setting passwords on specific URL's or protocols.
Another configuration aspect is that one might want specific settings
when running a particular Buckminster action. Picture an action that
builds an update site and then publishes it on an FTP server. In order
to build there is a need to access a keystore (for jar signing). In
order to publish, credentials on the ftp server are needed. For this it
might be more suitable with a "build configuration", explicitly
appointed when the command is executed, then a general purpose
configuration file.
Do we need three places, the preference store, a general configuration
file, and a build configuration to store settings?
Perhaps it would be enough if all commands could appoint a specific
configuration file? Then again, the concept of a default configuration
file is appealing. I don't think it should be specific to headless
though, it should be applied when doing things from the GUI as well.
So now one potential issue becomes apparent: I have two configuration
files in two different places. In my particular use case I primarily
will use buckminster headless in continuous integration. Those
settings, atleast the credentials piece, will be very different than
what I store on my developer box. In any case, I think if a button were
added to the GUI to generate a headless.xml that most problems would be
taken care of. It would be a nice template to start out with anyway.
The problem that I see with this approach is that there is a vast amount
of preferences and other settings that needs to be mirrored. Compiler
settings, target platform, Execution environment, etc. The keyring stuff
is just a small part of it.
Our approach so far has instead been to provide a "template workspace".
This is a zipped workspace without any projects that is created in
advance using an IDE. In this workspace, all preferences, passwords,
repositories, etc. has been defined and saved.
I don't know how eclipse headless works now WRT cvs, svn, etc tools and
credentials. What I am thinking is that buckminster would pass them the
credential information they need to access a resource instead of
configuring each tool individually. This would of course be optional.
Each tool provide their own configuration with GUI and all allowing you
to specify repositories and credentials for each. It would be a fairly
large undertaking if we were to take care of all of this for them.
Especially since both they and the Eclipse platform change over time.
In headless mode, I mentioned interactivity. What this means is whether
or not buckminster will try to interact with you, for example to obtain
a user/pass. This could be a command line option as well.
Good point.
I have been unable to locate any useful information on the keyring
capabilities and API. If anyone has any pointers, I would greatly
appreciate it.
I sent a mail to the platform-core-dev@xxxxxxxxxxx mailing list asking
about this. If possible, I'd like to always use the keyring and other
capabilities that Eclipse provides.
Kind Regards,
Thomas Hallgren
