Bugzilla – Full Text Bug Listing
| Summary: | [Import/Export] Unable to add project to nested directory. | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Paul Kimelman <paulkimelman> |
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alex.blewitt, dev, john.arthorne, mlists, paulkimelman |
| Version: | 3.2.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Paul Kimelman
*** This bug has been marked as a duplicate of bug 35973 *** I am sorry, but I do not see how this is a duplicate of the 35973. That bug report is asking for a project packaging mechanism, similar to Developer Studio's Solutions (container of related projects). All I am asking for is that Eclipse not try to force project directories to be embedded in the workspace directory (or completely away from the workspace). That is 35973, is looking for a whole new policy on project management. I am only pointing out that there is an unneeded error in the projection creation code. If you do not agree, please explain why. I seem to recall this bug can be triggered by checking out projects from a CVS server too when the structure is as described. The checkout tries to create subdirectories in the workspace location (which fails). However, that is from memory and I could have been confusing it with project import (or vice versa). (In reply to comment #3) > I seem to recall this bug can be triggered by checking out projects from a CVS > server too when the structure is as described. The checkout tries to create > subdirectories in the workspace location (which fails). However, that is from > memory and I could have been confusing it with project import (or vice versa). I do not know about CVS or Subversive, but SVN goes nuts in this case. You get non-stop errors and then Eclipse crashes. So, I never tried it again (once was enough fun for me ;-) (In reply to comment #2) > is an unneeded error in the projection creation code. > If you do not agree, please explain why. > You could introduce problems with project specific settings, for one. For example, having a project compiling as 1.4.2 that includes the subfolder, but making the subfolder a project that is 5.0. But we can't see JDT information in the platform (just like we can't see that it doesn't matter fot CDT) so the restriction is in place. It would be resolved by the solution for bug 35973. which is more expanded and flexible project management (which is why it was resolved as a duplicate, that bug will consider many corner cases that removing the restriction will introduce). But it is not as easy as just removing the restriction (that would introduce a number of hard to track down errors). PW I think the check is an unnecessary hack. Sure, there would be things that might not work; but there's demonstrably things that don't work now by having this restriction in place. And those people that want to fly with potentially-unsupported-layouts would be on their own; but at least you'd give them the choice of whether they want to do this or not. And hey, you'd even get bug reports about what doesn't work should you relax this restriction. Eclipse has always been open (e.g. with potentially breakable 'internal' apis) with the implicit assumption that using them isn't supported. Even though they're not supported per se, people make good use of them. Similarly, although you can think of situations (e.g. 1.4.2 and 5.0) where this wouldn't work, I'd be willing to bet that the people who *want* this would be using 1.4.2 or 5.0 in both places, and so wouldn't run into trouble. You're also blinkering yourself to other uses e.g. for other types of project layouts (or hey, plain projects) where this kind of restriction is totally unhelpful. So why prevent something if it has a set-of-known-good and set-of-known-bad uses, just because the set-of-known-bad is empty? I mean, you might as well prevent people creating PDE projects because they can't handle resources at anything other than the top layer. There was a UI bug in 3.2 that prevented this, but this is now supported in 3.3. *** This bug has been marked as a duplicate of bug 147727 *** *** This bug has been marked as a duplicate of bug 147727 *** (In reply to comment #5) ... > You could introduce problems with project specific settings, for one. For > example, having a project compiling as 1.4.2 that includes the subfolder, but > making the subfolder a project that is 5.0. All of the problems are easily created once you go off default now. You can create projects anywhere outside of the workspace directory tree and this means also creating nested outside. So, if you have those bugs, you have not done anything to stop them anyway. The most common nesting is ***not*** the kind you are you talking about. I am talking about workspace/test/proj1, workspace/test/proj2, ..., workspace/test/projN type nesting. You are talking about workspace/proj/sub-proj. If you use the kind you are speaking of, you have all sorts of hassles today (exclude rules for one). So, removing the restriction is not the same as building in a whole new paradigm for complex project/sub-projects and/or solutions (which is a good idea, but not related). This bug report is an easy to fix/change and makes it easy to use a directory model common to many build setups. Note that you are free to add a warning about nesting, but you do not check for that when outside the workspace tree, so it is a weak test today. |