[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ant-dev] Copying existing configs to use as project builders
|
yes. This is what I meant. Note that I am assuming thta someone can
create and manage a launch config as a file in a project. That way they
can version it, share it, ...
Jeff
"John Arthorne"
<John_Arthorne@xxxxxxx> To: platform-ant-dev@xxxxxxxxxxx
Sent by: cc:
platform-ant-dev-admin@ Subject: Re: [platform-ant-dev] Copying existing
eclipse.org configs to use as project builders
12/04/2002 01:20 PM
Please respond to
platform-ant-dev
Ideally the handle would not encode the location of the configuration file.
This seems to be the main reason you can't currently pass by reference. I
believe Jeff is suggesting that the handle be used simply to lookup the
launch configuration in some tool registry. As you say, this sounds like
it would require a different type of handle from what you have currently.
Since you already seem to require that external tool names be unique, this
sounds like a good candidate.
"Darin Wright"
<Darin_Wright@xxxxxxx> To:
platform-ant-dev@xxxxxxxxxxx
Sent by: cc:
platform-ant-dev-admin@ Subject: Re:
[platform-ant-dev] Copying existing configs to use as
eclipse.org project builders
12/04/2002 12:31 PM
Please respond to
platform-ant-dev
My assuption is that the build spec would contain a handle of a launch
configuration....however, perhaps Jeff is insinuating that the build spec
contain some other "reference" to a launch configuration - perhaps by name?
Darin
----- Forwarded by Darin Wright/WPG/OTI on 12/04/2002 11:33 AM -----
Darin Wright
To: platform-ant-dev@xxxxxxxxxxx
cc:
12/04/2002 Subject: Re: [platform-ant-dev] Copying
11:32 AM existing configs to use as project buildersLink
Launch configurations are represented by handles. The handle for a launch
configuration descibes its location (file which contains the launch config
attributes). When a launch configuration is shared, the handle is workspace
relative (and can thus be shared). When a launch configuration is local, it
points to a local path in the file system (which cannot be shared). Thus,
to be able to share a config as a project builder, the config has to be
shared.
Darin
"Jeff McAffer"
<Jeff_McAffer@xxxxxxx> To: platform-ant-dev@xxxxxxxxxxx
Sent by:
platform-ant-dev-admin@ cc:
eclipse.org Subject: Re: [platform-ant-dev]
Copying existing configs to use as project
builders
12/04/2002 11:11 AM
Please respond to
platform-ant-dev
Why does the config *have* to be in the project? The project builder could
be configured to say "run the config called fred whatever fred might be"
If a team requires the sharing of launch configs (including external tools
configs), they should be put in *a* project somewhere and loaded by the
lauch manager when the project is opened.
Jared Burns
<jared-eclipse@xxxxxxxx To:
platform-ant-dev@xxxxxxxxxxx
m> cc:
Sent by: Subject: Re:
[platform-ant-dev] Copying existing
platform-ant-dev-admin@ configs to use as
project builders
eclipse.org
12/04/2002 11:08 AM
Please respond to
platform-ant-dev
On Tuesday 03 December 2002 10:34 pm, Jeff McAffer wrote:
> I second the unreasonability.
I think you misread Darin's message. :-)
> I don't know the technical reasons behind it
> however. The copy proposal might work as a starting point but perhaps
the
> near future should include referencing?
I was hoping to just gloss over that "not technically feasible" bit, but I
suppose I should explain.
The config used by a builder needs to be stored with the project so that
the
builder will stay with the project when it is shared. If the config file
has
to reside in the project, then we can't *truly* share the configs (files
can't be in two places at once). The best we could do is fake it by keeping
the multiple copies in synch. But this isn't possible. For example, say I
have projects Foo and Bar that share the same config. If I check out
project
Foo and edit the project builder, and my friend Bob checks out project Bar
and edits the other copy of the builder, when we check Foo and Bar back
into
the repository the fake synchronization will be lost.
Everyone (myself included) would like the by-reference solution to work,
but
it looks to be impossible.
- Jared
_______________________________________________
platform-ant-dev mailing list
platform-ant-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ant-dev
_______________________________________________
platform-ant-dev mailing list
platform-ant-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ant-dev
_______________________________________________
platform-ant-dev mailing list
platform-ant-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ant-dev
