I will post the full text of an email I just sent to Integral (the awsome folks behind FusionDebug, FusionReactor, etc) after this. Please do not consider this flame bait - it's an honest question. I have actually donated a significant amount of money to CFE in the past, and I am willing to do so agan. It just seems like the project has stagnated, and I'm only looking to move it forward. If I can pay for people to work on CFE instead of having to pay Integral, I'd be more than happy to do so.
Yes, I know it's open source, and yes, I have downloaded the project and tried to make changes. I'm not interested in that path - I'm looking to directly fund the project to help it meet my needs, and hopefully my needs align somewhat with everyone else's.
Roland
My Email to Integral:
My name is Roland Collins. I’ve recently purchased FusionDebug, FusionReactor, and FusionAnalytics from you, and I could not be happier with the products you guys create. They’re truly amazing, and they have paid for themselves many times over. We’re on the cusp of getting some of our resellers to adopt your products as well. We may be a relatively small company, but we occupy a niche in the Financial Services industry with little competition. Your tools have recently been a large part of that success. There is nothing out there that compares to what you guys have built – especially at the price point.
Knowing that you are ColdFusion experts, I thought I would pose a question to you. Our current development environment is Eclipse (4.2), Aptana, CFEclipse, and FusionDebug. This has been an amazingly successful suite for us, even with the advent of CF10. However, it seems like CFEclipse is dead in the water at this point, even though we consider it far superior to CFBuilder. Quite frankly, we consider CFBuilder to be a joke of a product in our shop. It’s fine for small projects and “light” apps, but we have a massive ColdFusion codebase. CFEclipse is fast, reliable, and plays well with other Eclipse plugins. CFBuilder is slow, crashes all the time, and assumes that it is the only plugin that matters. To put it in perspective, we’ve been using CF as our primary application server since ’96. We have CFCs that are ~10k lines long (libraries, not OOP classes). CFB sucks at dealing with this kind of environment. CFE is close, but not perfect, although it is much better.
The reason I’m writing to you guys tonight is to see if you would be at all interested at some funded CFEclipse development. To put it plainly, the way I see it, either CFEclipse gets resurrected, or I will eventually have to purchase licenses for CFB for all of my developers. And that would be tragic – it’s slower, it’s way too tightly integrated, and it’s … well … how do I say this politely… managed by an offshore company that has no interest other than profit.
The tools you have already developed seem to be a natural fit for the platform, and indeed they work amazingly well. My company isn’t large by any stretch, but we are more than willing to pay for tools that help us save time. I guess my question boils down to this – if we were willing to spend some money, would you be willing to spend that money on improving CFEclipse? And I’m not looking for proprietary work here either – any investment we would make, I would be perfectly happy with you guys reselling that effort. All that I care about is making my developers more efficient. I know you have consulting services, so I hope that this question isn’t entirely out of left-field. I’m not looking for you guys to reinvent a product that already works really well for us – I’m just curious if there are ways that we could incite you to improve an existing product in a mutually beneficial way.
FWIW, here is the “wish list” of things we would lie to see added to CFE:
• Scan the Eclipse project for CFCs . ( Add a new view that shows CFCs and the functions within those CFCs, based on my project root).
o This should be a persistent view. I shouldn’t have to be working inside the CFC to see this.
o Show me a list of all CFCs in the project, and all functions in those CFCs.
• Support mappings for CFCs. (Let me specify that <cfinvoke component=”Foo.Bar” mthod=”baz”> maps to C:\InetPub\myapp\CFC\foo\bar.cfc, or more importantly, let me map to C:\InetPub\myapp\CFC\foo to “Foo.”).
o This should be a persistent view. I shouldn’t have to be working inside the CFC to see this.
• Provide insight for arguments-scoped and locally-scoped variables. I don’t need fancy handling – just let me ctrl-space the names!!!!.
That’s really about it!
If this is something you would at all be interested in, please let me know.
rc.rules.the.unive...@gmail.com> wrote:
> I will post the full text of an email I just sent to Integral (the awsome
> folks behind FusionDebug, FusionReactor, etc) after this. Please do not
> consider this flame bait - it's an honest question. I have actually
> donated a significant amount of money to CFE in the past, and I am willing
> to do so agan. It just seems like the project has stagnated, and I'm only
> looking to move it forward. If I can pay for people to work on CFE instead
> of having to pay Integral, I'd be more than happy to do so.
> Yes, I know it's open source, and yes, I have downloaded the project and
> tried to make changes. I'm not interested in that path - I'm looking to
> directly fund the project to help it meet my needs, and hopefully my needs
> align somewhat with everyone else's.
> Roland
> My Email to Integral:
> ******
> **My name is Roland Collins. I’ve recently purchased FusionDebug,
> FusionReactor, and FusionAnalytics from you, and I could not be happier
> with the products you guys create. They’re truly amazing, and they have
> paid for themselves many times over. We’re on the cusp of getting some of
> our resellers to adopt your products as well. We may be a relatively small
> company, but we occupy a niche in the Financial Services industry with
> little competition. Your tools have recently been a large part of that
> success. There is nothing out there that compares to what you guys have
> built – especially at the price point.**
> **Knowing that you are ColdFusion experts, I thought I would pose a
> question to you. Our current development environment is Eclipse (4.2),
> Aptana, CFEclipse, and FusionDebug. This has been an amazingly successful
> suite for us, even with the advent of CF10. However, it seems like
> CFEclipse is dead in the water at this point, even though we consider it
> far superior to CFBuilder. Quite frankly, we consider CFBuilder to be a
> joke of a product in our shop. It’s fine for small projects and “light”
> apps, but we have a massive ColdFusion codebase. CFEclipse is fast,
> reliable, and plays well with other Eclipse plugins. CFBuilder is slow,
> crashes all the time, and assumes that it is the only plugin that matters.
> To put it in perspective, we’ve been using CF as our primary application
> server since ’96. We have CFCs that are ~10k lines long (libraries, not
> OOP classes). CFB sucks at dealing with this kind of environment. CFE is
> close, but not perfect, although it is much better.**
> ****
> **The reason I’m writing to you guys tonight is to see if you would be at
> all interested at some funded CFEclipse development. To put it plainly,
> the way I see it, either CFEclipse gets resurrected, or I will eventually
> have to purchase licenses for CFB for all of my developers. And that would
> be tragic – it’s slower, it’s way too tightly integrated, and it’s … well …
> how do I say this politely… managed by an offshore company that has no
> interest other than profit.**
> ****
> **The tools you have already developed seem to be a natural fit for the
> platform, and indeed they work amazingly well. My company isn’t large by
> any stretch, but we are more than willing to pay for tools that help us
> save time. I guess my question boils down to this – if we were willing to
> spend some money, would you be willing to spend that money on improving
> CFEclipse? And I’m not looking for proprietary work here either – any
> investment we would make, I would be perfectly happy with you guys
> reselling that effort. All that I care about is making my developers more
> efficient. I know you have consulting services, so I hope that this
> question isn’t entirely out of left-field. I’m not looking for you guys to
> reinvent a product that already works really well for us – I’m just curious
> if there are ways that we could incite you to improve an existing product
> in a mutually beneficial way.**
> **FWIW, here is the “wish list” of things we would lie to see added to
> CFE:**
> **
> • Scan the Eclipse project for CFCs . ( Add a new view that shows CFCs and
> the functions within those CFCs, based on my project root).
> o This should be a persistent view. I shouldn’t have to be working inside
> the CFC to see this.
> o Show me a list of all CFCs in the project, and all functions in those
> CFCs.
> • Support mappings for CFCs. (Let me specify that <cfinvoke
> component=”Foo.Bar” mthod=”baz”> maps to C:\InetPub\myapp\CFC\foo\bar.cfc,
> or more importantly, let me map to C:\InetPub\myapp\CFC\foo to “Foo.”).
> o This should be a persistent view. I shouldn’t have to be working inside
> the CFC to see this.
> • Provide insight for arguments-scoped and locally-scoped variables. I
> don’t need fancy handling – just let me ctrl-space the names!!!!.**
> **That’s really about it!**
> **If this is something you would at all be interested in, please let me
> know.
> **
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online:
> http://groups.google.com/group/cfeclipse-users?hl=en
> Rolando - thanks for the email and the kind words for CFEclipse.
> I honestly don't know what the current development status is.
> Historically there have always been up and down periods of development and we're certainly in a down period lately.
> Denny and Mark occasionally pop up here but I believe they are both heavily working on Railo 4.
> Keep us posted if you hear anything back.
> Jim
> On Sat, Jul 7, 2012 at 4:30 AM, Roland Collins <rc.rules.the.unive...@gmail.com> wrote:
> I will post the full text of an email I just sent to Integral (the awsome folks behind FusionDebug, FusionReactor, etc) after this. Please do not consider this flame bait - it's an honest question. I have actually donated a significant amount of money to CFE in the past, and I am willing to do so agan. It just seems like the project has stagnated, and I'm only looking to move it forward. If I can pay for people to work on CFE instead of having to pay Integral, I'd be more than happy to do so.
> Yes, I know it's open source, and yes, I have downloaded the project and tried to make changes. I'm not interested in that path - I'm looking to directly fund the project to help it meet my needs, and hopefully my needs align somewhat with everyone else's.
> Roland
> My Email to Integral:
> My name is Roland Collins. I’ve recently purchased FusionDebug, FusionReactor, and FusionAnalytics from you, and I could not be happier with the products you guys create. They’re truly amazing, and they have paid for themselves many times over. We’re on the cusp of getting some of our resellers to adopt your products as well. We may be a relatively small company, but we occupy a niche in the Financial Services industry with little competition. Your tools have recently been a large part of that success. There is nothing out there that compares to what you guys have built – especially at the price point.
> Knowing that you are ColdFusion experts, I thought I would pose a question to you. Our current development environment is Eclipse (4.2), Aptana, CFEclipse, and FusionDebug. This has been an amazingly successful suite for us, even with the advent of CF10. However, it seems like CFEclipse is dead in the water at this point, even though we consider it far superior to CFBuilder. Quite frankly, we consider CFBuilder to be a joke of a product in our shop. It’s fine for small projects and “light” apps, but we have a massive ColdFusion codebase. CFEclipse is fast, reliable, and plays well with other Eclipse plugins. CFBuilder is slow, crashes all the time, and assumes that it is the only plugin that matters. To put it in perspective, we’ve been using CF as our primary application server since ’96. We have CFCs that are ~10k lines long (libraries, not OOP classes). CFB sucks at dealing with this kind of environment. CFE is close, but not perfect, although it is much better.
> The reason I’m writing to you guys tonight is to see if you would be at all interested at some funded CFEclipse development. To put it plainly, the way I see it, either CFEclipse gets resurrected, or I will eventually have to purchase licenses for CFB for all of my developers. And that would be tragic – it’s slower, it’s way too tightly integrated, and it’s … well … how do I say this politely… managed by an offshore company that has no interest other than profit.
> The tools you have already developed seem to be a natural fit for the platform, and indeed they work amazingly well. My company isn’t large by any stretch, but we are more than willing to pay for tools that help us save time. I guess my question boils down to this – if we were willing to spend some money, would you be willing to spend that money on improving CFEclipse? And I’m not looking for proprietary work here either – any investment we would make, I would be perfectly happy with you guys reselling that effort. All that I care about is making my developers more efficient. I know you have consulting services, so I hope that this question isn’t entirely out of left-field. I’m not looking for you guys to reinvent a product that already works really well for us – I’m just curious if there are ways that we could incite you to improve an existing product in a mutually beneficial way.
> FWIW, here is the “wish list” of things we would lie to see added to CFE:
> • Scan the Eclipse project for CFCs . ( Add a new view that shows CFCs and the functions within those CFCs, based on my project root).
> o This should be a persistent view. I shouldn’t have to be working inside the CFC to see this.
> o Show me a list of all CFCs in the project, and all functions in those CFCs.
> • Support mappings for CFCs. (Let me specify that <cfinvoke component=”Foo.Bar” mthod=”baz”> maps to C:\InetPub\myapp\CFC\foo\bar.cfc, or more importantly, let me map to C:\InetPub\myapp\CFC\foo to “Foo.”).
> o This should be a persistent view. I shouldn’t have to be working inside the CFC to see this.
> • Provide insight for arguments-scoped and locally-scoped variables. I don’t need fancy handling – just let me ctrl-space the names!!!!.
> That’s really about it!
> If this is something you would at all be interested in, please let me know.
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
Have you checked out IntelliJ's CFML support? I have found it to be much
faster then CFB while providing nice support for the CFC features you
mentioned below. That being said I would love to see these features be
added to CFEclipse. Perhaps IntelliJ would help you while the CFEclipse
team is working on their next release.
rc.rules.the.unive...@gmail.com> wrote:
> I will post the full text of an email I just sent to Integral (the awsome
> folks behind FusionDebug, FusionReactor, etc) after this. Please do not
> consider this flame bait - it's an honest question. I have actually
> donated a significant amount of money to CFE in the past, and I am willing
> to do so agan. It just seems like the project has stagnated, and I'm only
> looking to move it forward. If I can pay for people to work on CFE instead
> of having to pay Integral, I'd be more than happy to do so.
> Yes, I know it's open source, and yes, I have downloaded the project and
> tried to make changes. I'm not interested in that path - I'm looking to
> directly fund the project to help it meet my needs, and hopefully my needs
> align somewhat with everyone else's.
> Roland
> My Email to Integral:
> ******
> **My name is Roland Collins. I’ve recently purchased FusionDebug,
> FusionReactor, and FusionAnalytics from you, and I could not be happier
> with the products you guys create. They’re truly amazing, and they have
> paid for themselves many times over. We’re on the cusp of getting some of
> our resellers to adopt your products as well. We may be a relatively small
> company, but we occupy a niche in the Financial Services industry with
> little competition. Your tools have recently been a large part of that
> success. There is nothing out there that compares to what you guys have
> built – especially at the price point.**
> **Knowing that you are ColdFusion experts, I thought I would pose a
> question to you. Our current development environment is Eclipse (4.2),
> Aptana, CFEclipse, and FusionDebug. This has been an amazingly successful
> suite for us, even with the advent of CF10. However, it seems like
> CFEclipse is dead in the water at this point, even though we consider it
> far superior to CFBuilder. Quite frankly, we consider CFBuilder to be a
> joke of a product in our shop. It’s fine for small projects and “light”
> apps, but we have a massive ColdFusion codebase. CFEclipse is fast,
> reliable, and plays well with other Eclipse plugins. CFBuilder is slow,
> crashes all the time, and assumes that it is the only plugin that matters.
> To put it in perspective, we’ve been using CF as our primary application
> server since ’96. We have CFCs that are ~10k lines long (libraries, not
> OOP classes). CFB sucks at dealing with this kind of environment. CFE is
> close, but not perfect, although it is much better.**
> ****
> **The reason I’m writing to you guys tonight is to see if you would be at
> all interested at some funded CFEclipse development. To put it plainly,
> the way I see it, either CFEclipse gets resurrected, or I will eventually
> have to purchase licenses for CFB for all of my developers. And that would
> be tragic – it’s slower, it’s way too tightly integrated, and it’s … well …
> how do I say this politely… managed by an offshore company that has no
> interest other than profit.**
> ****
> **The tools you have already developed seem to be a natural fit for the
> platform, and indeed they work amazingly well. My company isn’t large by
> any stretch, but we are more than willing to pay for tools that help us
> save time. I guess my question boils down to this – if we were willing to
> spend some money, would you be willing to spend that money on improving
> CFEclipse? And I’m not looking for proprietary work here either – any
> investment we would make, I would be perfectly happy with you guys
> reselling that effort. All that I care about is making my developers more
> efficient. I know you have consulting services, so I hope that this
> question isn’t entirely out of left-field. I’m not looking for you guys to
> reinvent a product that already works really well for us – I’m just curious
> if there are ways that we could incite you to improve an existing product
> in a mutually beneficial way.**
> **FWIW, here is the “wish list” of things we would lie to see added to
> CFE:**
> **
> • Scan the Eclipse project for CFCs . ( Add a new view that shows CFCs and
> the functions within those CFCs, based on my project root).
> o This should be a persistent view. I shouldn’t have to be working inside
> the CFC to see this.
> o Show me a list of all CFCs in the project, and all functions in those
> CFCs.
> • Support mappings for CFCs. (Let me specify that <cfinvoke
> component=”Foo.Bar” mthod=”baz”> maps to C:\InetPub\myapp\CFC\foo\bar.cfc,
> or more importantly, let me map to C:\InetPub\myapp\CFC\foo to “Foo.”).
> o This should be a persistent view. I shouldn’t have to be working inside
> the CFC to see this.
> • Provide insight for arguments-scoped and locally-scoped variables. I
> don’t need fancy handling – just let me ctrl-space the names!!!!.**
> **That’s really about it!**
> **If this is something you would at all be interested in, please let me
> know.
> **
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online:
> http://groups.google.com/group/cfeclipse-users?hl=en
I'm still keen to do some stuff, but I probably need a bit of help. I actually was playing with mark's cfedit code on fridAy. Had got as far as getting the tests running locally (had to adjust some path references), but I wasn't really sure where to go next...
Sent from my mobile
On 07/07/2012, at 11:31 PM, Mark Drew <mark.d...@gmail.com> wrote:
> Sorry for the short reply, I am currently away from my laptop. (Comic Con today! Yay!)
> But yes, it is a down time but Denny and I do have a bunch of projects to release. I am currently working on an eclipse plugin to blow thy minds.
> As a side effect of this, I am also looking at CFEclipse and all that you ask is indeed possible and I shall reply off list with some suggestions.
> Regards
> Mark Drew
> On 7 Jul 2012, at 14:01, Jim Priest <pri...@thecrumb.com> wrote:
>> Rolando - thanks for the email and the kind words for CFEclipse.
>> I honestly don't know what the current development status is.
>> Historically there have always been up and down periods of development and we're certainly in a down period lately.
>> Denny and Mark occasionally pop up here but I believe they are both heavily working on Railo 4.
>> Keep us posted if you hear anything back.
>> Jim
>> On Sat, Jul 7, 2012 at 4:30 AM, Roland Collins <rc.rules.the.unive...@gmail.com> wrote:
>> I will post the full text of an email I just sent to Integral (the awsome folks behind FusionDebug, FusionReactor, etc) after this. Please do not consider this flame bait - it's an honest question. I have actually donated a significant amount of money to CFE in the past, and I am willing to do so agan. It just seems like the project has stagnated, and I'm only looking to move it forward. If I can pay for people to work on CFE instead of having to pay Integral, I'd be more than happy to do so.
>> Yes, I know it's open source, and yes, I have downloaded the project and tried to make changes. I'm not interested in that path - I'm looking to directly fund the project to help it meet my needs, and hopefully my needs align somewhat with everyone else's.
>> Roland
>> My Email to Integral:
>> My name is Roland Collins. I’ve recently purchased FusionDebug, FusionReactor, and FusionAnalytics from you, and I could not be happier with the products you guys create. They’re truly amazing, and they have paid for themselves many times over. We’re on the cusp of getting some of our resellers to adopt your products as well. We may be a relatively small company, but we occupy a niche in the Financial Services industry with little competition. Your tools have recently been a large part of that success. There is nothing out there that compares to what you guys have built – especially at the price point.
>> Knowing that you are ColdFusion experts, I thought I would pose a question to you. Our current development environment is Eclipse (4.2), Aptana, CFEclipse, and FusionDebug. This has been an amazingly successful suite for us, even with the advent of CF10. However, it seems like CFEclipse is dead in the water at this point, even though we consider it far superior to CFBuilder. Quite frankly, we consider CFBuilder to be a joke of a product in our shop. It’s fine for small projects and “light” apps, but we have a massive ColdFusion codebase. CFEclipse is fast, reliable, and plays well with other Eclipse plugins. CFBuilder is slow, crashes all the time, and assumes that it is the only plugin that matters. To put it in perspective, we’ve been using CF as our primary application server since ’96. We have CFCs that are ~10k lines long (libraries, not OOP classes). CFB sucks at dealing with this kind of environment. CFE is close, but not perfect, although it is much better.
>> The reason I’m writing to you guys tonight is to see if you would be at all interested at some funded CFEclipse development. To put it plainly, the way I see it, either CFEclipse gets resurrected, or I will eventually have to purchase licenses for CFB for all of my developers. And that would be tragic – it’s slower, it’s way too tightly integrated, and it’s … well … how do I say this politely… managed by an offshore company that has no interest other than profit.
>> The tools you have already developed seem to be a natural fit for the platform, and indeed they work amazingly well. My company isn’t large by any stretch, but we are more than willing to pay for tools that help us save time. I guess my question boils down to this – if we were willing to spend some money, would you be willing to spend that money on improving CFEclipse? And I’m not looking for proprietary work here either – any investment we would make, I would be perfectly happy with you guys reselling that effort. All that I care about is making my developers more efficient. I know you have consulting services, so I hope that this question isn’t entirely out of left-field. I’m not looking for you guys to reinvent a product that already works really well for us – I’m just curious if there are ways that we could incite you to improve an existing product in a mutually beneficial way.
>> FWIW, here is the “wish list” of things we would lie to see added to CFE:
>> • Scan the Eclipse project for CFCs . ( Add a new view that shows CFCs and the functions within those CFCs, based on my project root).
>> o This should be a persistent view. I shouldn’t have to be working inside the CFC to see this.
>> o Show me a list of all CFCs in the project, and all functions in those CFCs.
>> • Support mappings for CFCs. (Let me specify that <cfinvoke component=”Foo.Bar” mthod=”baz”> maps to C:\InetPub\myapp\CFC\foo\bar.cfc, or more importantly, let me map to C:\InetPub\myapp\CFC\foo to “Foo.”).
>> o This should be a persistent view. I shouldn’t have to be working inside the CFC to see this.
>> • Provide insight for arguments-scoped and locally-scoped variables. I don’t need fancy handling – just let me ctrl-space the names!!!!.
>> That’s really about it!
>> If this is something you would at all be interested in, please let me know.
>> You are subscribed to the Google Groups "CFEclipse Users" group.
>> To post send email to: cfeclipse-users@googlegroups.com
>> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
>> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
>> You are subscribed to the Google Groups "CFEclipse Users" group.
>> To post send email to: cfeclipse-users@googlegroups.com
>> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
>> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en > -- > For more information on CFEclipse visit: cfeclipse.org
> For support, FAQ and tips and tricks visit: https://github.com/cfeclipse/cfeclipse/wiki
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
Here's a bit of a wishlist I put together a while ago:
- If you type a tag then </ [ctrl-space] does not suggest closing tag
- Variable scope for auto complete not respected
- Autocomplete in cfscript not implemented
- When auto close tags is turned on, you always get a new line, even
when you don't want one.
- Cannot type over auto-inserted characters like (), "", {}, etc.
- Sometimes changes case of selected function name
- Function completion doesn't work inside cfc files
Just little things but if I could even just fix these in the current
version, it'd be a nice little improvement..
On 8 July 2012 12:38, Andrew Myers <am2...@gmail.com> wrote:
> I'm still keen to do some stuff, but I probably need a bit of help. I
> actually was playing with mark's cfedit code on fridAy. Had got as far as
> getting the tests running locally (had to adjust some path references), but
> I wasn't really sure where to go next...
> Sent from my mobile
> On 07/07/2012, at 11:31 PM, Mark Drew <mark.d...@gmail.com> wrote:
> Hi,
> Sorry for the short reply, I am currently away from my laptop. (Comic Con
> today! Yay!)
> But yes, it is a down time but Denny and I do have a bunch of projects to
> release. I am currently working on an eclipse plugin to blow thy minds.
> As a side effect of this, I am also looking at CFEclipse and all that you
> ask is indeed possible and I shall reply off list with some suggestions.
> Regards
> Mark Drew
> On 7 Jul 2012, at 14:01, Jim Priest <pri...@thecrumb.com> wrote:
> Rolando - thanks for the email and the kind words for CFEclipse.
> I honestly don't know what the current development status is.
> Historically there have always been up and down periods of development and
> we're certainly in a down period lately.
> Denny and Mark occasionally pop up here but I believe they are both
> heavily working on Railo 4.
> Keep us posted if you hear anything back.
> Jim
> On Sat, Jul 7, 2012 at 4:30 AM, Roland Collins <
> rc.rules.the.unive...@gmail.com> wrote:
>> I will post the full text of an email I just sent to Integral (the awsome
>> folks behind FusionDebug, FusionReactor, etc) after this. Please do not
>> consider this flame bait - it's an honest question. I have actually
>> donated a significant amount of money to CFE in the past, and I am willing
>> to do so agan. It just seems like the project has stagnated, and I'm only
>> looking to move it forward. If I can pay for people to work on CFE instead
>> of having to pay Integral, I'd be more than happy to do so.
>> Yes, I know it's open source, and yes, I have downloaded the project and
>> tried to make changes. I'm not interested in that path - I'm looking to
>> directly fund the project to help it meet my needs, and hopefully my needs
>> align somewhat with everyone else's.
>> Roland
>> My Email to Integral:
>> ******
>> **My name is Roland Collins. I’ve recently purchased FusionDebug,
>> FusionReactor, and FusionAnalytics from you, and I could not be happier
>> with the products you guys create. They’re truly amazing, and they have
>> paid for themselves many times over. We’re on the cusp of getting some of
>> our resellers to adopt your products as well. We may be a relatively small
>> company, but we occupy a niche in the Financial Services industry with
>> little competition. Your tools have recently been a large part of that
>> success. There is nothing out there that compares to what you guys have
>> built – especially at the price point.**
>> **Knowing that you are ColdFusion experts, I thought I would pose a
>> question to you. Our current development environment is Eclipse (4.2),
>> Aptana, CFEclipse, and FusionDebug. This has been an amazingly successful
>> suite for us, even with the advent of CF10. However, it seems like
>> CFEclipse is dead in the water at this point, even though we consider it
>> far superior to CFBuilder. Quite frankly, we consider CFBuilder to be a
>> joke of a product in our shop. It’s fine for small projects and “light”
>> apps, but we have a massive ColdFusion codebase. CFEclipse is fast,
>> reliable, and plays well with other Eclipse plugins. CFBuilder is slow,
>> crashes all the time, and assumes that it is the only plugin that matters.
>> To put it in perspective, we’ve been using CF as our primary application
>> server since ’96. We have CFCs that are ~10k lines long (libraries, not
>> OOP classes). CFB sucks at dealing with this kind of environment. CFE is
>> close, but not perfect, although it is much better.**
>> ****
>> **The reason I’m writing to you guys tonight is to see if you would be
>> at all interested at some funded CFEclipse development. To put it plainly,
>> the way I see it, either CFEclipse gets resurrected, or I will eventually
>> have to purchase licenses for CFB for all of my developers. And that would
>> be tragic – it’s slower, it’s way too tightly integrated, and it’s … well …
>> how do I say this politely… managed by an offshore company that has no
>> interest other than profit.**
>> ****
>> **The tools you have already developed seem to be a natural fit for the
>> platform, and indeed they work amazingly well. My company isn’t large by
>> any stretch, but we are more than willing to pay for tools that help us
>> save time. I guess my question boils down to this – if we were willing to
>> spend some money, would you be willing to spend that money on improving
>> CFEclipse? And I’m not looking for proprietary work here either – any
>> investment we would make, I would be perfectly happy with you guys
>> reselling that effort. All that I care about is making my developers more
>> efficient. I know you have consulting services, so I hope that this
>> question isn’t entirely out of left-field. I’m not looking for you guys to
>> reinvent a product that already works really well for us – I’m just curious
>> if there are ways that we could incite you to improve an existing product
>> in a mutually beneficial way.**
>> **FWIW, here is the “wish list” of things we would lie to see added to
>> CFE:**
>> **
>> • Scan the Eclipse project for CFCs . ( Add a new view that shows CFCs
>> and the functions within those CFCs, based on my project root).
>> o This should be a persistent view. I shouldn’t have to be working
>> inside the CFC to see this.
>> o Show me a list of all CFCs in the project, and all functions in those
>> CFCs.
>> • Support mappings for CFCs. (Let me specify that <cfinvoke
>> component=”Foo.Bar” mthod=”baz”> maps to C:\InetPub\myapp\CFC\foo\bar.cfc,
>> or more importantly, let me map to C:\InetPub\myapp\CFC\foo to “Foo.”).
>> o This should be a persistent view. I shouldn’t have to be working
>> inside the CFC to see this.
>> • Provide insight for arguments-scoped and locally-scoped variables. I
>> don’t need fancy handling – just let me ctrl-space the names!!!!.**
>> **That’s really about it!**
>> **If this is something you would at all be interested in, please let me
>> know.
>> **
>> You are subscribed to the Google Groups "CFEclipse Users" group.
>> To post send email to: cfeclipse-users@googlegroups.com
>> To unsubscribe send email to:
>> cfeclipse-users+unsubscribe@googlegroups.com
>> For more options, visit this group online:
>> http://groups.google.com/group/cfeclipse-users?hl=en
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online:
> http://groups.google.com/group/cfeclipse-users?hl=en
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online:
> http://groups.google.com/group/cfeclipse-users?hl=en
I have been super swamped, and my email client is doing something odd
with my rules, so I've been missing messages ta boot.
A quick update:
"It's [still] alive!"
I've got CFE building automatedly via Buckminster, along with what
Eclipse calls a "Product", which is basically a stand-alone version of
CFE bundled with whatever plugins we want to bundle. Now that it's this
easy, we can do our goal of having various stand-alone bundles, even.
So now, if you want to wank around with the code yourself, there's a
single plugin you install that will pull the sources, and set up
everything for you (releng). This is what Buckminster uses to set up
automated builds. Buckminster is slick, and better fits our needs than
Tycho, which is also slick.
The parser code has updated tests, and is compatible with the latest
cfscript features of Railo (until we have separate parsers based on
versions and flavors, I took the easiest route-- simicolons are
required, even though Railo doesn't need them, and conversely, Railo's
"tags in script" format is supported -- ex: loop from="1" to="3"
index="i" { ... } -- so it's not perfect but theoretically shouldn't
flag valid stuff as invalid for any of the engines, and that's the side
to err on!), and there's something afoot for dictionaries as well.
The parser is also hooked up to an automated deal now, although it's
separate from the CFE automated build, as it's a stand alone project and
hopefully easier to make use of, add tests too, etc.. Simple JUnit
beats swtbot for ease of use, no question (SWTBot is set up for CFE,
although there are currently no tests-- think of swtbot as Selenium for
Eclipse).
I've talked with Marc about using a .cfmlproject type of file to store
mappings and runner paths and stuff, which will work for both CFE and
MXUnit, and there are some nice package-management types of things we
can use it for too. More on that later.
I've made MXUnit the default in the unit test creation wizard, and will
probably ditch the other two soon unless someone says they're using them
(cfunit, and I can't even remember the other-- cfcunit? Ya.).
A side-effect of automating the CFE build was that the MXUnit build got
automated as well, though I wanted to surprise Marc with that (maybe
he's not reading, and if so, "shhhhh!").
There are also minor improvements with autocomplete/"jump to function",
help from within cfscript (you don't have to select the whole function
now, etc.), and you don't have to fight to close parens ")" at least
((that was annoying), which I need to apply to {} ## "" and ''.
Hopefully within the next month I'll have this all set up somewhere
public. And then every time we commit, BANG! new build is out, tests
are run, yum yum.
:Den "Quick" Uno
-- Giving up smoking is the easiest thing in the world. I know because I've
done it thousands of times. - Mark Twain
On Fri, Jul 13, 2012 at 3:32 PM, denstar <valliants...@gmail.com> wrote:
> Hi Folks!
> I have been super swamped, and my email client is doing something odd
> with my rules, so I've been missing messages ta boot.
> A quick update:
> "It's [still] alive!"
> I've got CFE building automatedly via Buckminster, along with what
> Eclipse calls a "Product", which is basically a stand-alone version of
> CFE bundled with whatever plugins we want to bundle. Now that it's this
> easy, we can do our goal of having various stand-alone bundles, even.
> So now, if you want to wank around with the code yourself, there's a
> single plugin you install that will pull the sources, and set up
> everything for you (releng). This is what Buckminster uses to set up
> automated builds. Buckminster is slick, and better fits our needs than
> Tycho, which is also slick.
> The parser code has updated tests, and is compatible with the latest
> cfscript features of Railo (until we have separate parsers based on
> versions and flavors, I took the easiest route-- simicolons are
> required, even though Railo doesn't need them, and conversely, Railo's
> "tags in script" format is supported -- ex: loop from="1" to="3"
> index="i" { ... } -- so it's not perfect but theoretically shouldn't
> flag valid stuff as invalid for any of the engines, and that's the side
> to err on!), and there's something afoot for dictionaries as well.
> The parser is also hooked up to an automated deal now, although it's
> separate from the CFE automated build, as it's a stand alone project and
> hopefully easier to make use of, add tests too, etc.. Simple JUnit
> beats swtbot for ease of use, no question (SWTBot is set up for CFE,
> although there are currently no tests-- think of swtbot as Selenium for
> Eclipse).
> I've talked with Marc about using a .cfmlproject type of file to store
> mappings and runner paths and stuff, which will work for both CFE and
> MXUnit, and there are some nice package-management types of things we
> can use it for too. More on that later.
> I've made MXUnit the default in the unit test creation wizard, and will
> probably ditch the other two soon unless someone says they're using them
> (cfunit, and I can't even remember the other-- cfcunit? Ya.).
> A side-effect of automating the CFE build was that the MXUnit build got
> automated as well, though I wanted to surprise Marc with that (maybe
> he's not reading, and if so, "shhhhh!").
> There are also minor improvements with autocomplete/"jump to function",
> help from within cfscript (you don't have to select the whole function
> now, etc.), and you don't have to fight to close parens ")" at least
> ((that was annoying), which I need to apply to {} ## "" and ''.
> Hopefully within the next month I'll have this all set up somewhere
> public. And then every time we commit, BANG! new build is out, tests
> are run, yum yum.
> :Den "Quick" Uno
> --
> Giving up smoking is the easiest thing in the world. I know because I've
> done it thousands of times. - Mark Twain
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online:
> http://groups.google.com/group/cfeclipse-users?hl=en
Denny how would you feel about doing a brain dump session with a few of us who are interested in hacking on CFE - sort of a walk through what does what, etc so maybe a few of us could get more active?
I'd love to help but it's completely daunting to look at the codebase...
Sent from my mobile
On 14/07/2012, at 8:32 AM, denstar <valliants...@gmail.com> wrote:
> I have been super swamped, and my email client is doing something odd
> with my rules, so I've been missing messages ta boot.
> A quick update:
> "It's [still] alive!"
> I've got CFE building automatedly via Buckminster, along with what
> Eclipse calls a "Product", which is basically a stand-alone version of
> CFE bundled with whatever plugins we want to bundle. Now that it's this
> easy, we can do our goal of having various stand-alone bundles, even.
> So now, if you want to wank around with the code yourself, there's a
> single plugin you install that will pull the sources, and set up
> everything for you (releng). This is what Buckminster uses to set up
> automated builds. Buckminster is slick, and better fits our needs than
> Tycho, which is also slick.
> The parser code has updated tests, and is compatible with the latest
> cfscript features of Railo (until we have separate parsers based on
> versions and flavors, I took the easiest route-- simicolons are
> required, even though Railo doesn't need them, and conversely, Railo's
> "tags in script" format is supported -- ex: loop from="1" to="3"
> index="i" { ... } -- so it's not perfect but theoretically shouldn't
> flag valid stuff as invalid for any of the engines, and that's the side
> to err on!), and there's something afoot for dictionaries as well.
> The parser is also hooked up to an automated deal now, although it's
> separate from the CFE automated build, as it's a stand alone project and
> hopefully easier to make use of, add tests too, etc.. Simple JUnit
> beats swtbot for ease of use, no question (SWTBot is set up for CFE,
> although there are currently no tests-- think of swtbot as Selenium for
> Eclipse).
> I've talked with Marc about using a .cfmlproject type of file to store
> mappings and runner paths and stuff, which will work for both CFE and
> MXUnit, and there are some nice package-management types of things we
> can use it for too. More on that later.
> I've made MXUnit the default in the unit test creation wizard, and will
> probably ditch the other two soon unless someone says they're using them
> (cfunit, and I can't even remember the other-- cfcunit? Ya.).
> A side-effect of automating the CFE build was that the MXUnit build got
> automated as well, though I wanted to surprise Marc with that (maybe
> he's not reading, and if so, "shhhhh!").
> There are also minor improvements with autocomplete/"jump to function",
> help from within cfscript (you don't have to select the whole function
> now, etc.), and you don't have to fight to close parens ")" at least
> ((that was annoying), which I need to apply to {} ## "" and ''.
> Hopefully within the next month I'll have this all set up somewhere
> public. And then every time we commit, BANG! new build is out, tests
> are run, yum yum.
> :Den "Quick" Uno
> -- > Giving up smoking is the easiest thing in the world. I know because I've
> done it thousands of times. - Mark Twain
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
We talked about this a long time ago.... I've got a Connect account,
and can easily create a session where folks could talk, share screens,
etc ... though I'm sure there are other options out there as well -
Google +?
On Sat, Jul 14, 2012 at 9:49 PM, Andrew Myers <am2...@gmail.com> wrote:
> Denny how would you feel about doing a brain dump session with a few of us who are interested in hacking on CFE - sort of a walk through what does what, etc so maybe a few of us could get more active?
> I'd love to help but it's completely daunting to look at the codebase...
> Sent from my mobile
> On 14/07/2012, at 8:32 AM, denstar <valliants...@gmail.com> wrote:
>> Hi Folks!
>> I have been super swamped, and my email client is doing something odd
>> with my rules, so I've been missing messages ta boot.
>> A quick update:
>> "It's [still] alive!"
>> I've got CFE building automatedly via Buckminster, along with what
>> Eclipse calls a "Product", which is basically a stand-alone version of
>> CFE bundled with whatever plugins we want to bundle. Now that it's this
>> easy, we can do our goal of having various stand-alone bundles, even.
>> So now, if you want to wank around with the code yourself, there's a
>> single plugin you install that will pull the sources, and set up
>> everything for you (releng). This is what Buckminster uses to set up
>> automated builds. Buckminster is slick, and better fits our needs than
>> Tycho, which is also slick.
>> The parser code has updated tests, and is compatible with the latest
>> cfscript features of Railo (until we have separate parsers based on
>> versions and flavors, I took the easiest route-- simicolons are
>> required, even though Railo doesn't need them, and conversely, Railo's
>> "tags in script" format is supported -- ex: loop from="1" to="3"
>> index="i" { ... } -- so it's not perfect but theoretically shouldn't
>> flag valid stuff as invalid for any of the engines, and that's the side
>> to err on!), and there's something afoot for dictionaries as well.
>> The parser is also hooked up to an automated deal now, although it's
>> separate from the CFE automated build, as it's a stand alone project and
>> hopefully easier to make use of, add tests too, etc.. Simple JUnit
>> beats swtbot for ease of use, no question (SWTBot is set up for CFE,
>> although there are currently no tests-- think of swtbot as Selenium for
>> Eclipse).
>> I've talked with Marc about using a .cfmlproject type of file to store
>> mappings and runner paths and stuff, which will work for both CFE and
>> MXUnit, and there are some nice package-management types of things we
>> can use it for too. More on that later.
>> I've made MXUnit the default in the unit test creation wizard, and will
>> probably ditch the other two soon unless someone says they're using them
>> (cfunit, and I can't even remember the other-- cfcunit? Ya.).
>> A side-effect of automating the CFE build was that the MXUnit build got
>> automated as well, though I wanted to surprise Marc with that (maybe
>> he's not reading, and if so, "shhhhh!").
>> There are also minor improvements with autocomplete/"jump to function",
>> help from within cfscript (you don't have to select the whole function
>> now, etc.), and you don't have to fight to close parens ")" at least
>> ((that was annoying), which I need to apply to {} ## "" and ''.
>> Hopefully within the next month I'll have this all set up somewhere
>> public. And then every time we commit, BANG! new build is out, tests
>> are run, yum yum.
>> :Den "Quick" Uno
>> --
>> Giving up smoking is the easiest thing in the world. I know because I've
>> done it thousands of times. - Mark Twain
>> You are subscribed to the Google Groups "CFEclipse Users" group.
>> To post send email to: cfeclipse-users@googlegroups.com
>> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
>> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
> We talked about this a long time ago.... I've got a Connect account,
> and can easily create a session where folks could talk, share screens,
> etc ... though I'm sure there are other options out there as well -
> Google +?
> Jim
> On Sat, Jul 14, 2012 at 9:49 PM, Andrew Myers <am2...@gmail.com> wrote:
>> Denny how would you feel about doing a brain dump session with a few of us who are interested in hacking on CFE - sort of a walk through what does what, etc so maybe a few of us could get more active?
>> I'd love to help but it's completely daunting to look at the codebase...
>> Sent from my mobile
>> On 14/07/2012, at 8:32 AM, denstar <valliants...@gmail.com> wrote:
>>> Hi Folks!
>>> I have been super swamped, and my email client is doing something odd
>>> with my rules, so I've been missing messages ta boot.
>>> A quick update:
>>> "It's [still] alive!"
>>> I've got CFE building automatedly via Buckminster, along with what
>>> Eclipse calls a "Product", which is basically a stand-alone version of
>>> CFE bundled with whatever plugins we want to bundle. Now that it's this
>>> easy, we can do our goal of having various stand-alone bundles, even.
>>> So now, if you want to wank around with the code yourself, there's a
>>> single plugin you install that will pull the sources, and set up
>>> everything for you (releng). This is what Buckminster uses to set up
>>> automated builds. Buckminster is slick, and better fits our needs than
>>> Tycho, which is also slick.
>>> The parser code has updated tests, and is compatible with the latest
>>> cfscript features of Railo (until we have separate parsers based on
>>> versions and flavors, I took the easiest route-- simicolons are
>>> required, even though Railo doesn't need them, and conversely, Railo's
>>> "tags in script" format is supported -- ex: loop from="1" to="3"
>>> index="i" { ... } -- so it's not perfect but theoretically shouldn't
>>> flag valid stuff as invalid for any of the engines, and that's the side
>>> to err on!), and there's something afoot for dictionaries as well.
>>> The parser is also hooked up to an automated deal now, although it's
>>> separate from the CFE automated build, as it's a stand alone project and
>>> hopefully easier to make use of, add tests too, etc.. Simple JUnit
>>> beats swtbot for ease of use, no question (SWTBot is set up for CFE,
>>> although there are currently no tests-- think of swtbot as Selenium for
>>> Eclipse).
>>> I've talked with Marc about using a .cfmlproject type of file to store
>>> mappings and runner paths and stuff, which will work for both CFE and
>>> MXUnit, and there are some nice package-management types of things we
>>> can use it for too. More on that later.
>>> I've made MXUnit the default in the unit test creation wizard, and will
>>> probably ditch the other two soon unless someone says they're using them
>>> (cfunit, and I can't even remember the other-- cfcunit? Ya.).
>>> A side-effect of automating the CFE build was that the MXUnit build got
>>> automated as well, though I wanted to surprise Marc with that (maybe
>>> he's not reading, and if so, "shhhhh!").
>>> There are also minor improvements with autocomplete/"jump to function",
>>> help from within cfscript (you don't have to select the whole function
>>> now, etc.), and you don't have to fight to close parens ")" at least
>>> ((that was annoying), which I need to apply to {} ## "" and ''.
>>> Hopefully within the next month I'll have this all set up somewhere
>>> public. And then every time we commit, BANG! new build is out, tests
>>> are run, yum yum.
>>> :Den "Quick" Uno
>>> --
>>> Giving up smoking is the easiest thing in the world. I know because I've
>>> done it thousands of times. - Mark Twain
>>> You are subscribed to the Google Groups "CFEclipse Users" group.
>>> To post send email to: cfeclipse-users@googlegroups.com
>>> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
>>> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
>> You are subscribed to the Google Groups "CFEclipse Users" group.
>> To post send email to: cfeclipse-users@googlegroups.com
>> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
>> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
> You are subscribed to the Google Groups "CFEclipse Users" group.
> To post send email to: cfeclipse-users@googlegroups.com
> To unsubscribe send email to: cfeclipse-users+unsubscribe@googlegroups.com
> For more options, visit this group online: http://groups.google.com/group/cfeclipse-users?hl=en
