Showing posts with label eclipse. Show all posts
Showing posts with label eclipse. Show all posts
Thursday, June 25, 2009
Railo on SVN and Team Project Sets
Finally! You can now build Railo of SVN. Unfortunately the architecture of Railo begs for some simplification but that's beside the point really I suppose. Sean Corfield has posted some directions. The directions are pretty easy to follow but thanks to Railo's architecture it requires the setup of multiple projects in eclipse, which while not over complicated it is slightly annoying. To help out the enthusiastic folks I figure I'd take this opportunity to introduce everyone to Team Project Sets in Eclipse. Team Project Sets in Eclipse make it easier to setup multiple projects and share that information with team mates or others. Whilst it does not setup as much as I'd like it does get all the projects setup and connected to SVN with a simple import. I've put a Team Project file up on my drop box account here. To use this simply download the PSF, then in Eclipse select File->Import->Team->Team Project Set. Once you import this file Eclipse will get to work connecting to SVN and downloading all the source. The only difference from Sean's directions is I placed the dependent jar's in an Eclipse project Railo-libs (which will allow for easier updates later) so when you re-add the Jars to the build path just select Add Jars instead of Add External Jars.
Thursday, August 14, 2008
Eclipse Plugin for Fusebox (re: Marc Esher's Comment)
Marc Esher, someone I've grown to call friend over the past few months, left a question in my post yesterday inquiring if Kroger would be donating an eclipse plugin for Fusebox. What Marc knows but others do not is we have built a plugin at Kroger to help kick start project start up. The plugin is a fantastic help to driving consistency and help get a project's code base off on the right foot. The short answer to Marc is no. But I didn't want to leave that sort of comment in my comment trail as that's the short answer. The longer answer goes something like this.
The plugin we have inside Kroger is pretty Kroger specific and reaches far beyond the boundaries of what Fusebox should offer/dictate, in my opinion. Beyond that it is mixed and jumbled up with a large amount of Java web app generation as well. There is also the added complexity of competitive advantage that might keep me from being able to release it. I have not asked so I am not sure where that would take me at this point. All in all the plugin would force way too many things on developers and most would probably find it's restrictions more problematic than it is worth. That being said the concept of the plugin is rather nice and I think I maybe have even mentioned to Marc at one point about making a plugin available. It would not be the Kroger plugin but instead a separate one that I build with lessons learned from inside Kroger. In fact as I think about it what I'd really like is to create a plugin that allows additions to be added, so I can use it internally as the core/seed to Kroger's plugin and externaly folks can use it as the core for Fusebox project creation or Model-Glue generation. In all honesty the plugin does little more than what a nicely written ANT task can do, it just feels cleaner and has a slightly nicer flow to it inside Eclipse. At the end of the day I am one person though and I have to make a decision on what is worked on. Personally, as I said before, I think Fusebox itself is in a happy place right now, it is stable and has reasonably good functionality. So chances are I'll probably work on things like this before picking up the core and flopping it around too much. In short no Marc Kroger's plugin as it is today will not ever be released. After some refactoring some of it, it might be release. There's still the the whole getting permission to do it that may or may not work out.
The plugin we have inside Kroger is pretty Kroger specific and reaches far beyond the boundaries of what Fusebox should offer/dictate, in my opinion. Beyond that it is mixed and jumbled up with a large amount of Java web app generation as well. There is also the added complexity of competitive advantage that might keep me from being able to release it. I have not asked so I am not sure where that would take me at this point. All in all the plugin would force way too many things on developers and most would probably find it's restrictions more problematic than it is worth. That being said the concept of the plugin is rather nice and I think I maybe have even mentioned to Marc at one point about making a plugin available. It would not be the Kroger plugin but instead a separate one that I build with lessons learned from inside Kroger. In fact as I think about it what I'd really like is to create a plugin that allows additions to be added, so I can use it internally as the core/seed to Kroger's plugin and externaly folks can use it as the core for Fusebox project creation or Model-Glue generation. In all honesty the plugin does little more than what a nicely written ANT task can do, it just feels cleaner and has a slightly nicer flow to it inside Eclipse. At the end of the day I am one person though and I have to make a decision on what is worked on. Personally, as I said before, I think Fusebox itself is in a happy place right now, it is stable and has reasonably good functionality. So chances are I'll probably work on things like this before picking up the core and flopping it around too much. In short no Marc Kroger's plugin as it is today will not ever be released. After some refactoring some of it, it might be release. There's still the the whole getting permission to do it that may or may not work out.
Sunday, May 11, 2008
Pulse2 Review
This weekend I finally got around to giving pulse2 a spin. For those that have not heard of pulse2 its an eclipse based application that does the dirty work when it comes to configuring..eclipse. I know this sounds kind of odd but that's what it is and does. Once you open pulse2 you can chose which Eclipse runtime you want, like the core + WTP, then all additional plugins in the Pulse2 catalog. Once you have chosen the plugins you want Pulse does the dirty work of downloading and resolving dependencies. If you have 2 profiles with the same plugin it will not download it twice, its smart like that. You can also save these configs as profiles and share them with others. Pulse2 in its basic form is free but as I quickly found out anything worth while really requires the freelance account and that is subscription based @ $6/month or $60/year.
My initial thought, and why it took me so long to use pulse, was meh I can do this all on my own. However, loading different profiles can be really useful. Lets say I am working on mxUnit's eclipse plugin I can load an IDE specifically geared towards plugin dev. This would be pretty different than if I was working on OpenBD's core (something else I did this weekend). I quickly learned how nice Pulse2 is and this is a perfect way to help others in the community, share my profile and anyone can use it! The problem for me comes in that you can only use plugins in Pulse2's catalog to use Pulse2 for free. Even worse some of the plugins in the catalog require a freelance account to use (Aptana and Jboss tools are the 2 biggies here). This seems crappy to me since there is not way they can keep the catalog up-to-date. A perfect example of this is mxUnit; if I want to make a profile for the average CFML developer its either without the mxUnit plugin or it is a freelance account profile.
You can always install plugins yourself and have them not managed by Pulse but again I loose the profile aspect of it. In addition to being able to add your own plugins with a freelance account you can also share configuration settings. This is really awesome since I have multiple dev computers pulse will now keep them all in sync with one another. That to me seems like the type of services that I should pay for, not the ability to manage any plugin I want, isn't that what pulse set out to do FREE to begin with? Other than my not all plugins can be managed gripe, I also had quite a few issues with Pulse2 on Leopard, invalid argument exceptions. So bad that I would repeatedly have to shut down Pulse2 and relaunch to get my profiles configured all the way. Once the profile was configured Pulse did work perfectly so it was choppy starting but overall the product worked and worked well.
At this point I am not sure the service is worth the $60/year, I know it is not much but I can already accomplish most of what the service extras do for me with source control and checking in/out my eclipse configurations. What's more my method works with more than just eclipse it works will all my dev tools. This type of functionality is in the roadmap and once that comes to fruition I think it will surely be worth the cost. I might just get the subscription now so I can help fund the project and continue to use my extra managed plugins I guess I'll make that decision in 29 days.
My initial thought, and why it took me so long to use pulse, was meh I can do this all on my own. However, loading different profiles can be really useful. Lets say I am working on mxUnit's eclipse plugin I can load an IDE specifically geared towards plugin dev. This would be pretty different than if I was working on OpenBD's core (something else I did this weekend). I quickly learned how nice Pulse2 is and this is a perfect way to help others in the community, share my profile and anyone can use it! The problem for me comes in that you can only use plugins in Pulse2's catalog to use Pulse2 for free. Even worse some of the plugins in the catalog require a freelance account to use (Aptana and Jboss tools are the 2 biggies here). This seems crappy to me since there is not way they can keep the catalog up-to-date. A perfect example of this is mxUnit; if I want to make a profile for the average CFML developer its either without the mxUnit plugin or it is a freelance account profile.
You can always install plugins yourself and have them not managed by Pulse but again I loose the profile aspect of it. In addition to being able to add your own plugins with a freelance account you can also share configuration settings. This is really awesome since I have multiple dev computers pulse will now keep them all in sync with one another. That to me seems like the type of services that I should pay for, not the ability to manage any plugin I want, isn't that what pulse set out to do FREE to begin with? Other than my not all plugins can be managed gripe, I also had quite a few issues with Pulse2 on Leopard, invalid argument exceptions. So bad that I would repeatedly have to shut down Pulse2 and relaunch to get my profiles configured all the way. Once the profile was configured Pulse did work perfectly so it was choppy starting but overall the product worked and worked well.
At this point I am not sure the service is worth the $60/year, I know it is not much but I can already accomplish most of what the service extras do for me with source control and checking in/out my eclipse configurations. What's more my method works with more than just eclipse it works will all my dev tools. This type of functionality is in the roadmap and once that comes to fruition I think it will surely be worth the cost. I might just get the subscription now so I can help fund the project and continue to use my extra managed plugins I guess I'll make that decision in 29 days.
Subscribe to:
Posts (Atom)
