No, I don't see it as a primary user scenario in anything other than an
error case. And you're correct that it would have to be caught in
validation (I also see us giving an warning in our editor views in this
case.) The real problem I see is that, when using the deploy path to
load the EMF resource, you don't really *know* you're getting a
resource for another file. The URI for the resource you receive is the
same as the one you've submitted, since they're both deployment paths
(and they have identical deployment paths.) I haven't found a good way
to determine that the resource I'm getting back is for a different
file. Have any thoughts on that?
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
Chuck Bridgham wrote:
Hi Paul,
The short answer is we don't support
this scenario well.... If files with identical names use the same
deploy
path, we pick one of the two (usually the first defined in the
component
list).
Do you really see this as a primary
user scenario? I completely understand multiple src folders
that are aggregated at publish time, but not copies of the same file in
seperate folders.
You would need a seperate component
mapping for that individual file to make it "persistence_1.xml".
What's missing here is a good
validator
that would catch these cases, and provide quickfixes to rename the
source
or target.
Thoughts? - Chuck
Rational Java EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
Chuck,
Both the suggestion you originally provided and the fix in the code
drop
work very well for the case that there is one source folder. I'm
able to calculate the deploy path for the file resource (previous
suggestion)
or find the correct resource even if I only use the project relative
source
path (fix from latest code). So, much thanks!
But this brings me to the issue of multiple source folders. We use
the EMF model of the resource to aid in its editing. We know how
users can be (if only we could eliminate users, development would be so
much simpler), and I'm pretty sure they'd want to edit files even if
they're
not playing quite so nice with the one-source-folder paradigm, so we at
least have to consider the situation that they've set up multiple
source
folders.
If I use deploy path lookup, and I happen to have this setup:
src
|-META-INF
|-persistence.xml
src2
|-META-INF
|-persistence.xml
if I attempt to load the EMF resource for the second file, I'll
actually
get the EMF resource for the first file. Not what you'd want if you're
editing the second one. Note that you can't *tell* that the EMF
resource
you're getting for the second one is actually the EMF resource from the
first one (or at least I don't know how to tell.) Also note that
if there is *only* the second file, everything works great.
If I use relative source path lookup for the above example, the EMF
resource
works great for the first file, but the normalized URI for the second
one
is now ".../src/src2/META-INF/persistence.xml" and I get a
FileNotFoundException
attempting to load the contents of my EMF resource. This is also
the case if *only* the second file exists.
So. What should our story be for multiple source folders? Is
this something that can be addressed in the WTP EMF code?
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
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: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
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
paul.fullbright@xxxxxxxxxx
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
paul.fullbright@xxxxxxxxxx
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
paul.fullbright@xxxxxxxxxx
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: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
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
paul.fullbright@xxxxxxxxxx
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
|
