Re: [drools-user] IntelliJ Plugin

[Mark Proctor]

Don't forget we are using Drools 3.0. I'd love to see support for 
intelliJ, Netbeans etc, but it will need to come from contributors as 
the core team only has resources for one IDE, Eclipse.

Mark
Jérôme BERNARD wrote:
I've done a quick search on Google and found two interesting things:
- the homepage of JFlex (http://jflex.de/) where they talk (although 
really briefly) about an integration with ANTLR,
- a post 
(http://www.antlr.org:8080/pipermail/antlr-interest/2006-April/015974.html) 
on the ANTLR ML where someone did something quite similar.

So a possible solution seems to be to "hack" the ANTLR grammar in 
order to use JFlex lexer instead of the ANTLR one.
BTW a side effect could be potential speed improvement as some 
benchmarks "proves" JFlex lexer faster than the ANTLR one.
Now maintenance might be a bit harder as a change in Drools grammar 
would have to be "replicated" in the ANTLR+JFlex one.

Hope this helps.

Regards,
Jérôme.


On 2 mai 06, at 01:56, Michael Neale wrote:

yes recognising blocks of code is immensely hard, as you kind of have to
expect anything in those blocks. I am planning in future to add in a 
"CDATA"
like feature to make lexing more seamless (just a small improvement that
means we can avoid keyword collissions).

It sounds like jflex has done the easy part, and left the hard part 
up to
you ;) still, its interesting.

On 5/2/06, Russ Egan <[EMAIL PROTECTED]> wrote:

I started giving this a shot, by starting with their java script 
plugin.
But I've found translating antlr to jflex is tricky: where antlr 
defines
both the lexer and the parser, jflex is just a lexer.  That makes it
tricky to recognize the embedded java code in the drl files.  You 
need to
figure out which blocks of text are java, and therefore shouldn't be 
more
granularly tokenized.  And you need to figure that out by just using 
token
recognition.

I don't have any experience with lexers or compilers (I'm not a compsci
grad), so maybe it's not really has hard as it seems to me.

The other drawback to intellij's support is that you can't leverage 
a nice
tool like antlr to handle parsing.  You have to write the parsing by
hand.  At least, that's how their javascript plugin works.  It might be
possible to embed antlr in the plugin, and adapt it's output to IDEA's
plugin API.  Unfortunately, the plugin is expected to expose the
intermediary lexer output directly to the IDE to enable highlighting 
and
such.

On Mon, 01 May 2006 06:10:20 -0400, Michael Neale
<[EMAIL PROTECTED]> wrote:

> I would love to, but we get killed for even looking at something non
open
> source sideways ;) as we are an antlr grammar, that would be nice.
>
> On 5/1/06, Fabian Crabus <[EMAIL PROTECTED]> wrote:
>>
>> jepp...the meta programming system is not for mere mortals (tried 
it,
>> had
>> a look
>> at the hello world, didn't grasp a bit, uninstalled 
it)...nevertheless
>> they offer
>> custom language support via their plugin sdk. It's based on some 
jflex
>> magic, that
>> can be adapted to antlr based languages- though it's not really for
>> the faint of heart.
>> So I'd hoped that someone dug a little deeper...
>>
>> On 5/1/06, Michael Neale <[EMAIL PROTECTED]> wrote:
>> > Not that I am aware of. Has been a few years since I have used
>> intelliJ,
>> but
>> > I am aware that they have some advanced concepts around
>> meta-programming,
>> > and making new languages, but they are probably not open 
source, so
>> that
>> may
>> > put a dampener on things.
>> >
>> > On 5/1/06, Fabian Crabus <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Hi,
>> > >
>> > > speaking of rule editors: is anyone working on an IntelliJ 
plugin?
>> > > Something along the lines of the groovyJ plugin?
>> > > I've started to look into IntelliJ's custom language support but
the
>> > > documentation has -hmm- a potential to be more helpful ;)
>> > >
>> > > So has anyone done some work on something like this? Or can
>> > > anyone give me a pointer?
>> > >
>> > > Thanks,
>> > > Fabian
>> > >
>> >
>> >
>>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/




--
Jérôme BERNARD,
Kalixia, SARL.
http://weblog.kalixia.com