Community
Participate
Working Groups
As we move to 2.1 there will be people using both 2.0 and 2.1 on the same projects. In 2.1 there is some new metadata in the .classpath files. Since these files are shared, we should investigate and document the behaviour people can expect. For example assume user 2.1 gets a project and updates something captured in new .classpath metadata. She then releases this to the shared repo. User 2.0 comes along and checks the project out. What happens? Does it work and the extra data is ignored? If not, what is the failure mode? Are there any workarounds? Assuming it is ok or can be worked around, 2.0 then updates something in the project that rewrites the .classpath file. Is the 2.1 data preserved? They then release the changes. What happens to 2.1 when she catches up to the changes? What happens to another 2.1 user who then loads the project for the first time? See also bug 29576
2.0 user shouldn't get busted. It will simply ignore extra data (if any). Note that the extra data will only be inserted in .classpath if new features are in use: exclusion filters or multiple output folder. If the classpath is touched locally by the 2.0 user, he will get an outgoing change at next synchronization. 2.1 features won't be preserved in .classpath, and thus he should refrain from releasing it since it would discard some information contained in the .classpath file. Cases like nested source folders (now supported in 2.1) will be not supported in 2.0, and issue a classpath problem causing the .classpath file to not be read (left to whatever it was before).
Good info. Please note these scenarios and workarounds and any others you can think of in your readmes for the 2.1 release.
Can you comment on classpath container support in 2.0? For example, in 2.1 the default behaviour seems to be to use classpath containers for the JRE libs in java projects. What will happen then if someone uses 2.0 to open a project created in 2.1? I assume that the classpath entry identifying the contatiner (type "con") will be ignored and the result is that the project most likely will not compile since all the system libs are missing. Is this correct? Note: we are just trying to understand the behaviour and how to work with what we have.
Containers did already exist in 2.0, so they shouldn't cause any grief at all.
- what happens when a 2.1 user loads some 2.0 metadata (this *must* work as we do guarantee backward compatibility) works no problem. 2.1 classpath is a superset of 2.0 classpath. - what happens when a 2.0 user loads some 2.1 metadata? should work. 2.0 will ignore extra attributes it doesn't recognize (source folder exclusion patterns, source folder custom output folder). In case 2.1 user is nesting source folders (tolerated if excluding inner from outer), a 2.0 user will get a classpath problem. - is it safely ignored? yes - are the fields the same but the meanings different? no - what is written when the 2.0 user rewrites the metadata - is the 2.1 data preserved? no, could lose some information (extra attributes). - is the 2.1 data left intact (e.g., 2.0 and 2.1 are in different files?) no - when the 2.1 user updates after 2.0 has written, what happens? - if the 2.1 data is lost, is that handled gracefully? yes, some classpath problems may result. But if 2.0 user did release a valid classpath, this should work fine for a 2.1 user. The bad scenario is a case where a 2.0 user got the 2.1 classpath, got classpath problems (since new attributes where ignored), then decided to release back its classpath even though it had errors. - if it is still there, does it match the 2.0 data?
Doc issue, won't do any xml tree merging, nor will we introduce a signature since we won't change its format into a non-readable way.
We will however add some new settings to enable/disable features which would affect .classpath compatibility with 2.0 clients: - enable exclusion patterns - enable multiple output folders - persist inferred source attachment root path (since UI no longer sets it, but 2.0 clients will need the info somehow).
Added first 2 settings, 2.0 clients can set the missing rootpath. Closing
Verified.
No persistence of inferred source root paths got added, however options control exclusion filters and custom output folders. Also note that a 2.0 client may hit bug 32690, when using nested source folders in 2.1 (a 2.0 client wouldn't get an classpath error after checking out, only when opening the buildpath preferences). A fix for 32690 has been backported in 2.0.x stream and is posted as a patch on JDT/Core webpage (2.0.x area): http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r2.0/main.html#updates
