Breaking API change from M1 to M2 : ISourceCodeContext, TypeUtil and others

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Breaking API change from M1 to M2 : ISourceCodeContext, TypeUtil and others

Aurélien Pupier
Hi all,

we are upgrading from M1 to M2.
We noticed that ISourceCodeContext, TypeUtil, SourceContextInfo, Field, org.codehaus.groovy.eclipse.core.types.* no more exist.
What replace these classes? Which is the corresponding API? and How should we use the new API?

Thanks by advance for your help

Best regards,

Aurelien Pupier
R&D Engineer, BOS Studio Developer

BonitaSoft - Open your processes
email : [hidden email]

This message and any attachment (the "message") is intended solely for the addressees and is confidential. If you receive this message by mistake, please delete it and notify the sender immediately. Any use not in accordance with its purpose, any out-spread or disclosure, either as a whole or partially, is prohibited except with formal approval. Internet cannot guarantee the integrity of this message, therefore BonitaSoft will not be liable for the message if modified.
Reply | Threaded
Open this post in threaded view
|

Re: Breaking API change from M1 to M2 : ISourceCodeContext, TypeUtil and others

Andrew Eisenberg
That is correct.  All of this has been removed.  This is legacy code from V1 of the plugin.  Instead you should be using the corresonding IJavaElement classes such as IField, IMethod, etc.

Exactly how to use this will depend on what you are trying to do.  Please explain.

I have also added a few new extension points that may be of interest to you.  I will be blogging about them soon.

Also, although the API is approaching a steady state and we don't expect any major changes, please let me know what part of the code you are using and I will be sure to maintain backwards compatibility.


On Mon, Dec 14, 2009 at 9:50 AM, Aurélien Pupier <[hidden email]> wrote:
Hi all,

we are upgrading from M1 to M2.
We noticed that ISourceCodeContext, TypeUtil, SourceContextInfo, Field, org.codehaus.groovy.eclipse.core.types.* no more exist.
What replace these classes? Which is the corresponding API? and How should we use the new API?

Thanks by advance for your help

Best regards,

Aurelien Pupier
R&D Engineer, BOS Studio Developer

BonitaSoft - Open your processes
email : [hidden email]

This message and any attachment (the "message") is intended solely for the addressees and is confidential. If you receive this message by mistake, please delete it and notify the sender immediately. Any use not in accordance with its purpose, any out-spread or disclosure, either as a whole or partially, is prohibited except with formal approval. Internet cannot guarantee the integrity of this message, therefore BonitaSoft will not be liable for the message if modified.

Reply | Threaded
Open this post in threaded view
|

Re: Breaking API change from M1 to M2 : ISourceCodeContext, TypeUtil and others

Andrew Eisenberg
> We have a dialog in which one we embed a lighter GroovyEditor (inhereting from the "standard" Groovy Editor), so that users can easily write small but powerful pieces of code when designing a process (see http://twitpic.com/q7s63), with completion and context awareness.
> Then we were using ISounceCodeContext to inject some AST in the dialog to give to user the ability to get some info about variables and methods, but also to give him the ability to simulate the execution of script by setting variables values.

That is very, very cool indeed.  I'd like to try it out.  I've been
wanting to have something like the Display view, but for Groovy code.
If I'm understanding you right, then there is some overlap here, in
that your code allows a user to execute a groovy code snippet and
tweak its values.  I think there is some general usefulness that can
be extracted from there.  Any desire to submit this as a patch?

The new extension points are primarily for extending the groovy type
system for use with custom DSLs such as Grails (allowing editor syntax
highlighting, content assist, and navigation to be extensible), so I
don't think it is directly applicable to what you are doing.

> We don't wish to make spend your time working on backward compatibility, so that you'll for sure find new powerful features to implement ;)
> However, I don't really know what to use instead of a ISourceCodeContext... Maybe you have a hint for us?
There are three things that might be useful for you:

* CompletionNodeFinder - this class is used to find the AST node and
supporting context information whenever content assist is invoked
* ASTNodeFinder - his class is used to find the declaration of the
current selection.  I'd recommend using
CompilationUnit.codeSelect(..), which uses this class to do its magic.
* TypeInferencingVisitorWithRequestor - a generic visitor that
provides a TypeRequestor with type information for all ASTNodes in a
groovy ModuleNode.

You can see code for how each of these are used.  Also, feel free to
ask any questions here.  And, if there is something left unimplemented
or some missing API, please raise a bug for it.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Breaking API change from M1 to M2 : ISourceCodeContext, TypeUtil and others

Andrew Eisenberg
Thanks from our team ! Yo can try this in the M5 of Bonita Open Solution, everywhere yo get an "Edit Expression" widget (buttons or in combo). Feel free to download it at http://www.bonitasoft.com/products/downloads.php. Your feedback on bonitasoft.org forum would be greetly appreciated ;)

I will have a look.
 

We are currently very busy with the finalization of the product, which is to be released for mid-January. Then we cannot put some development strength in refactoring to make it clean enough to be contributed yet. Moreover there are some dependencies to some runtime part of the workflow engine for evaluation that may not be acceptable for a patch.
Would this piece of code interest you enough to be worth contributing it in such state? In that case, we could discuss with our boss about contributing it "as it" so that you could use it as a starting point or to get ideas for the "Groovy display" view, but we could not help you much more than by answering some questions until we get more time...


Understandable, but perhaps I will look at the code.  Better debug capability isn't on the roadmap until post 2.0.  So, there is time.  I do see that the code is GPL.  Unfortunately, this is incompatible with ASL, and I wouldn't be able to use any of the code unless there is a license change.