This will most likely fall into the "Oh, man, why did I hit send?"
category for me, but what the hell.  There have been a number of posts
recently, both in this group, on blogs (See Jim Priest's
http://www.thecrumb.com/2008/04/02/the-semi-annual-cfeclipse-sucks-po...
 ), and in the Aptana Jira on the state of CFEclipse. The folks
carrying on the conversations are smart, dedicated, respected members
of the CF Community.

I rarely get involved in these kinds of talks, for these reasons: 1)
who cares what I think. really. By nature I don't like to opine in
public  2) I don't have anything new to add that these fine folks
haven't said already. But I've read a few things recently that made me
actually want to say something on the topic, because it is one I care
deeply about since I spend most of my working day in this IDE.

What got me thinking:

1) Jim's post, mentioned above. I've probably come across it half a
dozen times since he posted it. I've wondered how many other people
read it and said "eh, whatever.". What I really wondered is how many
people in the CF Community would be willing to either a) lend their
java skills to cfeclipse or b) learn enough java to contribute in some
manner. This then got me thinking about why people contribute to open
source in general. This got me thinking why other java programmers in
the community don't contribute to the highest-profile java project
there is in the cf community (cfeclipse)

2) Shortly after reading jim's post the last time, I stumbled on this
(no idea how): http://www.returnundefined.com/2008/02/i-guess-donating-code-isnt-eno....
 It's a great read, very short. Lots of great cussing. And a situation
I've not yet run into with mxunit but which I'm sure will happen some
day.

3) This post, which I just read today, even though it's a few weeks
old: http://www.adrocknaphobia.com/post.cfm/open-sounce-could-be-last-hope....
It's adobe's adam lehman on the open sourcing of blue dragon.

4) And, lastly, I finally decided to read the aptana jira that Jim
referenced in his CFIDE survey post  to this group from April 9
(http://support.aptana.com/asap/browse/STU-284).

The last 2 really got to me.

First, I have to say that I've wanted to contribute to CFEclipse for
some time now. I started learning Eclipse RCP back in June 07. Since
then, I've put out a pretty good first-timer plugin, and I had a great
time learning how to do it. In fact, it's probably been the most fun
I've had programming in a long time. Not "couple of friends, bottle of
Dalwhinnie 15, box of Cohibas at the nudie bar" fun. Not "driving down
the highway at 180 in my new Ferrari" fun. More like "I can't believe
I just did 300 pullups" fun. "I can't believe I climbed up that
perfectly good mountain and all i got were these stinkin' bloody
fingers" fun.  The kind of thrill you get when you've done something
really hard that you've never done before and didn't know you  had in
you kind of fun.  Remember when you first started programming, or even
when you first started with CF, and you were up till 2 AM b/c you were
so jacked up about putting out this rad site for you and your buddies
to keep in touch on? Or you made an online newsletter your grandma
could use? Or when you first heard of Ajax and you were so stoked
about your new whizbang effects thingamajiggie that pulsed 30 soap
feeds and bound to some div and had a loading mask and all that?
Well, it was like that.

I've looked at the cfeclipse code. A lot. Many times. But I've always
resisted contributing. Lots of reasons, at least initially. The
biggest one is time. If you've never done open source, you have no
idea how much time it can eat up. It can be like another full time
job. This is why I commend mark drew so mightily for what he's done.
Back in 2005, I tried cfeclipse probably 2 or 3 different times. Each
time, I went back to Studio and used Eclipse just for java. When I
used it for CF, it just crashed all the damn time. I credit mark for
making it stable... stable enough that the majority of developers in
our IT dept. use it where i work. That's no small feat, considering
the people who don't use it use VI and TextPad.  But my reasons for
continuing to not contribute have changed somewhat, and  those posts
mentioned above kind of crystallized it for me. Then, they got me
thinking bigger picture about the state of cfeclipse right now, where
it's headed, what IDE I'll be using in 2 years, etc.

This brings me to these two questions: Why don't I contribute? and
What does CFEclipse need to thrive (survive?)?

1) Why don't I contribute.   I don't know if any of you remember this,
but one of CF's great coders, Matt Liotta, worked for a time on an
Eclipse-based IDE for CF. It was named Helium if I remember correctly.
There was this little horse race, and eventually Helium threw in the
towel and conceded to CFEclipse. At least, I think Matt Liotta was
involved in that. Anyway, here's a great talent... talent which would
be unbelievably helpful for CFEclipse. I bring this up because I want
to say that folk like matt have their reasons for staying out of the
fray, known only to them. What I'm putting here are my own reasons and
noone else's.

