Community
Participate
Working Groups
To reduce conflicts between unrelated content types that share the same file name/spec, associating content types to natures would help. For a given project, content types associated to configured natures would have higher priority. For instance, the Java nature would be associated with the Java source file, Java properties, JAR manifests, and others that may become available.
*** Bug 72839 has been marked as a duplicate of this bug. ***
Is there any plan to move on this for 3.1?
Yes. I haven't done much work in the content type area after 3.0.1, but it sure is something we plan to do. This and allowing users to interfere on content type resolution (see bug 68270, and also bug 57908).
May I make a general comment on this bug/proposal ... if I understand it correctly, you're suggesting a resource's content type can change depending on the nature(s) of the project. This seems to stray from the whole concept of "content type" which should be dependent only on the resources content. I suspect when clients desire the contentType to change, what they really want is something associated with the content type to change. Since natures themselves can change, seems kind of dangerous to change contentType ... a file created and encoded in one project, for example, might not be readable if the project's nature changed (and the encoding/decoding rules changed)? Sorry if I'm reading to much into the little that's written here, but seemed I'd better voice my concerns soon since targeted for M5! I'm not sure what the exact use-case motivating this change in API behavior is. Thanks.
All we want to do is to give the user the right answer, asking the user to intervene as a last resort. The rationale for this PR here is that the probability of clashing content type definitions in an Eclipse product is considerable, but tend to be reduced in the context of a project (and of the universe of its associated natures). So unless there are conflicts, content type determination would work the same accross projects. One thing that I would like to highlight is that content types in Eclipse are not solely dependant on contents, but on the file name as well. In fact, for many file formats based on plain text, content analysis does not help on content type determination at all. Also, if a file is copied from a project to another, it is reasonable to expect that both projects share the corresponding nature. Finally, although this is scheduled to be resolved by M5, that does not mean it is going to be implemented. If the feedback we get from the community gives enough reasons why we should not do this, we would probably not do it.
Thanks for the explaination. And, now that I've "complained" about this possible enhancement, I'll give a vote for it :) ... actually, I have run across a use case that might fit this case. In JSP 2.0 Spec, you can, in web.xml file, have some "say" in what should be considered a JSP file, a JSP file in XML Syntax, etc., and .... since web.xml's can change from one Eclipse project to another, there might a better programming model than simply everyone figuring out details themselves. (That is, if handled by changing contentType definition, then all else follows naturally without additional client programming). While this requires more than simple association to nature, it was related to the idea of content type definition changing from one project to another, so thought I'd document it, if helpful. I *am* however still concerned about giving end-users a little too much rope to hurt themselves with ... my only concern has to do with encoding/charset rules changing, simply due to copying from one project to another. Perhaps a warning, at least to log, if not dialog, that a resource's encoding was "changing from xxx to yyy due to move/copy operation" would prevent user errors that would not otherwise be detectable until some time later, when actually used (by which point I'm sure would appear to be an editor bug :) Thanks.
Could not make this happen for M5. Upgrading target milestone. Re: comment 6 - David, this (files having different encodings) is already possible in Eclipse since we added project/folder default charset settings in 3.0. See also bug 85765 for user-driven (project specific) content type resolution.
See also bug 37668 comment 20 for a use case (although the plan here is to use natures as a hint for choosing the best content type, and not to rule out potential matches that are not associated to any natures).
It was suggested (in Bugzilla 78653) that I annotate this defect if associating content types to natures did not handle my particular issue, which is the fact that file inspection alone does not work in Eclipse. My objection with relying on hints as the only unambiguous mechanism follows. Using natures as hints is fine when you are running in the GUI and are opening a resource on which to operate. But our application (Rational Modeling Platform Compare Support for EMF -- how's that for a mouthful :-) also operates on artifacts that are fed in from ClearCase as temp files with no useful informaiton in the file spec (e.g. file name TMP1234) and no user intervention whatsoever (e.g. automatically launched workbench to run a silent merge.) In other words, I think that there are perfectly valid scenarios that are shipping in major applications today that could really use an accurate and unambiguous typing mechanism that does not assume that hinting will always be available.
(In reply to comment #7) > Could not make this happen for M5. Upgrading target milestone. > Re: comment 6 - David, this (files having different encodings) is already > possible in Eclipse since we added project/folder default charset settings in 3.0. > See also bug 85765 for user-driven (project specific) content type resolution. For the CDT case not having content-type project specific, is one of the major barrier from not embrassing the content-type framework. Any time/date for this?
I have most of it implemented. I expect to see it released next week, maybe after the integration build. Alain, could you elaborate on the use cases for CDT, describing which problems this would solve? Thanks.
(In reply to comment #11) > I have most of it implemented. I expect to see it released next week, maybe > after the integration build. Alain, could you elaborate on the use cases for > CDT, describing which problems this would solve? Thanks. Sorry, I was highjacking the wrong thread, comment posted in PR https://bugs.eclipse.org/bugs/show_bug.cgi?id=85765
Copied from bug 85675 comment 3, by Alain Magloire "Below is an excerpt from CDT mailing list with Leo: > Will this enhancement be done in Eclipse 3.1? Will CDT drop the > per-project file extension associations if it is not? I would not like > to see the functionality dropped. Developers can find themselves > working with someone else's code where "strange" file extensions are > used, but not necessarily want these extensions to be valid in the > projects that they create. > > Regards, > Leo a scenario *.tcc is use by cygwin to say indicate a C++ template file and should be parse by the C++ source parser. The content-type per nature solves the problem for the ISV, so when they(ISV) ship with the CDT, there wizards will add a nature to the project so new content-types will be available to there specific projects. But for the open-source users, working on say Linux, needing to add an extension for QT or for its own libs(*.t for template), it is not possible without affecting things globally. I think, with the coming of content-type/natures, I can argue with with the CDT folks on the need to totally embrace the IContentTypeManager framework(so we can drop the old Resolver Model), but having project specific will probably help."
Alain, as said in comment 8, content type-nature associations are intended as a mean of getting a hint on what content type is preferred, when multiple content types apply, not to rule out those that are not associated.
The question that I have relates to filename/extension association to a content type, not content type determination from file "contents", and not content types per nature. CDT currently supports defining the set of filenames/extensions that define a C/C++ source file *per CDT project*. The current platform content type manager appears to allow filename/extensions to be added *per user* - I assume that means per workspace. I don't want CDT to lose the per project functionality. I think that developers will get projects that they need to use from different places that could use custom file extension mappings that are not the ones that the user would necessarily use. The queston is, can the content manager be extended to allow filename/extension associations per project in Eclipse 3.1?
To understand what you were asking for (and what Alain mentioned in comment 13, what I now understand), I had a look at CDT. That should not be too hard to support. Opened bug 87447 to address it.
Provided that IFile.getContentDescriptor().getContentType() returns the most appropriate content type for the file based on it's project, then the work I've put in for 37668 should automatically use it. Is this what you had envisioned Rafael?
Yes, IFile#getContentDescription() will follow project-specific policies, if any. IContentTypeManager.getDescriptionFor(InputStream,String) will not.
Perfect.
(Non-functional) API is in place for M6. Implementation will happen during the M7 cycle.
Created attachment 19913 [details] patch for org.eclipse.core.resources
Created attachment 19915 [details] patch for org.eclipse.core.tests.resources
Patches reviewed by JohnA, and released to HEAD with improvements/corrections.
