Community
Participate
Working Groups
For plug-in development, PDE distinguishes between the plug-in projects you are working on (source plug-in projects) and plug-in projects you are working with but not actually changing (binary plug-in projects). Making this distinction afforts the user the benefits of having full source for everything in their workspace where it's easily browsed and searched, while permitting economies because the latter kind of projects do not actually have to be (re) compiled. This work item is to support a similar notion of library project for Java development in general. The user would be able to flag a Java project as a library project; JDT would know how present library projects appropriately at the UI, and how to deal with them more efficiently using generated binaries. [JDT Core, JDT UI]
Library project got deferred post 3.1
*** Bug 106209 has been marked as a duplicate of this bug. ***
Summary set to match work item from the R3.2 plan. New text for the item is: For plug-in development, PDE distinguishes between the plug-in projects you are working on (source plug-in projects) and plug-in projects you are working with but not actually changing (binary plug-in projects). Making this distinction affords the user the benefits of having full source for everything in their workspace where it's easily browsed and searched, while permitting economies because the latter kind of projects do not actually have to be (re)compiled. This work item is to support a similar notion of library project for Java development in general. The user should be able to flag a Java project as a library project; JDT would then know how to present library projects appropriately at the UI, and how to deal with them more efficiently using generated binaries. [JDT Core, JDT UI, PDE]
It feels like this isn't something specific to Java, but more a way to lock projects so they stop building in reaction to changes. Could we imagine something at the project resource level which would lock a project, and turn all its builder off implicitly until the project is unlocked ? Something in the same area as closing a project, except its contents is still available. If we did handle this notion at the Java only level, it would feel too specific and inconsistent in presence of pre/post builders. Ideally, a project could be locked, clients would be notified, and could react upon. While the project is locked, all resource changes are recorded by the build manager, and batched for the next effective build action. So builders could still perform incrementally. I presume that in a locked project, resource changes would still be notified, and thus source models (JavaModel) would keep updated though; unless we flip a switch to consider the existing binaries (if any) on the classpath in place of the original source folders (this is a pure JDT issue to decide here). JohnA: would you consider such an addition in the platform ?
Comment from JohnA: I'm not very familiar with the requirements motivating library projects, but it seems like it would not be something that is toggled on or off by the user. I.e., I would think a library project is created by a different wizard, and there would never be any builders installed on it. However, there is API today for turning builders on or off, either by removing from the build spec or calling ICommand.setBuilding(buildKind, false) on the commands in the build spec. If the only interesting characteristic of library projects is the lack of builders, that's easy to do.
Ideally, users could lock projects, pretty much like they can close them currently. The tricky part is if deregistering builders only, then it produces outgoing changes (project description) which is unhappy, and also is entirely missing reacting to incremental changes (once unlocked in the end). So this would force users to re-issue a full build in the end, when it could be handled as a deferred incremental build. The usecase we know about is clients using full source workspaces, where most of the projects are in fact not changing for them, but still the incremental updates are causing grief. Think of developping Eclipse in a full-source workspace (checking out CVS projects), then if individual changes are checked out in SWT, you do not want them to ripple through the entire workspace, until you unlock the SWT project. So once build, you'd like to pretty much lock the project as it is, and isolate it from normal build activity. One thing I am wondering is: is that much different from our scoped builds based on working sets ? Cannot this usecase be simply handled by better constructing a default working set for builds ? (each time you lock a project, it gets excluded from this working set).
Given we have many CC'ed people on this bug, can we get more usecases described in this bug report, to better understand what exactly needs to happen ?
Thinking more about it. What if a locked project was unmodifiable (sort of read-only for entire resource tree). Then clients, would not have to stop reacting to changes, as these wouldn't occur. i.e. no more editing, no more CVS actions, no more refreshing of underlying file changes (if any), no rsc change broadcasted. Once unlocked, the platform would broadcast changes (if any, but shouldn't be any, normally). JDT wouldn't need to switch from using source folders of locked projects to bin folders, as the resource tree would be frozen. Would this match expectation of feature request ?
BTW - it is getting late in the game for conducting API change (these must be frozen before feb. 17th - milestone 5). I suggest this plan item get deferred post 3.2, given we got zero feedback.
Deferring.
To be investigated for M5
Not for 3.5
*** Bug 343134 has been marked as a duplicate of this bug. ***
