Community
Participate
Working Groups
Build Identifier: 20110615-0604 When i try to open a diagram on a JPA project, i get an unexpected error saying "'Creating diagram for: jpa-test...' has encountered a problem. Could not write file: /jpa-test/diagrams/jpa-test.xml." I think that it's because, when creating the diagram, Eclipse always puts the name of the project before the folder specified in the JPA Diagram Editor properties, i.e for my project named "jpa-test", he always try to put the XML file in the folder "file:/jpa-test/diagrams". Unfortunately, there is no such a folder on my file system. I can solve this problem by creating this folder on the file system and giving writing access to the user running Eclipse, however this is a dirty solution. I think it that it would be better to put the XML file in the folder "file:/{project_location}/diagrams" instead of "file:/project_name/diagrams". Reproducible: Always Steps to Reproduce: 1. Create a JPA project on linux 2. Right-click on project 3. Select "JPA Tools" > "Open Diagram"
I have the same bug after install Eclipse Indigo 3.7 (before I used beta version of eclipse 3.7 with JPA Diagram Editor beta and all worked fine).
We're working on it ...
Still having the same issue on Indigo, Ubuntu 11.04 64bit
I have confirmed this behaviour on Indigo Mac OSX Lion
Created attachment 203247 [details] Fix for both HEAD and R3_0_maintenance branches
Created attachment 203248 [details] patch for both HEAD and R3_0_maintenance branches
Created attachment 203262 [details] Fix for both HEAD and R3_0_maintenance branches - v3
Reviewed and tested on OSX Lion. The patch and the tests work.
This is an ugly bug - the user can't even open an empty diagram. There are 5 votes for this bug. No workaround. The fix was tested manually and a new JUnit test is added. The manual and JUnit tests have been performed on Windows, Linux and OS XLion. The problem is a redundant code in ModelIntegrationUtil.copyExistingXMIContentAndDeleteFile(...). On OS different than Windows IFileStore.mkdir() expects an absolute path on the filesystem and it gets a path relative to the workspace root. However, this code is obsolete and redundant and the patch removes it - just a few lines of code. The fix was reviewed by Dimitar Giormov The risk is low.
This looks like a major issue. I assume this was not caught earlier because it occurs only on a non-win OS.
(In reply to comment #10) > This looks like a major issue. I assume this was not caught earlier because it > occurs only on a non-win OS. Correct!
Can you confirm ... is this a regression from the Indigo release? Since the "final bits" are due by 5 PM Eastern, this will take a special exception to get into the common SR1 repo. Another option is have a patch "ready to go" for once SR1 is released next week. (as an update from webtools specific site).
I have checked in this patch, but only released the org.eclipse.jpt.jpadiagrameditor.ui plugin. Did not release the test plug-in because I made a change to the new required bundle to make it a version range. I think it is safer to add the new test at a later date. Stefan, could you smoke test the new build when it's completed?
> Stefan, could you smoke test the new build when it's completed? Yes, I will do it.
(In reply to comment #14) > > Stefan, could you smoke test the new build when it's completed? > Yes, I will do it. Tested on Linux and Windows
(In reply to comment #12) > Can you confirm ... is this a regression from the Indigo release? Appears that the bug exists in the Indigo release.
(In reply to comment #16) > (In reply to comment #12) > > Can you confirm ... is this a regression from the Indigo release? > > Appears that the bug exists in the Indigo release. Ok, thanks. In that case, I will just say, to the rest of the PMC ... I think we sort of jumped the gun approving this bug/fix for a release-train-schedule-breaking exception to Indigo SR1 ... but, since Carl has already worked hard, at PMCs request, to push this through its stages, it would now do more harm to back it out. So, I will not object ... just documenting the communication problem. And, I'm glad its fixed! Thanks for fixing and thanks to others for reporting. It is a bad bug and good to have it done.
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #12) > > > Can you confirm ... is this a regression from the Indigo release? > > > > Appears that the bug exists in the Indigo release. > Ok, thanks. In that case, I will just say, to the rest of the PMC ... I think > we sort of jumped the gun approving this bug/fix for a > release-train-schedule-breaking exception to Indigo SR1 ... but, since Carl has > already worked hard, at PMCs request, to push this through its stages, it would > now do more harm to back it out. So, I will not object ... just documenting the > communication problem. > And, I'm glad its fixed! Thanks for fixing and thanks to others for reporting. > It is a bad bug and good to have it done. Just one thing: We should've fix it earlier, but we didn't because of lack of resources. Sorry about that. :(
Patch submitted and released in HEAD branch.
Stefan, Could you change the new org.eclipse.core.filesystem required bundle to have a version range? I changed this in maintenance, but did not release the test plug-in.
(In reply to comment #20) > Stefan, > Could you change the new org.eclipse.core.filesystem required bundle to have a > version range? Done in HEAD ...
