Community
Participate
Working Groups
3.0 M7 it seems that external tool builder names must be globally unique i wanted to have 2 external tool builders for /usr/bin/make for 2 different projects, both called 'make clean' - eclipse would not allow me this restriction seems unnecessary
This is an artificial limitation in the launch framework, imposed by the launch dialog. The only real limitation is that two configs in the same directory/folder (metadata) cannot have the same name (since the name is used as the file name). We should be able to relax this.
If a configuration isn't shared, the name has to be unique because we store the configs in files in the same location (the metadata area). For shared configs, we can get more complex. So long as the file location isn't the same, the names can be the same. But we need to make sure that when the user changes a shared config's location that we re-verify that there's no name collision.
>If a configuration isn't shared, the name has to be unique because we store the >configs in files in the same location (the metadata area). sounds like an implementation detail that surfaces as nuisance for users
Deferred, post 3.0. Too late for this change. As well, it creates problems in the LCD when configs have the same name (i.e. the tree needs to render more info to be able to distinguish them).
Consider for 3.1
Deferred
*** Bug 103029 has been marked as a duplicate of this bug. ***
*** Bug 107274 has been marked as a duplicate of this bug. ***
*** Bug 130204 has been marked as a duplicate of this bug. ***
*** Bug 135258 has been marked as a duplicate of this bug. ***
*** Bug 154774 has been marked as a duplicate of this bug. ***
*** Bug 163303 has been marked as a duplicate of this bug. ***
*** Bug 165151 has been marked as a duplicate of this bug. ***
Created attachment 54801 [details] patch This is a work in progress that allows configs to have the same name if stored in different locations. It enhances the way "local" configs are stored. Rather than storing them all in one directory in the metadata, a directory structure is created based on the resource that a configruation is stored with. It effectively gives configurations a namespace based on their resource mapping. So, two configs can have the same name if the're not associated with the same "container" resource. It does not add UI support to distingusish between configs with the same name.
What if launch configuration is not associated with any resource? Or what if it's associated with multiple resources? P.S. Sorry, I didn't have time to look at the patch itself.
No resource == default package (i.e. all configs that have no resource association share the same namespace). Multiple resoruces == use the first resource (not sure what the rule should be here - probably should use the "deepest" resource in the association, but if it's cross project resources, then not sure what to do).
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
*** Bug 365232 has been marked as a duplicate of this bug. ***
As requested by Denis Roy (see comment above), I would like to have this bug reopened, because it seems as if the patch has never been applied or is not functioning. The issue still exists in Version: Indigo Service Release 1 Build id: 20110916-0149 Because this is an enhancement request, I would like to suggest an related enhancement which allows the use of a global external tool launcher by a logical reference (no file system soft link) instead of copying it to the project folder. (It could be another option besides creating a new builder or importing a global one). I think this is the actual reason why most people would like to have the same name for a builder in multiple projects. It would even allow to migrate the same project on different platforms without changing the external tool builder launcher each time you switch between them (consider for example different OSs or different tools doing the same thing). This would come in very handy e.g. for teams working on a common source code repository which contains the project configuration as well.
(In reply to comment #20) > Because this is an enhancement request, I would like to suggest an related > enhancement which allows the use of a global external tool launcher by a > logical reference (no file system soft link) instead of copying it to the > project folder. (It could be another option besides creating a new builder > or importing a global one). > I think this is the actual reason why most people would like to have the > same name for a builder in multiple projects. It would even allow to migrate > the same project on different platforms without changing the external tool > builder launcher each time you switch between them (consider for example > different OSs or different tools doing the same thing). This would come in > very handy e.g. for teams working on a common source code repository which > contains the project configuration as well. Could you create a separate bug for the additional request?
Latter enhancement request moved into seperate enhancement request (Bug: 400126).
Is this really such a toughie?
Created attachment 256759 [details] testprojects This is still a problem with Mars, exactly as described in comment #0 . The limitation seems totally artificial since the following workaround works: Project1 > Properties > Builders, New, "testbuilder", Save Project2 > Properties > Builders, New, "testbuilder" --> Error: A 'Program' configuration with that name already exists. After CLOSING Project1 the "testbuilder" can be added and seems to work OK. Also, when IMPORTING attached projects, the builders seem to work OK. Can the team confirm that this workaround is acceptable ? And could the odd UI limitation be finally lifted? CQ:WIND00-WB3-51391
Going through the patch from Comment #15, I think we are stuck for multiple resources scenario
