Community
Participate
Working Groups
Created attachment 108009 [details] Proposed Patch It would be nice to expose public constants for the .classpath and .settings/org.eclipse.jdt.core.prefs files. Such constants exist in the internal JavaProject class, so downstream plugins have to choose between referencing internal api or duplicating constants. I have seen numerous situations where these paths/names get duplicated in downstream plugins. This happens primarily in cases where a batched IWorkspace.validateEdit() request needs to be made prior to starting an operation. Something similar to what platform has done with IProjectDescription.DESCRIPTION_FILE_NAME... Attaching a proposed patch.
I agree about ".classpath" (but the Javadoc has to tell explicitly that the format of the file is not specified and that the file is not to be modified). I wouldn't make the .prefs file API, since this is an implementation detail of the org.eclipse.equinox.preferences bundle, so any such API should go there (see org.eclipse.core.internal.preferences.EclipsePreferences#computeLocation(..)).
(In reply to comment #1) > I wouldn't make the .prefs file API, since this is an implementation detail of > the org.eclipse.equinox.preferences bundle, so any such API should go there > (see > org.eclipse.core.internal.preferences.EclipsePreferences#computeLocation(..)). Thanks Markus. I agree. JDT/Core should not expose an API constant that is related to the preference bundle.
I would propose: /** * Name of the file containing the project's classpath. * * <p>The format of this file is unspecified and it is not meant to be modified. * Its contents is modified by using the <code>setRawClasspath</code> methods.</p> * * @see #setRawClasspath(IClasspathEntry[], IProgressMonitor) * @see #setRawClasspath(IClasspathEntry[], boolean, IProgressMonitor) * @see #setRawClasspath(IClasspathEntry[], IPath, IProgressMonitor) * @see #setRawClasspath(IClasspathEntry[], IClasspathEntry[], IPath, IProgressMonitor) * @see #setRawClasspath(IClasspathEntry[], IPath, boolean, IProgressMonitor) * @since 3.7 */ String CLASSPATH_FILE_PATH = ".classpath"; //$NON-NLS-1$
If you just say "Name of the file", then it's not clear where the file is located. "Path to the file" would at least suggest that it's a project-relative path. But I would call the constant CLASSPATH_FILE_NAME and add "The file is a child of the project folder." as second sentence of the Javadoc.
(In reply to comment #4) > But I would call the constant CLASSPATH_FILE_NAME and add "The file is a child > of the project folder." as second sentence of the Javadoc. Ok, sounds good. I'll adjust the patch.
Created attachment 188329 [details] Proposed fix
The attached patch addresses half the stated requirement. Perhaps instead of committing to API for specific files, we can have the following method: IJavaProject.getMetadataFiles() -> List<IFile> I think this would address Markus's concerns regarding not creating API around implementation details of preferences API while also allowing JDT API users to reliably validateEdit() _all_ classes that might need to be written when using JDT API.
(In reply to comment #7) > IJavaProject.getMetadataFiles() -> List<IFile> That would just be a guess, which can quite as well be implemented in client code. And it's too coarse-grained to be useful, since you still don't know which API modifies which files. E.g. when you copy a compilation unit that uses a non-default encoding, then this will modify org.eclipse.core.resources.prefs as well (or maybe the *.derived.* variant). The best guess you can make is to include the whole .settings folder.
Don't you think that this guess would be better implemented and maintained by JDT rather than by multitude of clients? Having clients "guess" the entire .settings directory is both not sufficient to cover all JDT metadata files and too broad, so users aren't going to stand for that. The case of file encoding metadata can be handled separately as if you go to modify a compilation unit you will also be modifying the source file in question. You would need something like ICompilationUnit.getFiles(). Note that I am not requesting that API. The cases that I've seen center primarily around programmatic changes to classpath and compiler level settings.
Let be clear about what we can do here. It makes sense to me to expose the path to the .classpath file. I don't like the idea of exposing the preferences files for a java project. This doesn't belong to the java project. This is handled by the preference bundles, not JDT.
(In reply to comment #9) > Don't you think that this guess would be better implemented and maintained by > JDT rather than by multitude of clients? Having clients "guess" the entire > .settings directory is both not sufficient to cover all JDT metadata files and > too broad, so users aren't going to stand for that. JDT metadata is the .classpath file. Files under .settings should be seen as metadata files from the preference bundle. I plan to expose the .classpath constant. Maybe we should state that the value of the constant is unspecified. It is only a path relative to the project. So it can be used to retrieve the .classpath file and give us the freedom to change the layout in the future.
Markus, what do you think about releasing the current patch with the modification described in comment 11? I found many usages of ".classpath" inside JDT code and this relies on an unspecified behavior. So it is worth specifying this once for all.
Created attachment 189670 [details] Proposed fix It could be something like this.
> + * <p>The value of the path is unspecified. That doesn't work, since this is a compile-time constant that will be inlined in referencing class files. But since you won't be able to change this path anyway (for compatibility with old projects that are stored in source code repositories), I think you should just leave out this sentence. If the path ever changes in the future, you'd have to deprecate this constant and add a new one for the new file. The rest of the patch looks good.
Ok, I'll add back the previous sentence: <p>The file is a child of the project folder.</p> Will be released shortly.
Created attachment 189717 [details] Proposed fix Patch to be released.
Released for 3.7M6.
Verified for 3.7M6 by code inspection.
