Since apparently we are unable to affect the internal DLTK model of our
source modules, we attempt to build and refine our own models. Somehow we
want the ability to distinguish between clean compilation units (not open as
editor input) and potentially dirty working copies (open in an editor
window). The model of a working copy could refer to something defined in a
model of a compilation unit, but not vice-versa. Thus, we believe we need a
way to distinguish between those two sources of input.

I've seen that the interface ISourceModule has the method isWorkingCopy.
Unfortunately, the parser interface methods that we can easily override do
not refer to that interface:

1) ISourceElementParser.parseSourceModule: (this is the high level interface
when I also do semantic checks per module)
public void parseSourceModule(char[] contents, ISourceModuleInfo astCache,
char[] filename) {

I'd still like to know how to distinguish between clean compilation units
(parsed and/or checked as part of a build) and potentially dirty working
copies (invoked from an editor).

Thanks,
Chuck

"Chuck Doucette" <cdoucette@vaultus.com> wrote in message
news:g4u8ni$803$1@build.eclipse.org...
> Since apparently we are unable to affect the internal DLTK model of our
> source modules, we attempt to build and refine our own models. Somehow we
> want the ability to distinguish between clean compilation units (not open
> as editor input) and potentially dirty working copies (open in an editor
> window). The model of a working copy could refer to something defined in a
> model of a compilation unit, but not vice-versa. Thus, we believe we need
> a way to distinguish between those two sources of input.
>
> I've seen that the interface ISourceModule has the method isWorkingCopy.
> Unfortunately, the parser interface methods that we can easily override do
> not refer to that interface:
>
> 1) ISourceElementParser.parseSourceModule: (this is the high level
> interface when I also do semantic checks per module)
> public void parseSourceModule(char[] contents, ISourceModuleInfo astCache,
> char[] filename) {
>
> 2) ISourceParser.parse: (this is the low level interface where I simply
> create the AST tree and populate our corresponding model of declarations)
> ModuleDeclaration parse(char[] fileName, char[] source, IProblemReporter
> reporter);
>
> The only other thing I see is that both methods have access to the current
> IProblemReporter.
> From another topic I was told that until you edit a module,
> IProblemReporter will be null.
>
> Is that currenly the only way to distinguish between a compilation unit
> and a working copy - or is there another way?
>
> Thanks,
>
> Chuck
>
>
>
>

I'm assuming I can distinguish between clean complition unit and a
potentially dirty working copy by looking at properties of the source
module, i.e. isWorkingCopy()?

Is that true?

Chuck

"Chuck Doucette" <cdoucette@vaultus.com> wrote in message
news:gcddad$ulu$1@build.eclipse.org...
> I'd still like to know how to distinguish between clean compilation units
> (parsed and/or checked as part of a build) and potentially dirty working
> copies (invoked from an editor).
>
> Thanks,
> Chuck
>
> "Chuck Doucette" <cdoucette@vaultus.com> wrote in message
> news:g4u8ni$803$1@build.eclipse.org...
>> Since apparently we are unable to affect the internal DLTK model of our
>> source modules, we attempt to build and refine our own models. Somehow we
>> want the ability to distinguish between clean compilation units (not open
>> as editor input) and potentially dirty working copies (open in an editor
>> window). The model of a working copy could refer to something defined in
>> a model of a compilation unit, but not vice-versa. Thus, we believe we
>> need a way to distinguish between those two sources of input.
>>
>> I've seen that the interface ISourceModule has the method isWorkingCopy.
>> Unfortunately, the parser interface methods that we can easily override
>> do not refer to that interface:
>>
>> 1) ISourceElementParser.parseSourceModule: (this is the high level
>> interface when I also do semantic checks per module)
>> public void parseSourceModule(char[] contents, ISourceModuleInfo
>> astCache, char[] filename) {
>>
>> 2) ISourceParser.parse: (this is the low level interface where I simply
>> create the AST tree and populate our corresponding model of declarations)
>> ModuleDeclaration parse(char[] fileName, char[] source, IProblemReporter
>> reporter);
>>
>> The only other thing I see is that both methods have access to the
>> current IProblemReporter.
>> From another topic I was told that until you edit a module,
>> IProblemReporter will be null.
>>
>> Is that currenly the only way to distinguish between a compilation unit
>> and a working copy - or is there another way?
>>
>> Thanks,
>>
>> Chuck
>>
>>
>>
>>
>
>

isWorkingCopy() is one of the ways, also you can check buildType in the
beginBuild() method of the IBuildParticipantExtension

Regards,
Alex

Chuck Doucette wrote:
> Apparently - my build participants (except for the parser I assume) are now
> supposed
> to implement IBuildParticipant:
> void build(ISourceModule module, ModuleDeclaration ast, IProblemReporter
> reporter) throws CoreException;
>
> I'm assuming I can distinguish between clean complition unit and a
> potentially dirty working copy by looking at properties of the source
> module, i.e. isWorkingCopy()?
>
> Is that true?
>
> Chuck
>
> "Chuck Doucette" <cdoucette@vaultus.com> wrote in message
> news:gcddad$ulu$1@build.eclipse.org...
>> I'd still like to know how to distinguish between clean compilation units
>> (parsed and/or checked as part of a build) and potentially dirty working
>> copies (invoked from an editor).
>>
>> Thanks,
>> Chuck
>>
>> "Chuck Doucette" <cdoucette@vaultus.com> wrote in message
>> news:g4u8ni$803$1@build.eclipse.org...
>>> Since apparently we are unable to affect the internal DLTK model of our
>>> source modules, we attempt to build and refine our own models. Somehow we
>>> want the ability to distinguish between clean compilation units (not open
>>> as editor input) and potentially dirty working copies (open in an editor
>>> window). The model of a working copy could refer to something defined in
>>> a model of a compilation unit, but not vice-versa. Thus, we believe we
>>> need a way to distinguish between those two sources of input.
>>>
>>> I've seen that the interface ISourceModule has the method isWorkingCopy.
>>> Unfortunately, the parser interface methods that we can easily override
>>> do not refer to that interface:
>>>
>>> 1) ISourceElementParser.parseSourceModule: (this is the high level
>>> interface when I also do semantic checks per module)
>>> public void parseSourceModule(char[] contents, ISourceModuleInfo
>>> astCache, char[] filename) {
>>>
>>> 2) ISourceParser.parse: (this is the low level interface where I simply
>>> create the AST tree and populate our corresponding model of declarations)
>>> ModuleDeclaration parse(char[] fileName, char[] source, IProblemReporter
>>> reporter);
>>>
>>> The only other thing I see is that both methods have access to the
>>> current IProblemReporter.
>>> From another topic I was told that until you edit a module,
>>> IProblemReporter will be null.
>>>
>>> Is that currenly the only way to distinguish between a compilation unit
>>> and a working copy - or is there another way?
>>>
>>> Thanks,
>>>
>>> Chuck
>>>
>>>
>>>
>>>
>>
>
>