Community
Participate
Working Groups
The project generation wizard will not accept source and target paths outside a common directory root. This inconvenient, because, in my current (NetBeans, VisualCafe) establishments I am spoiled with the ability to generate output across partition boundaries. Worse, I could not figure out how to share overlapping source directories for different projects. File system and project management are logically independent so the current tight coupling seems artificial and unnecessary. With great regards and anticipation, George
I think he means the new java project wizard. I know that overlapping source folders and external output folders have been discussed, but I was unable to find matching existing bugs.
The mechanism for sharing source folders is to define a project containing them in a source folder. Then other projects can prereq this project, and will both see the same sources. Now, for outputing classfiles outside the workspace, this was done on purpose along the line of Eclipse tooling. The Java builder processes .java resources and writes out .class resources. Those can in turn be processed by another tool which is reactive to .class file changes. In order for this mechanism to work, the .class resources have to live inside the workspace area. Now you can fragment your workspace, so that some projects live on other partitions (see the project creation wizard, and do not let it use the default location). I understand though that from a pure Java IDE standpoint, you might still want this functionality, and we might consider it, but the drawback would be that you would then loose other tool contributions if they want to process .class files. Maybe all you need to do is to actually export/deploy those .class files once you are done, and this is a related but separate feature.
Ok to close ?
More feedback from: george@wright.com.au (George Korosy) Tried to follow your advice, but the stumbling block is that any name I enter in wizard for a freshly created project is treated as a directory name, and source and target directories must be relative to (meaning in this case: contained under) that node. So, as an example, the on-disk structure of the project I currently work (using Forte and VisualCafe, with Forte being the favorite) is something like this: sourcepartition://projectW/com/companyname/packege-a sourcepartition://projectW/com/companyname/packege-b sourcepartition://projectW/com/companyname/packege-c sourcepartition://projectW/com/companyname/packege-c/package-c0 sourcepartition://projectW/com/companyname/packege-c/package-c1 sourcepartition://projectW/com/companyname/packege-c/package-c2 sourcepartition://projectW/com/companyname/packege-d targetpartition://projectW/bin/com/companyname/packege-a targetpartition://projectW/bin/com/companyname/packege-b targetpartition://projectW/bin/com/companyname/packege-c targetpartition://projectW/bin/com/companyname/packege-c/package-c0 targetpartition://projectW/bin/com/companyname/packege-c/package-c1 targetpartition://projectW/bin/com/companyname/packege-c/package-c2 targetpartition://projectW/bin/com/companyname/packege-d I have 2 main classes, one in package-c/package-c0 and one in package-c/package-c2, with 2 projects set up around them, and both projects relying practically on everything else, except for each other's leaf packages. So, if am correct, the only way to separate out these two projects is a grand-scale hard disk re-organization with 7 new projects in place of the current 2: partition4bothsourceandtarget://projectW/eclipseProjectA/src/com/companyname/pac kege-a partition4bothsourceandtarget://projectW/eclipseProjectA/bin/com/companyname/pac kege-a partition4bothsourceandtarget://projectW/eclipseProjectB/src/com/companyname/pac kege-b partition4bothsourceandtarget://projectW/eclipseProjectB/bin/com/companyname/pac kege-b partition4bothsourceandtarget://projectW/eclipseProjectC/src/com/companyname/pac kege-c partition4bothsourceandtarget://projectW/eclipseProjectC/bin//comcompanyname/pac kege-c partition4bothsourceandtarget://projectW/eclipseProjectC0/src/com/companyname/pa ckege-c/package-c0 partition4bothsourceandtarget://projectW/eclipseProjectC0/bin/com/companyname/pa ckege-c/package-c0 partition4bothsourceandtarget://projectW/eclipseProjectC1/src/com/companyname/pa ckege-c/package-c1 partition4bothsourceandtarget://projectW/eclipseProjectC1/bin/com/companyname/pa ckege-c/package-c1 partition4bothsourceandtarget://projectW/eclipseProjectC2/src/com/companyname/pa ckege-c/package-c2 partition4bothsourceandtarget://projectW/eclipseProjectC2/bin/com/companyname/pa ckege-c/package-c2 partition4bothsourceandtarget://projectW/eclipseProjectD/src/com/companyname/pac kege-d partition4bothsourceandtarget://projectW/eclipseProjectD/bin/com/companyname/pac kege-d (Should there be any better alternatives I skipped, please educate me ... ) The only gain is, that if I am correct, I will be able use Eclipse. On the contrary, there are quite a few disadvantages: (1) Restriction on partitioning source and target. (2) Limited reuse of directories, great increase in physical file paths -- the real packaging of our little project is actually far more complicated than this. (3) Under Forte / NetBeans, instead of mounting one single file system root for source and another single file system root for target (and this latter is only needed if I want to pack jars), I will mount several more, with sources and targets interleaved. (4) Source packages (or target packages), belonging together lgocally, are physically separated, while logaically independent entities (like corresponding java and class packages) are tied physically. (5) The current single sweep "get latest" in MS Visual Source Safe, will be replaced with long series of get latests, one per root directory. (You might like to point out that we should not need to use MSVSS in the first the, and I totally agree with you, but this is one of the rude facts of life here.) (6) Additional house-keeping, jar-packaging, and re-packaging for each and every update from source control. (7) As per aesthetics, it is just rude, clumsy and ugly. Project identity, source packaging, and output location are logically all independent of each other, and a good object oriented design (like, I assume, the Eclipse project) should not place artificial constraints. I am fully convinced, that your WorkSpace centric porject-setup-philosophy, and all eventual .class post processing plug-ins, would be adequately informed to do their work (if you really wanted to) with storing arbitrary directory pointers, rather than owning half of my hard disk. Jakob Braeuchi might have a similar problem -- please observe his November 27 posting, "Project References Runtime" in newsgroups. I am about to lodge another request for enhancement, because this ".java to .class, copy over everything else intact" compilation philosophy removes more from /bin then it should be authorized to do, while copies over heaps of unwanted garbage. Every one else here gave up on Eclipse after some one to two hours of frustration. I am the only one still holding on, but probably not for long -- despite some really smart things Eclipse can do, Forte is far more usable and developer friendly. Will check back for release 2.0 -- any hints on timing? (Why did you (or IBM, or the World) need Eclipse, instead of joining NetBeans?) Have a nice weekend, George
I would certainly not encourage a major disk reorganization, but unless I am still missing something, I would rather suggest a split in 3 projects: Common code and 2 client applications, see below: "ProjectW Common" project +- com/companyname/packege-a +- com/companyname/package-b +- com/companyname/package-c +- com/companyname/package-c/package-c0 +- com/companyname/package-a "Client1" project : prereq "ProjectW Common" on its classpath +- com/companyname/package-c/package-c1 "Client2" project : prereq "ProjectW Common" on its classpath +- com/companyname/package-c/package-c2 -------------- This organization allows you to manage the common code (framework?) separately from client code. The binaries for the common part will automatically contributed to client projects (Client1 and Client2). Now for deployment, you might want to bundle clients with common pieces or not (like DLLs I could see the benefit of not duplicating them). Projects should represent logical code bundles, e.g. when developping Eclipse a project is a plugin. Projects should be self-contained so that you can easily share them over a VCM. If you have fragments outside then it will be difficult to manage (version control etc...). Therefore the relationship between projects should be kept coarse-grain if possible, so as to minimize issues later in the game. You should probably have smaller projects in your application, rather than all in one (which then need some fine-grain sharing inside the project themselves). For upgrading your projects to the latest, you can simply select them all, and use "Replace from stream contents", and they will all be updated in one operation. Now I am curious about the copying issue you mentionned in the last paragraph. Is it related to the fact that resources are being copied to the output folder ? Or that we scrub the output folder when doing a full build ?
Might revisit after 2.0
Closing. Configuration flexibility was added in 2.1 and later.
Removing LATER
Worksforme now
