Organize JDev for large applications

Question

Hello JDev team,
In order to properly manage very large applications and different versions of the same application (like maintenance and development) in the same environment, there are various settings that would find their more appropriate place at the level of the workspace.
I already saw some other threads discussing similar topics, I would only like to put them together and try to get some schedules :-)
1. One problem is that there are no nested workspaces, and you don't have good "visibility" outside your own workspace (one example, you cannot create a BC Client Data Model unless the BC project is in the same workspace).
Nested workspaces would be great for properly organizing a large application. If you implement this, please don't forget the visibility "details".
2. A quite different problem is related to the definition of libraries. Once you have to manage in parallel, in the same environment, different versions of the same application, things become hard to manage.
Most of the projects should have their associated library defined, as there are relations between projects. But a library entry is absolute, so it stands for one version. When you have to switch to another version (which is also under SCM), there are different physical paths on the disk, so different values for the libraries. And you have to change (one by one or directly in libraries.xml) their definitions.
This would be solved naturally if the libraries were defined for a workspace. And would also provide the possibility to have relative paths rather than absolute ones, which is easier to manage.
3. Base classes. It is nice to have this in the global Preferences, but, as somebody else noticed before me, it might be necessary sometimes to have different base classes for different applications, all in the same development environment. This comes similar to having base classes defined (also) at the level of the workspace.
4. Debugger/Breakpoints/Default Action. This is another kind of preference I would like to have at the level of the workspace, or even for each project. Especially because of the "Group of Breakpoints" section.
5. Deployment. Here, a new option "Relative to Workspace Directory" would do. Or, allow the definition of the default deployment directory for each workspace.
6. Web Browser/Proxy. Well, here my problem might be more specific. We access internet resources via a proxy, so when it comes to accessing Oracle resources (like Check for Updates...) from JDeveloper, the proxy setting is useful, even required.
But, in our intranet development, we do not use a proxy (not the same, anyway). So, for normal development purposes, there should be no proxy.
In this case, what I would like would be to have the global setting in the IDE preferences used for global resources, while the setting in the workspace (if any) will be used for the application-specific resources (e.g. servlet URL).
I am quite sure I did not cover all the possible enhancement topics, but I hope things will be checked carefully.
Apart from adding valuable features for developers, the approach of moving certain preferences from the IDE to a "work component" (workspace, project) would also help team-work.
Once one team member will set some preference(s) for a workspace (and put it under SCM), this setting(s) will be automatically available to all other team members.
Could you please comment my issues and tell me which of them (with the solutions that you foresee) could integrate 9.0.4?
Thank you,
Adrian

Answer 1

Hi Adrian,
Thanks for the detailed feedback.
I agree with you that there are significant issues when using project files at the moment in a team environment, particularly when an SCM system is involved. And since a recent survey indicated that the majority of JDeveloper users use some kind of SCM system, it's particularly important that we address this in future releases.
At the moment, I'm putting together some suggestions for future changes in this area from the point of view of the feature team who develop SCM support in JDeveloper. Your ideas are useful input into this process. Sadly, it's unlikely that any major changes to the way project files are stored will make it into 9.0.4, since 9.0.4 has already gone into "bugfix only" mode, and the focus of the 9.0.4 release has been on performance improvements and stability. However, we are looking at this issue for a future release (possibly 9.0.5, although these discussions are at a very early stage).
I've included comments on some of your specific points below.
1. Nested workspaces
There was some discussion about whether we should use nested projects a long time ago (i.e. get rid of the concept of a workspace altogether, and just allow projects to contain, and presumably inherit properties from, other projects). This is currently being tracked as ER 2048949. It requires a substantial change to the architecture of JDeveloper and could have a massive effect on components across the IDE. I believe that a lot of the issues with project files can be solved in other ways without going to the extreme of using nested projects / workspaces.
2. Library Definitions
Project-scope libraries should hopefully make this a whole lot easier in 9.0.3. I also like the idea of defining libraries at the workspace level so that they can be shared between projects; alternatively, using a "library definition" file as a separate, version-controllable resource that can be referred to by a project. I've filed ER 2689043 to track this.
3. Base Classes
This is a BC4J thing, and a bit outside my area of knowledge :) I'll pass your suggestions along.
4. Debugger Preferences
I'm not sure what you mean by "group of breakpoints section"
5. Deployment
Filed ER 2689052
6. Web Browser/Proxy
You might be able to make use of the "Exceptions" field in the proxy settings to help with this. Within Oracle, we have exactly the same issue, but normally use an exception list that looks something like this: "localhost|127.0.0.1|*.oracle.com|*.oraclecorp.com|*.oracleads.com"
One of the areas I'm interested in seeing improved is the concept of "configurations" that we currently have in project files. For example, it would be nice to define a workspace-scope configuration that's inherited by projects. Also nice would be the ability to allow read-only configurations (that are source controlled as part of the checked in project definition) and user/view-specific configurations (which would not be version controlled). The user/view specific configurations could inherit preferences from the read-only configurations, and the user could override things in a way that wouldn't affect other users (e.g. in the "Paths" preferences, change the output directory to one on their own local machine) without having to check out the project file from source control.
Thanks,
Brian
JDev Team