Dimiter,
Yes, this is one of the more annoying bugs we have. (We have a utility
to generate unique project names for our JUnit tests, so we've worked
around one of your issues that way.) Truth is, I know *when* it
happens, but I really have no idea *why* it happens. It only happens
when creating a resource with a given path (say
"MyProject/src/META-INF/persistence.xml"), deleting or closing the
project, and then attempting to recreate the resource with the same
path. *Something* isn't being cleaned up or disposed, but again, I
don't know what exactly. I've been experimenting with ArtifactEdits in
an alt stream, and I've seen a disappearance of most or all of these
issues, but again, I'm not sure why, and I'm not sure I understand the
code well enough (lack of documentation is a big problem here) to feel
good about introducing it into our maintenance stream. But that is
what I'm going to look into doing. This bug is big enough that even
some problems caused by (mis)use of ArtifactEdits are probable worth it.
Incidentally, this issue won't crop up when importing a brand new
project into a workspace. It only occurs when importing a project into
a workspace in which it has been deleted in the same session (i.e.
delete, then reimport.)
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
Dimitrov, Dimiter wrote:
Hello Paul,
The issue was
discovered simultaneously from our tester and a JUnit test. The tester
had closed the project because of huge set of projects in the workspace
and opens it after that on demand. The JUnit test is passing
successfully only once. If it is invoked second time in the one Eclipse
session it fails every next time. The
import is more probable case, if the application should be transfered
on another workstation.
Actually you are right, that these
use cases is not so popular,
but when project have to be closed (for any reason), after reopening
the only one way to repair it is restart of the Eclipse (and it works
only if the editors hadn’t been saved meantime). This bug is very
important for us, because it could lead to big discomfort for the
developer of bigger applications, in case of metadata corruption. Could
you suggest some way to load externally the metada from the scratch
(even restart of the plugin or of the model manager?)
Thank you for the attention,
Dimiter
Dimiter,
This is most likely related to this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=192477
We are definitely experiencing difficulties closing/reopening projects
(deleting/re-importing is effectively the same thing) and dealing with
the WTP/EMF resource interaction.
Can you give us any insight into the use case for closing/reopening of
projects? This is something that we're working on, but it may be
helpful to know why closing/reopening is something that you are
dependent upon.
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
Dimitrov, Dimiter wrote:
Hello,
I'm working with
DALI 1.0 from the Europa release and I’m in big trouble with the usage
of an persistence unit from my JPA project. It contains in the
following: Sometimes (most frequently after close/open of the project
or delete of project and import again), the persistence units of the
project doesn’t presented despite the fact that provider.xml is valid.
I had tried lots of approaches to rebuild the model, but
unsuccessfully: when I invoke IJpaPlatform.persistenceUnitSize() it
returns 0.
My appeal is could
you suggest me a way to reload the metadata information, described in
the descriptor file persistence.xml
Thank you in advance,
Dimiter
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
|