Now, then: I've already mentioned time. That feeds into this second
one,  and into which Adam's post factors further. He says in one
paragraph that he'd prefer to see CF's java developers contribute to
an open source IDE as opposed to Blue Dragon. But then, down in a
comment, he writes this: "@All - Regarding a comprehensive IDE, I
completely agree and Adobe hears ya. Keep your eyes out for more
information on Centaur coming soon. (aka ColdFusion 9)". Whither the
dichotomy?   I love to code, but I'm no dummy. I sure as hell wouldn't
want to give hours and hours of my time to CFEclipse only to have
Adobe come out with CFBuilder a year from now, knowing full well that
it would relegate CFEclipse and the work I've done to a dying niche.
Please remember: this is all free work, but it's not a matter of
money. It's a matter of time. Folk who've contributed lots of time to
open source will understand this tradeoff. It's abstract to most
people. In concrete terms, it's this: All those times your little 4
year old says "Daddy will you play with me?" and you say "Not right
now honey" because you just gotta get this one little thing in for the
project... that's the kind of thing you do. No, it's not all the time.
But it's sometimes. For people like me who work a full time job for a
company that would have no motivation to donate developer time to an
OSS project, the only time you get for this stuff is nights and
weekends. So the least you hope for is that the project lives and
breathes, at least for some time, and that you help people in your
community kick ass. It's volunteerism and it's quite rewarding.
Nonetheless, smart people bet on winners. I wouldn't invest my money
in Joe's Goodtime Pharmacy if I knew Walmart was considering putting
in another store 2 blocks away, because I'd never get my money back.
Reading Adam's comment was icing on the "Don't waste your time, go out
and play with the kids" cake.

Now, I'm going to be accused (rightfully so) of taking that quote out
of context, of parsing language and reading tea leaves and all that.
You're right. I am. Still, let's look at some of the other recent
factors that heretofore haven't affected CFEclipse much, at least not
directly, but which dovetail with Adam's language. These are reasons
why you see (In jim's terms) Semi-Annual "Why CFEclipse sucks" posts
but not really any "Where's CFEclipse headed?" granola-and-sunshine
posts. Because by and large CFEclipse is the only worthwhile open
source IDE for CF if you want other enterprisey functionality in a
single IDE. The eclipse ecosystem is unbelievable. Just astonishing.
The reason I ditched CFStudio was certainly not because CFEclipse had
so many killer apps.  It's that it finally got to a point where it
didn't crash every day, it had good-enough code hinting, and they
brought in ctrl-j snippets. Seriously, that's about all I use. That
and the methods view. And when it finally got good enough for every
day use, I knew I could take advantage of the real reason for
switching to eclipse for CF, which was all the other stuff you get
with other eclipse plugins: good-enough source control integration,
killer searching, ant, projects (I hate the cfstudio filesystem view
of the world), working sets, etc. Add mylar/mylyn on top of that....
good stuff.     Anyway, the other editors right now are either way too
old, are Dreamweaver (kind of sucky for coding I think, but great for
design), or are simple text editors.  So my point is that cfeclipse
doesn't have much competition. Now, to bring this around to Adam's
post about IDEs and CF9: To me, FlexBuilder 3 shows adobe is quite
serious about the IDE game, at least in some contexts. Clearly,
they've got eclipse RCP talent and an unbelievably deep bench. I look
at flexbuilder 3, and I look at CFEclipse, and I think "they could
build an eclipse-based ColdFusion IDE in 3 months". that'd be a for a
working, usable alpha.  With one fell swoop, they could render
CFEclipse unnecessary (except maybe the frameworks explorer and
snipex). that fell swoop would be a sub-300 IDE. Well, maybe sub-200.

You'd be perfectly right to think "What benefit would they have in
putting out a payware IDE?". I agree. One: to make money. that's the
obvious reason; however, big companies can tolerate a loss leader and
this could be one, especially one where the loss is minimal. I'm no
actuarial genius, though, so I really don't want to speak about stuff
I don't know jack about, so I'll shut up on that.  Now here is where I
get in trouble. What if, just what if, it would make sense for Adobe
to not be terribly excited about the BD open sourcing? How do you
counter that? Make CF itself free? Hell no. No way. So far, the
company line has been to ignore it. Well, ...

read more »

Whew. That wore me out!  :)

