- This topic has 10 replies, 4 voices, and was last updated 20 years, 4 months ago by
.
-
Posts
-
I don’t know if this has been raised before, but I didn’t see any references in the related posts I’ve reviewed, nor could I find anything in the help/user docs. My project team is really hampered in our attempts to use ME because of the need to put absolute path references in the .classpath for libraries that are outside our project structure *and* all linked source/javadoc (even for libraries that are *in* our project structure.)
While most of our library jars are in our project’s WEB-INF/lib directory, we have a few (weblogic.jar for example) that are not part of our project. And even for the jars that *are* in WEB-INF/lib, we make sure that they contain only the .class files so that means we have to define links to their related source and javadoc which are also outside the project structure.
Now several of our developers configure their workstations differently and check out the project cvs-module to different locations on their workstations. This means that we can’t share the .classpath file that’s in the project’s cvs-module. We have to each save our own copy as .classpath-johndoe or .classpath-janedoe and this means remembering to rename on checkin and checkout.
What I feel is really needed is a generic way of defining workspace variables that can be used in *any* project config setting that involves path information. I would like to be able to say that on my workstation LIB_SRC_ROOT = d:/javalibs and the source link for the project’s /WEB-INF/lib/struts.jar is ${LIB_SRC_ROOT}/jakarta-struts-1.1-src. It seems that this kind of thing is supported for JDK/JRE settings, but not for path settings.
Is this capability part of what’s being considered in your “flexible project structure” requirements discussions?
kitm,
This functionality, the way you described it, is entirely handled by the Eclipse platform. Our flexible project structure is related to more flexible J2EE project structure layouts (e.g. Where do you stick your WEB-INF dir, what about your EJBs? What about web roots? etc. etc.).What you are asking for is really much more generic/higher level which would be a request for the Eclipse team.
I have a question though… why do you have the .classpath file in CVS at all if this is the case? Why not remove it from CVS and just make it local to each machine? I have a tendency to never check in any IDE files into CVS, becuase you never know what IDE people will use on a team, and the IDE files just polute the source tree for other developers using totally different setups (JBuilder, NetBeans, Emacs/JDE, whatever…)
Just my 2 cents…
@support-rkalla wrote:
I have a question though… why do you have the .classpath file in CVS at all if this is the case? Why not remove it from CVS and just make it local to each machine? I have a tendency to never check in any IDE files into CVS, becuase you never know what IDE people will use on a team, and the IDE files just polute the source tree for other developers using totally different setups (JBuilder, NetBeans, Emacs/JDE, whatever…)
Just my 2 cents…
Hi Riyad,
On the other hand, most projects have a somewhat uniform server tooling, which means that most (actually, or at our company at least, all) developers use the same IDE, only possibly a different version. In this case it is much more preferable to put .classpath and .project files under source control, so that whenever you introduce a new library dependency, it is automatically update in other developers’ machine at an update, leaving less chance for an error, or a wasted our trying to track down library problems.
Projects themselves are inaffected by their placement. For every other library dependency you can use User-defined Libraries.
Using these resources only (and not using absolute-path elements in the .classpath), you can put the .classpath and .project into source control, as Eclipse expects it anyway.
Regards,
Robert
Rob,
As usual, good points. I haven’t had the opportunity to work in a single-IDE environment before.Riyad,
I’d like to point out a problem that I am now having with absolute paths in a team environment. MyEclipse uses absolute paths in the xdoclet-build.xml file. If I don’t include this file in CVS, the other members of my team will not get my customizations to the XDoclet modules (like package substitution, etc.). Therefore, this “project” file cannot be omitted from the source repository.
My team members and I are currently in a transition from Eclipse 3.0M8 to Eclipse 3.0. Because of this, we have two installations of Eclipse and MyEclipse on our PCs. It is not possible to switch back and forth between the two without editing out xdoclet-build.xml files. This is a major problem because our source repository policy mandates strict locking. Therefore, only one developer at a time is (technically) allowed to edit a file.
I wish to echo the original poster’s assertion that some sort of variable reference is necessary to allow sharing of project resources.
Thanks.
– Jack Gould
Sherwin-Williams
Cleveland, OhioJack,
You are absolutely right about the paths in the XDoclet file, that is currently an open enhancement that I will add your comment to in our tracking system.Riyad,
Where I work we are in the middle of a big push to standardize on one IDE so that developers can easily move from project to project and find sharable project config files in each one and not have to either a) figure out how to set up the project in their ‘favorite’ IDE or b) switch IDEs to take advantage of the fact that someone’s already created a usable project for a specific IDE. In evaluating IDEs we are finding that project setup is a major differentiator between them and a major source of resistance to adoption. Exactly because of problems with project structure flexibility, many of our developers simply refuse to use *any* IDE, preferring instead to use a lightweight programmer’s editor and Ant to do everything. The project setup pain seems to outweigh any arguments about productivity benefits once you get over that hurdle. (Of course, IDE bloat is the other main issue for most of them.)
I am finding that Eclipse itself has some major problems in both project flexibility (ability to handle ‘non-standard’ project structures) and portability (ability for a project to work in any physical location on any workstation without modification). Since your product and it’s success are completely tied to the Eclipse platform, I would think that you would try to make every effort to influence the Eclipse JDT project to address these issues.
I did some more research on Eclipse regarding my original request (and following Rob’s pointer about user-defined libraries) and found the following:
1. User defined-libraries seem to be the only way, currently, to address my problem. However, I see a major issue with this solution and that is that it doesn’t let us take advantage of ME’s very useful ability to automatically add all WEB-INF/lib jars to the project’s build path. This means that if we add new libraries to a project, then every developer must also add new user-defined lib definitions. In our project’s 90% of our libraries are in WEB-INF/lib and I really don’t want to have to create/maintain user-defined libs for all of those.
2. Eclipse allows you to create class path variables for your libraries and their associated source files, but with the following restrictions that make this feature useless to me. a) class path variables can only refer to absolute paths, so it makes no sense to use them to refer to libs that are inside my project structure (e.g. WEB-INF/lib), and most important for me, b) class path variables for source files can only be associated with libraries that are themselves defined using class path variables – this means I can’t use cpv’s to associate source with project-relative non-cpv library definitions that ME sets up for me from WEB-INF/lib.
I’d be happy to advocate a solution for this on the Eclipse newsgroups, but as they are not a true support forum like this one, I’m not sure what the most effective approach is. Any advice would be appreciated.
Thanks,
-Kit1. User defined-libraries seem to be the only way, currently, to address my problem. However, I see a major issue with this solution and that is that it doesn’t let us take advantage of ME’s very useful ability to automatically add all WEB-INF/lib jars to the project’s build path. This means that if we add new libraries to a project, then every developer must also add new user-defined lib definitions. In our project’s 90% of our libraries are in WEB-INF/lib and I really don’t want to have to create/maintain user-defined libs for all of those.
If most of your libs are in the WEB-INF/lib dir, and MyEclipse automatically mounts them and these are under source control… why do you need to do anything related to these libs? It should be automatic… if you add a new lib, and someone does an Update from CVS and pulls down the new lib, MyEclipse will mount it, viola! I think I’m misunderstanding you here…
I’d be happy to advocate a solution for this on the Eclipse newsgroups, but as they are not a true support forum like this one, I’m not sure what the most effective approach is. Any advice would be appreciated.
The most effective approach is usually to start a conversation on the newsgroup describing your problem but alsso file a bug for it… this will make your comments visible to many users and help you refine the request or maybe find out that its already been filed. The developers seem relatively active on the forums so you might get lucky.
Since your product and it’s success are completely tied to the Eclipse platform, I would think that you would try to make every effort to influence the Eclipse JDT project to address these issues.
It really boils down to an issue of resources, for both our team and the Eclipse team. I will send this thread to the devs to see what they think about it as I don’t think I’m enough in the know to comment.
[quote]If most of your libs are in the WEB-INF/lib dir, and MyEclipse automatically mounts them and these are under source control… why do you need to do anything related to these libs? It should be automatic… if you add a new lib, and someone does an Update from CVS and pulls down the new lib, MyEclipse will mount it, viola! I think I’m misunderstanding you here…
The issue is not getting the libraries [b]themselves[/b] into the build path, it’s getting their source and/or javadoc files linked to them. As I mentioned in my original post, to save space in our jar/war/ear files, we only include the .class files in all our WEB-INF/lib jars – even if they didn’t come to us that way, though most do. This means that for debugging, we need to manually associate the source files for those jars and we don’t put the source files in the project module in cvs as they’re only needed by those who might want to actually run the app under the debugger and they would unecessarily bloat the project module. So, we have our WEB-INF/lib’s auto-mounted by ME (yay!) but their source files are [b]outside[/b] the project and (usually) in a [b]different[/b] physical location on each developer’s workstation. This means that each developer that wants to debug or have useful javadoc pop-ups in the editor has to manually link the source and/or javadoc files to the libraries using absolute paths for their workstation.
The main problem as I see it right now is that Eclipse won’t let me define class path variables for those WEB-INF/lib jars that are inside the project, and without [b]those[/b] being cpv’s, it won’t let me used cpv’s to associate the source/javadoc files to them.
Q: What did I do wrong with that last post such that the markups (
…
etc.) didn’t render properly? I used the buttons in the reply page to insert them. What happened?
@kitm wrote:
The main problem as I see it right now is that Eclipse won’t let me define class path variables for those WEB-INF/lib jars that are inside the project, and without those being cpv’s, it won’t let me used cpv’s to associate the source/javadoc files to them.
Riyad,
he is having the same problem as was mentioned in a previous thread about deploying or not deploying user libraries.
Essentially the same solution would solve his problems as well:
– user libraries can have source and javadoc paths associated to them independent of projects, therefore user library dependencies are usable for specifying machine independent dependencies (this is already implemented in Eclipse 3.0)
– referenced user libraries should be possible to be marked as to be deployed or not to be deployed in the deployment data of each project
That way, they don’t have to put any paths into the project-specific files, and they still have the ability to refer on libraries, and have their source and doc configured in Eclipse.
Regards,
Robert
