Hi Karen, thanks I will take a look - please open a new bugzilla, your referenced bug seems unrelated to the recent changes.
- Chuck Rational Java EE Tooling Team Lead IBM Software Lab - Research Triangle Park, NC Email: [EMAIL PROTECTED] Phone: 919-254-1848 (T/L: 444) Karen Moore <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/31/2007 03:55 PM Please respond to "General discussion of project-wide or architectural issues." <[email protected]> To "General discussion of project-wide or architectural issues." <[email protected]> cc Subject Re: [wtp-dev] Getting an EMF resource from an ArtifactEditModel, given an IFile and not a deploy location Chuck, It appears these changes (I'm assuming they are the changes in EMF2DOMSSERenderer) have broken some use cases for us. If I have an orm.xml/persistence.xml file open when I open my workspace, I am unable to edit it through the Dali JPA views. I've debugged this some and come down to the code in EMF2DOMSSERenderer.initializeXMLModel(IFIled, boolean) doing a IModelManager.copyModelForEdit() on line 328. Then in AbstractModelLoader.createModel(IStructuredModel) a new JobSafeStructuredDocument is created on line 141. The problem is that this new document does not have an fExecutionDelegate set on it like the old one did (since it already had it set because it is open in the editor). So, when I later execute JobSafeStrucuredDocument.setText() it goes through the code for the executionDelegate being null and the editor is not updated with the changes. That's all the info I have uncovered, should I open a bug for this problem? Also, Dali bug 187295 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=187295> was something we had already found and sounds suspiciously similar. The latest code seems to have created more use cases that don't work. thanks, Karen Chuck Bridgham wrote: > > Paul, > > I beleive I fixed your issue with my code drop last night, can you try > again with your original uri? the normailization routine had some > problems. > > - Chuck > > Rational Java EE Tooling Team Lead > IBM Software Lab - Research Triangle Park, NC > Email: [EMAIL PROTECTED] > Phone: 919-254-1848 (T/L: 444) > > > > *Paul Fullbright <[EMAIL PROTECTED]>* > Sent by: [EMAIL PROTECTED] > > 08/29/2007 06:38 PM > Please respond to > "General discussion of project-wide or architectural issues." > <[email protected]> > > > > To > "General discussion of project-wide or architectural issues." > <[email protected]> > cc > > Subject > Re: [wtp-dev] Getting an EMF resource from an ArtifactEditModel, > given an IFile and not a deploy location > > > > > > > > > > Ack, sorry, was wrong there. It only uses that source URI for > comparison purposes (normalization.) > Paul Fullbright > Oracle Corp. > Eclipse Dali/Java Persistence Tools Development > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > Paul Fullbright wrote: > > Are EMF resources referenced only by their *deployment* URI's? I > seem to recall seeing that they were. If so, is there any suggestion > for having more than one resource with the same deploy path, but > different source paths? Or is this pretty much just completely > disallowed? > Actually, on further review, EMF resources are referenced (eventually, > in the ResourceSet) by their file location > ("platform:/resource/ProjectName/src/META-INF/persistence.xml"), not > their deployment location. If there were a way to look up an EMF > resource through the edit model using this sort of URI, that's all > that we would need. > > Paul Fullbright > Oracle Corp. > Eclipse Dali/Java Persistence Tools Development > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > Paul Fullbright wrote: > Chuck, > Because you are using the ArtifactEditModel.getResource api, we use > our own internal "module:" protocol when constructing the uri. > The resourceset has a URIConverter that knows how to normalize this > uri using the projects component model. The projects "root folder" > is used to determine the offset, and I'm guessing this project uses > the "src" folder. Have you tried using the uri > "META-INF/persistence.xml"? > If we know what exact file we're looking for, then yes we can do that. > For example, when we're validating, we *know* we're looking for > "META-INF/persistence.xml". No problem. API works fine. And yes, in > the case of a jst.utility project, I believe the root folder is always > "src". Of course, we work with a number of module facets, so it's > only "src" in this specific case. > > Our problem is that we can have multiple files, and they really could > be named anything or in just about any source or web content folder, > if the user so wishes. We build up our inter-resource (project-wide) > model by scanning through the workspace and picking up all the files > that are of interest to the JPA platform so that we can respond to > file changes, renames, etc. And we initialize the EMF models for > those files at that first scan, at which point we only have the file > location. We could *assume* certain things about the file's location > and what folder it's in, but I don't feel very comfortable about doing > that. > > So the ability to access the resource given only the file location is > pretty important. > > Most of our uri's are static, so we don't need to calculate the offset > into the "deployed" path. But if you have an IFile instance of your > resource you can use: > > IVirtualComponent component = ComponentCore./createComponent/(project); > List folderList = > Arrays./asList/(component.getRootFolder().getUnderlyingFolders()); // > All the folders that contribute to the root deployment path > IPath path = WorkbenchResourceHelperBase./getPathFromContainers/(list, > anIFile.getFullPath()); // Will find the first match(folder) that > contains your IFile > I will try this out. Thanks. > > Are EMF resources referenced only by their *deployment* URI's? I seem > to recall seeing that they were. If so, is there any suggestion for > having more than one resource with the same deploy path, but different > source paths? Or is this pretty much just completely disallowed? > > Paul Fullbright > Oracle Corp. > Eclipse Dali/Java Persistence Tools Development > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > Chuck Bridgham wrote: > Paul - First I want to apologize for taking so long to respond... I'm > working on addressing these questions more regulary > > There may be an issue here, but I first want to understand your > scenario... > > Because you are using the ArtifactEditModel.getResource api, we use > our own internal "module:" protocol when constructing the uri. > The resourceset has a URIConverter that knows how to normalize this > uri using the projects component model. The projects "root folder" > is used to determine the offset, and I'm guessing this project uses > the "src" folder. Have you tried using the uri > "META-INF/persistence.xml"? > > Most of our uri's are static, so we don't need to calculate the offset > into the "deployed" path. But if you have an IFile instance of your > resource you can use: > > IVirtualComponent component = ComponentCore./createComponent/(project); > List folderList = > Arrays./asList/(component.getRootFolder().getUnderlyingFolders()); // > All the folders that contribute to the root deployment path > IPath path = WorkbenchResourceHelperBase./getPathFromContainers/(list, > anIFile.getFullPath()); // Will find the first match(folder) that > contains your IFile > > Hope this helps... Chuck > > Rational Java EE Tooling Team Lead > IBM Software Lab - Research Triangle Park, NC > Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > Phone: 919-254-1848 (T/L: 444) > > > *Paul Fullbright **_<[EMAIL PROTECTED]>_* > <mailto:[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > 08/27/2007 03:37 PM > Please respond to > "General discussion of project-wide or architectural issues." > _<[email protected]>_ <mailto:[email protected]> > > > To > "General discussion of project-wide or architectural issues." > _<[email protected]>_ <mailto:[email protected]> > cc > > Subject > [wtp-dev] Getting an EMF resource from an ArtifactEditModel, given an > IFile and not a deploy location > > > > > > > > > > > > I'm trying to load an EMF resource from a project's (a jst.utility > project in this case, but this should work for any jst.* project) edit > model. I have the actual file, therefore also its full path or project > relative path, which in this case is "src/META-INF/persistence.xml". > > When I call: > artifactEditModel.getResource(fileURI) > (where fileURI is the URI for the project relative path above, > "src/META-INF/persistence.xml") > the edit model normalizes the path to > "src/src/META-INF/persistence.xml", assuming that what I've given it is > the *deployment* path for the resource. It assumes, that since it can't > find the virtual file for "src/META-INF/persistence.xml", that it > doesn't exist, but that if it did exist, it would be at the same > relative location in the first source folder for the project. This > seems wrong, because I'd expect that it would first see if there's an > *actual* resource at the given location before trying to make such an > assumption, but maybe there's a reason for doing this that I don't > understand. So the end result is that the edit model tries to give me a > resource for the project relative location > "src/src/META-INF/persistence.xml" (which doesn't exist) instead of the > project relative location "src/META-INF/persistence.xml" (which does > exist). > > Is there a way to either: > - easily find the deployment path for a source path? (If I give the > actual deployment path for the file "META-INF/persistence.xml", then the > normalized path calculated will be correct.) > or > - better specify the URI of my file resource so that the edit model > can find my EMF resource? > > Thanks, > > Paul Fullbright > Oracle Corp. > Eclipse Dali/Java Persistence Tools Development_ > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > _______________________________________________ > wtp-dev mailing list_ > [EMAIL PROTECTED] <mailto:[email protected]>_ > __https://dev.eclipse.org/mailman/listinfo/wtp-dev_ > > ------------------------------------------------------------------------ > > _______________________________________________ > wtp-dev mailing list > [EMAIL PROTECTED] <mailto:[email protected]> > _https://dev.eclipse.org/mailman/listinfo/wtp-dev_ > > ------------------------------------------------------------------------ > > _______________________________________________ > wtp-dev mailing list > [EMAIL PROTECTED] <mailto:[email protected]> > _https://dev.eclipse.org/mailman/listinfo/wtp-dev_ > > > ------------------------------------------------------------------------ > > _______________________________________________ > wtp-dev mailing list > [EMAIL PROTECTED] <mailto:[email protected]> > _https://dev.eclipse.org/mailman/listinfo/wtp-dev_ > _______________________________________________ > wtp-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/wtp-dev > >------------------------------------------------------------------------ > >_______________________________________________ >wtp-dev mailing list >[email protected] >https://dev.eclipse.org/mailman/listinfo/wtp-dev > > _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