I do remember this and often wondered what happened to it... From what I
can remember CFEclipse simply had more features - but it's been so long
ago...  And I don't know why they decided to develop something new
instead of contributing to CFEclipse...
http://blog.daemon.com.au/archives/000270.html

This is what really scares me now... Adobe could really crush OpenBD
(and the other CFML engines) by doing some kind of free "ColdFusion
only" IDE.  IMO though this would really SUCK.

Agreed.  Maybe something like the recent OpenBD "steering committee".

I don't know what the story here is either. Maybe Mark and/or Denny
could shed some light on this?

I like this idea - Adobe and NewAtlanta could both afford to do this.
It could be like Google's "Summer of Code"...

Yep!  I'm collecting data so it's there for anyone!

Well I think this small novel shows we're slowly progressing.
Discussion is good.  I'm trying to drum up conversation and you took the
bull by the horns :)

A month ago I was for the Aptana merge - just because there was the
potential to get Mark some much needed help and I think the Aptana folks
are fairly cool.  But they have a business to run and I could see them
looking at the viability of whatever they did to make money.

With the OpenBD announcement my view has shifted I think.  Now I think
we need to look at a "CFML Editor" vs. a "ColdFusion Editor".  For
OpenBD (and the others) to thrive (as you pointed out earlier) they will
need an IDE that supports ALL vendors.

So now I think:

1) We need a steering committee - Mark, some folks from Adobe, Smith,
Railo and NewAtlanta and the CF community
2) Come up with a 'base', free, CFML editor - I think CFEclipse fits
this nicely
3) Fix the bugs and issues that currently exist in CFE (developers
either provided by or trained by vendors above)
4) Individual vendors could contribute plugins that extend the base
functionality for their specific platform

If Mark is reading this I'd love to hear his opinions?  Does this seem
like a feasible way to move forward?  I would be happy to maybe contact
the OpenBD folks and see how they went about setting up their committee
since they recently did this.

Jim

Whoa! a massive post with lots of things to think about. I even  
printed it out, went outside for a smoke and read it all (yes! All of  
it!)

I shall do my best to answer/comment on things:

1) Re: Denny's contributions. My lazyness/disorganisation/lack of  
time. I spent some time this weekend going through patches and adding  
them to the source code (see: http://trac.cfeclipse.org/cfeclipse/timeline?from=04%2F15%2F08&daysba...)

2) I would hate to see CFEclipse be burned by anything else, but it  
would still be a viable project even with a Adobe IDE. There have been  
other IDE's out (even Rob Rohan did one!) and people will use the tool  
they like more for whatever reason. There are still people that use  
CFStudio and are happy about it. So I dont think it would die,  
besides, variety is the spice of life! :D

3) I totally agree, and as you might notice, I bill myself as Lead  
Developer, not project lead or anything like that. People from the  
project left for their own reasons and I am just the Lead (or rather  
last) Developer. I think despite previous failures in this point, I  
would love to see a board and to be honest, more help (Jim has done  
some EXCELLENT work on the site, which I didnt have time for, and I  
shall buy him a  beer or three next time I see him!)

Alright... I fall for it.. I shall add that to my roles :)

Its not bad... mainly Jack Daniels really...

Not after too many of the JD's I cant...

Gentlemen, its YOUR project, its open source for a reason. to be  
honest, I need to give Denny commit access and then we need a process  
so that every ticket is tested by someone before it can be closed.  
That kind of organization in the project is needed, with more than my  
pair of eyes doing it.

Its great to see activity in the Trac site, with people closing  
tickets when they are obviously fixed (I imported a whole bunch of  
issues from the tigris site that are still knocking around). This  
takes a great load of my mind at any rate.

I will try and do a few of these, but so far, when I have mentioned it  
in some circles, I have had very little response on this. Also, the  
source code for CFEclipse does *MY* head in sometimes, since its not  
as neat as it could be and there are 1000's of classes about which  
could be removed (I did some of that this weekend) or re-written
Agreed... lf course, we need resource to work to that milestone.

