+0 I can't speak for maintaining the Ant scripts for the examples. I can imagine they're a PITA to maintain, and I'm certainly not about to offer to do so.
But in the context of this, I'd like to mention that I'm not a Maven user. This isn't a matter of personal preference; I do my development offline on a laptop with no network access, for various reasons involving IP and security. I typically work with local standalone servers -- mail servers, XMPP servers, database servers, etc. This means my usual method of installing a required third-party .jar is to download it on another machine, copy it over to the laptop and install it manually. This is among the reasons I rant sometimes about dependence on third-party packages: it gets troublesome to do this when dependency runs five levels deep. Reading someone saying, "Why don't you just use X?" often makes me cringe. I'm willing to believe that I'm one of a very small number of people (can it be as small as 1?) who develop this way with Camel. After all, most people would develop a Camel application in an environment more similar to their deployment environment. But I'd like to offer it as something to think about when one is inclined to say, "It's okay, our users will just use Maven anyway." Don On Fri, Jul 8, 2011 at 7:57 AM, Jon Anstey <jans...@gmail.com> wrote: > Big +1. The Ant examples were always a pain to work with because we ship > very few 3rd party libs with Camel... which meant you would need to download > many 3rd party distributions and set up several env variables before even > running... good riddance I say :) > > On Fri, Jul 8, 2011 at 5:54 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > >> Hi >> >> We have 34 examples in the Camel kit. And frankly to keep most of them >> updated to work and run with Apache Ant is a p*** in the ****. >> I would like to discuss if we should consider reducing the number of >> examples that can run with Ant? >> >> The current pain points >> - Keep Ant examples up to date is manual labor >> - Some examples dont currently work as documented in README.txt file >> - End user will have to manually download 3rd party libraries such as >> Spring, ActiveMQ, Hibernate etc. >> - End user will have to set environment variables for home, eg >> ACTIVEMQ_HOME, ASPECTJ_HOME, HIBERNATE_HOME etc. >> - Some examples have migrated and uses OpenJPA with Maven instead of >> Hibernate, and thus running with Maven vs. Ant diverts. >> >> I suggest that we remove ANT support for the more complicated examples >> where you need to download many different 3rd party projects and >> whatnot. >> We may want to keep it on a few simpler examples that we know can be >> supported. >> >> >> Sidebar >> ====== >> Now that we talk about examples. I would like to add a very simple >> hello world examples as well. >> Something we can use in the getting started guide, so people who >> download the .zip / .tar can follow a guide. >> And run the hello world example and see that Camel is up and running >> quickly. >> For example it could be based on the maven archetype that creates a >> sample project (that example which moves files using a Content Based >> Router). >> >> Then we could have this example supported by Ant and Maven. >> ===== >> >> Any thoughts? >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: cib...@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus, fusenews >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> > > > > -- > Cheers, > Jon > --------------- > FuseSource > Email: j...@fusesource.com > Web: fusesource.com > Twitter: jon_anstey > Blog: http://janstey.blogspot.com > Author of Camel in Action: http://manning.com/ibsen >
