[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Taking working copies in account when doing JavaModel operations
|
No, it is not possible. ICompilationUnit.getWorkingCopy() will throw a
JavaModelException if the compilation unit does not exist.
I guess what you would want is that it returns an empty working copy.
This sounds like you need a new API:
ICompilationUnit.getWorkingCopy(boolean ignoreExistence)
I'm not sure of the feasibility of such new API. Could you please enter a
feature request for this?
Jerome
Dirk_Baeumer@xxxxxx
m To: jdt-core-dev@xxxxxxxxxxx
Sent by: cc:
jdt-core-dev-admin@ Subject: Re: [jdt-core-dev] Taking working copies in account when doing JavaModel
eclipse.org operations
02/01/2002 01:52 PM
Please respond to
jdt-core-dev
What do mean with "of course, the new file in p2 would have to exist.."
When we move a CU from p1 to p2 and want
to analyze the impact of that move we don't want to save any files to disk.
So is it possible to create the new CU in
P2 without saving it to disk ?
Jerome_Lanneluc@oti.
com To: jdt-core-dev@xxxxxxxxxxx
Sent by: cc:
jdt-core-dev-admin@e Subject: Re: [jdt-core-dev] Taking
clipse.org working copies in account when doing JavaModel
operations
01.02.2002 13:11
Please respond to
jdt-core-dev
I guess I didn't answer your question... Sorry for the delay.
Yes, if you want to move a CU from package p1 to package p2 using working
copies, you can make sure the working copy in p1 is empty, and the working
copy in p2 contains the new contents. Of course, the new file in p2 would
have to exist as you cannot create a working copy on a nonexistent CU.
Jerome
Dirk_Baeumer@xxxxxx
m To:
jdt-core-dev@xxxxxxxxxxx
Sent by: cc:
jdt-core-dev-admin@ Subject: Re:
[jdt-core-dev] Taking working copies in account when doing JavaModel
eclipse.org operations
01/28/2002 12:47 PM
Please respond to
jdt-core-dev
Just to double ckeck. Passing an empty working copy also works if I move a
CU from package p1 to package p2.
Dirk
Jerome_Lanneluc@oti.
com To: jdt-core-dev@xxxxxxxxxxx
Sent by: cc:
jdt-core-dev-admin@e Subject: Re: [jdt-core-dev] Taking
clipse.org working copies in account when doing JavaModel
operations
28.01.2002 11:41
Please respond to
jdt-core-dev
Passing an empty working copy should do the trick.
Philippe_Mulet@oti.
com To:
jdt-core-dev@xxxxxxxxxxx
Sent by: cc:
jdt-core-dev-admin@ Subject: Re:
[jdt-core-dev] Taking working copies in account when doing JavaModel
eclipse.org operations
01/25/2002 05:52 PM
Please respond to
jdt-core-dev
Good point, we need to look on how to do this too.
Dirk_Baeumer@xxxxxx
m To:
jdt-core-dev@xxxxxxxxxxx
Sent by: cc:
Erich_Gamma@xxxxxxx
jdt-core-dev-admin@ Subject: Re:
[jdt-core-dev] Taking working copies in account when doing JavaModel
eclipse.org operations
01/23/2002 11:26 AM
Please respond to
jdt-core-dev
Yes, but there is one option missing needed for refactoring. We need the
ability to mark a CU as deleted although it still exists on the file
system. Is this something the new infrastructure will provide as well.
Dirk
Philippe_Mulet@xxxxxx
m To: jdt-core-dev@xxxxxxxxxxx
Sent by: cc: Erich_Gamma@xxxxxxx
jdt-core-dev-admin@ec Subject: [jdt-core-dev] Taking
lipse.org working copies in account when doing JavaModel
operations
22.01.2002 15:05
Please respond to
jdt-core-dev
Working copies are not connected from the JavaModel, they are created on
demand to perform local operations which can then be commited onto the
JavaModel.
They can see other pieces of the JavaModel through name resolution, but
they cannot see any other working copy, since there is no mechanism in the
JavaModel to cause working copies to shadow their original compilation
unit. This is annoying when performing operations which involve some name
resolution, since the referenced working copies are being ignored (until
they are saved).
We are investigating ways to have multiple working copies to be considered
at once by JavaModel operations. We currently are leaning towards a
solution where some operations could take in argument a set of working
copies to be considered (taking precedence over the normal Java model). We
can imagine having the search engine and the type hierarchy resolver be
equipped with such APIs; unsure about code completion and code selection
(maybe).
Given we are not planning on indexing working copies, we would force these
extra working copies to be passed to the name resolution engine (and likely
resolved even if unnecessary), thus they would de facto take precedence
over the JavaModel regular lookup mechanism (SearchableEnvironment).
As a consequence, passing extra working copies could penalize affected
operations, does this sound acceptable ?
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