Well, ok... this is easy enough to setup. of course, the only problem  
here is that Simeon manages the trac server etc, but I am sure I can  
knock up a branch if you want one :)
and for the wiki, well its there! :D

Yeah, forget about Dre(w)! You guys contribute! I have too many irons  
in the fire :) But of course, there are many ways which the project  
can go, a lot of paths it can travel, if we have a couple of  
developers then that is much more fun!

To be honest, I dont understand all the code neither :)

I hope that cleared *something* up...

MD

Mark - thanks for the followup!

Mmmmmmmmmmmmmmmmmmmmmmmm. Beeeeeeeeeeeeer.

Mark - what I'd like to do is check out the survey results and compare
that to the open bugs/feature requests and see if there is any alignment
there - then publish a 'todo' list on the wiki:

1) This is super easy
2) This is easy
3) This is hard but doable
4) I need help with this
5) Freakin impossible!!

That way we can get an idea of what needs to be done, and who can do it.
Maybe someone is out there who does know basic Java stuff but is
intimidated - we can point them to the "This is super easy" list...
Denny and yourself could possibly tag team on the rest...  Maybe you
have an hour of free time - you could tackle a few easy items...

Agreed and I'm here to help in any way I can :)

That might be something else worthwhile to add to the list - what needs
to be trashed, re-written, etc.

I like this idea - but I'd hate for it to interfere with main
development.  Maybe if there is interest in this we can setup a location
for the source - and let people have at that with the disclaimer that
it's bleeding edge.  If something worthwhile comes out of that - then we
could pull that code back into the core.  

We're all doomed :)

I'd like to get more feedback on a steering committee. I may contact the
OpenBD folks to see how they are organizing things - it seems in many
ways we have similar products and goals...

- We have a fairly mature code base
- We want control over the code but with community input
- We want to keep things open-source

And I may contact some of the vendors (Adobe, NewAtlanta) and see if
there is any kind of interest there for an 'open' CFML IDE.  I probably
won't get much out of any of them but it's worth a shot.  

Jim

ehem,  *cough*
http://alan.blog-city.com/bluedragon_steering_committee.htm

I wonder who that handsome guy at the end of the top row is?

MD

LOL.  What? You think *I* know what's going on??

Jim

Thanks for opening this discussion, Marc.

I have contributed to CFEclipse in the past (I used to have committer
status a couple of years ago) and am very interested in doing so again.
I can't take a leadership role, but can tackle specific issues. Part of
what has prevented me from doing so recently is that I don't feel a
clear sense of direction, of what would be most valuable (that I am
capable of doing). I think some of the efforts you describe (steering
committe, road map, etc.) would be very helpful in resolving this.

The other obstacle is that the code is very different than it was when I
worked on it before, and I haven't had the time to dig in and figure out
what's extraneous (as Mark Drew described) and where to jump in. The SVN
structure is less clear to me now (What pieces do I need to check out in
order to properly build the plugin? How do I need to configure project
references/dependencies/etc. in Eclipse to get it working locally?).

If we could get some clarification on these things, it would make it a
lot easier for me to jump back in.

--
Christopher Bradford

And just as I said that...

http://alan.blog-city.com/interview_markdrew.htm

MD

On 15 Apr 2008, at 17:26, Priest, James (NIH/NIEHS) [C] wrote:

Chris - my goal with all this is to come up with some kind of list so
that developers like yourself can get started easier...  As I said - if
we can break it down by difficulty, time, need, etc - I think it will be
much easier to tackle.

Can you take a look at the "CFEclipse Developer Topics" section on the
wiki and let me know if that covers what you need or if we need to add
additional instructions??  If something is missing I can work with Mark
to get that information added.

http://trac.cfeclipse.org/cfeclipse/

Now that I'm done with the CFEclipse site I do want to spend some time
overhauling the wiki and one thing I'd like to do is make the developer
section more prominent...

Thanks for the feedback!  That's exactly the kind of stuff we need to
hear so we can address the issues. I you are having issues - I'm sure
others are as well.

Jim

Chris

I would welcome you back on board! Deffo!

Right, I am sure someone can pretty this up but what you need to check  
out is:

http://svn.cfeclipse.org/org.cfeclipse.cfml/trunk/  (The main  
cfeclipse plugin)

Which is the main code.

If you want to build a feature (so you can have the frameworks and  
unit testing or you want to create an update site) you need to check  
out the above as well as:

http://svn.cfeclipse.org/org.cfeclipse.cfml.frameworks/trunk/  (the  
frameworks plugin)
http://svn.cfeclipse.org/org.cfeclipse.cfml.cfunit/trunk/          (the cfunit  
plugin)

To create an update site you need to check out the feature and the  
update site:

http://svn.cfeclipse.org/org.cfeclipse.cfml.feature/trunk/
http://svn.cfeclipse.org/org.cfeclipse.cfml.update/trunk/

If you are working just on the CFEclipse, you still only need to check  
out the first one I mentioned

With regards to code, I am sure there is a lot there that you will  
recognize :)

MD

On 15 Apr 2008, at 17:35, Christopher Bradford wrote:

With regards to what I am working to, I am trying to do 1.3.2 (ok, we  
could rename that to 1.4 or even 2.0!!!)

http://trac.cfeclipse.org/cfeclipse/query?status=%21closed&group=stat...

I have assigned myself a few of those bugs, but the parsing ones are  
the ones I am a bit slow with, since I havent looked at it for ages  
and there are far too many if/else nested in the CFParser (a whopping  
2000 odd lines of madness methinks!)

Howzat for a starter for 10?

MD

On 15 Apr 2008, at 17:35, Christopher Bradford wrote:

From the interview with Mark Drew
(http://alan.blog-city.com/interview_markdrew.htm):
"As a tools developer, what features are CFML developers demanding from you?
The most requested feature, and one that I would love to implement is to get
insight into the methods of a CFC that you have defined. There are
challenges round this since CFML is a runtime language at heart, and until
you are actually running the code you cant be sure what a variable is. But I
have a couple of ideas."

I've been wanting to write a really good CFML parser for a while now... One
that would work outside of Eclipse as well as in it... Something that would
allow code to be programmatically inspected for conformance to (local)
standards (variable naming, use of scopes, etc), and that would allow
indexes of references & definitions to be built.  (I love what Eclipse does
for Java, for example.)  In short, I want to be able to build a model of an
entire repository of CFML code.  (As MD said, CFML is a runtime language so
a static parser will needs hints here and there to do things right, but I
think it could be done.)

At this point I don't have a lot to show (certainly nothing to "show off"),
but I am growing a set of unit tests for some of the uglier parts of the
language and I have a throw-away parser that handles them. My next step is
to port the hand-coded tag-parsing stuff I have now (which handles code
better than what Eclipse does) into JavaCC, which looks to me to be the best
choice for handling CFML (better than Antrl).  

I'd like to work on this problem in a way that meets my needs for a
stand-alone parser but that could also help CFE.  To do that I need to be
able have a discussion with someone who can say things like "that'll only
work with CFE if you add this and this", and to define boundaries around the
parser so it doesn't become a CFE-only thing (which would limit the value I
can get from the parser).

Anyway, I'll be working on this on and off with or without direction from
the CFE team, but it would be cool to contribute something more than just a
random bug fix to the CFE effort, and if there is already some work going on
within CFE on a better parser then I'd like to hear about it.

Thanks
        Mark G

Mark - that sounds really cool.

There IS a developer mailing list:

http://groups.google.com/group/cfeclipse-dev

It's a bit slow :)  but I'd assume that would be the spot to get
feedback and/or discuss the inner workings of CFEclipse.  And hopefully
with all the renewed interest - activity on it will pick up (that's the
goal anyway!)

Jim

I forgot to re-join when the dev group moved to google... Thanks for the
reminder.

        Mark

So if I take on a Trac issue from that list, should I be working in
trunk or in the 1.3.2 branch?

Chris

--
Christopher Bradford

Just so you guys are aware, I started writing an ANTLR based Open
Source CFML parser for CFEclipse aaaages ago.

It got to somewhere about 80% completion (there are probably a heap of
ege cases I never got around to picking up).

I never had the time to finish it completely, but I'm happy to keep
working on it, if it provides some use to you guys.

I haven't had the time to get into Eclipse development, even though I
have wanted to for a while, but I was pretty handy with ANTLR for a
while, and I'd be happy to get back into it again.

I did also start looking into DLTK a long time ago as well, but the
lack of documentation, and quite likely my complete lack of Eclipse
experience meant I wasn't able to make heads or tails of it.

Mark

On Wed, Apr 16, 2008 at 6:13 AM, Christopher Bradford

--
E: mark.man...@gmail.com
W: www.compoundtheory.com

Hi Mark M
I looked into a couple of Antlr-based attempts at parsing CFML (including
yours, actually, which is in the CFEclipse project somewhere) and while they
are a start, in my opinion Antlr is not the way to go.  I think JavaCC has
more power and we're going to need that power to wrestle CFML down to the
mat.  (Ex: the latest Antlr release does not support case-insensitive
parsing. That really sucks. Ex: JavaCC lets you write an entire production
in java. You may not need it often, but when you do, you do.)  

Another plus for JavaCC: the book "Generating Parsers with JavaCC" is much
better than "The Definitive Antlr Reference".  

The notions in your parser (and the other one in CFE) are definitely helpful
and I've been studying them, but yeah, there are a lot of edge cases that no
parser that I've seen yet handles. And that is before handling the effects
of cfimport!

I'm also of the opinion that a CFML parser should not parse any html...
non-CFML-language elements should be collected as text and associated with
the correct surrounding tag, but a parse tree for a CFML document should not
include elements for tables, links, etc.  (I figure a separate parser should
be used tackle the html parsing job.)

Thanks
        Mark G

I'm all for a Parser that works, and I don't have extensive experience
in this area, so I'm all ears!

I've got a few questions -

I've never used JavaCC, so I couldn't say one way or the other.

That's actually not true at all.  I've got case insensitive parsing in
my Parser, you just need to implement your own StringStream
See:
http://trac.cfeclipse.org/cfeclipse/browser/org.cfeclipse.cfml.core/t...
And:
http://www.antlr.org/wiki/pages/viewpage.action?pageId=1782

ANTLR let's you write inline Java code as well. In fact, in several
places I have needed it.  I couldn't have gotten as far into the
Parser as I had previously without it.

In fact you can see where I've used Java code in the header of the CFML.g.

Generally what I have done is placed stub methods in the CFML.g and
then inherited from the generated Parser to provide the
implementation.

This was just an easier way to write the Java, as I could do it in an
IDE, rather than inline in a .g file.

Again, I'm not having a go, just making sure we're all informed.

Again, I'll take your word on that ;o)

It may just be that you're also more comfortable with JavaCC, in which
case - write it in JavaCC ;)

Either or - I can always rip that out.. my parser just picks up
tags... they could be CFML, or HTML, and in fact, with cfimport with
no prefix can look like HTML, so I figured I would err on the same
side, and get everything, and it could always be made to filter it out
later.

Anyway, like I said, I'm all for having a Parser that works, so I
don't really care who writes it, or in what Parser generator ;o)  Just
wanted to make sure you were informed on all accounts.

Mark

--
E: mark.man...@gmail.com
W: www.compoundtheory.com

Sweeet!  DLTK plays nice with ANTLR!

I cut my Java teeth on parsing, ages ago, and it was fun, but... got old quick.

I guess it's been long enough, because I was looking at writing an
ANTLR based CF parser to test the DLTK stuff with.  :-)

That's what the python DLTK example uses (an antlr parser), and
there's some documentation, so...  figured what the hey.  Barely at
the playing stage tho, still sorta getting a feel for it.

It would be pimp to have a nice ANTLR parser, with a bunch of
test-cases (At the same time as working out ANTLR, I'm working out
Eclipse-based unit testing-- can't do one thing at once, apparently).

I'm currently thinking this:  I'm gonna run through the DLTK docs, and
create a simple IDE.  This basically amounts to writing a ANTLR parser
(and I don't know if ANTLR is the best or what, but there's some
docs/examples, so...  :] ) and a bit of XML.

If that goes swimmingly (hell, it's sounding like fun, which is always
a good sign), we can add it to the repo, and see if anyone else wants
to play.

I'm serious in thinking that a one or two man show (not by preference,
as Mark's mentioned, but we're working with the current recon here)
might actually be able to produce (and maintain!) a pretty swell CF
IDE when using the DLTK stuff-- because a /lot/ of the nifty
functionality is coming from DLTK, which has more contributers, and
will be maintained by those contributers.

As I've said before, I'd actually rather leverage more of the existing
eclipse plugins (data tools platform, WTP, Remote Target Management)
to provide the needed features, as those plugins are eclipse core and
getting attention all the time (more free contributions, basically).
    At least vs. trying to maintain our own filesystem explorer,
FTP/SFTP, SQL, etc. stuff.
Plus: when people get bugs, we can log them against those plugins, and
thus, help everyone become kick-ass, for the price of one.  If that
sorta makes sense.

Yeah, guess that's sorta it, for now.

Just to clarify, there's no bad blood between me and anyone that I
know of-- the lack of assimilation is due to Mark and myself being
busy.  I wasn't pushing, and he wasn't pulling, so it was just sorta
there for anyone...

Great thread!  Amazed that I'm even remotely understandable, I am.  Woohoo!

Denny

PS - Mark (Mandel :]), can you put the parser you did somewhere for me
to look at (or just send via email)?  I dunno if it'll help or not,
but I love data/examples.  If I get a "pluggable" ANTLR CF parser
going,  we can stick it (and the unit tests!) up in the repo and bang
away on test cases.  I think a strong parser is 90% of the battle,
perhaps.  Still feeling it all out, of course. :-)

I'm for sure going to explore DLTK, and I'll report back on what I find.

--
My joy of sharing competes with my fear of corrupting.

It's in SVN -
http://trac.cfeclipse.org/cfeclipse/browser/org.cfeclipse.cfml.core/t...

Mark

--
E: mark.man...@gmail.com
W: www.compoundtheory.com

Heh.  Guess I should finish reading before posting.

Hmmm... JavaCC vs. ANTLR, eh?  Which as more Eclipse support? (We
could deploy as an Eclipse stand-alone for the parser-only stuff).

Now this is some good eat'n.

Yay,
  Denny

This is an interesting idea - and one I agree with I think.  Would it be worthwhile to strip that functionality from CFE and simply point people to other plugins which do it better?

This would eliminate some code and allow developers to focus on more CFML related tasks.

Jim

winmail.dat 3K Download

I just wanted to point out that there are far too many Marks on this list.

From now on in, I shall re-christen myself.... "MD"

:D

MD

On Wed, Apr 16, 2008 at 3:24 AM, Priest, James (NIH/NIEHS) [C]

--
Mark Drew
Blog: http://www.markdrew.co.uk/blog/
LinkedIn: http://www.linkedin.com/in/mdrew

Chris

Go with the trunk. I think when we release 1.3.2 we tag it.

Better to keep one consistent code version ... for the moment.

MD

On Tue, Apr 15, 2008 at 9:13 PM, Christopher Bradford

--
Mark Drew
Blog: http://www.markdrew.co.uk/blog/
LinkedIn: http://www.linkedin.com/in/mdrew

On Tue, Apr 15, 2008 at 8:24 PM, Priest, James (NIH/NIEHS) [C]

I'm thinking that with the new update system in 3.4, it will be even
easier to mix and match plugins.

I think, from where I'm standing, that the dream may be a few different set-ups:

The "core" that uses at least something like remote target management
(filesystem needs) and WTP (for CSS/HTML (there is a WYSIWYG editor in
there now), and JSDT (javascript, very configurable).  Perhaps Data
Tools / RDS tie in for SQL.  Integrate those real nice (I'm thinking
within a single editor pane, even).  Mylyn integration, of course.

Have some blogs / walk thrus (already good bit out there).

And then "extra" configurations, with Testing and Performance / JBoss
whatnots... the UML stuff has come a long way too... There's more blog
entries and whatnot coming out for this stuff, but not much CF
geared-ness-- it would be cool to see more.  Have a "path" even,
sorta, if that makes sense.

To manage these configurations, we either use the new update stuff in
eclipse 3.4 (called equinox, I think) or something like pulse, yuxos,
or hell, our own deal.

That way you've got the light install, (eclipse starts up fast, etc.)
without all the honking goodness, but there's room to grow, for those
that are curious / need it.

I've made a decision to start blogging my adventures with such stuff
as TPTP...  heck, just pooling the info better will do wonders, I'm
thinking.  Looks like that's coming along already, come to think of
it.

Evolution is grand, I do declare!

:denny

--
I love deadlines. I like the whooshing sound they make as they fly by.
    Douglas Adams