Great email Greg! I sign under each line of the email.
This is a great idea. -- Regards Mateusz Nowakowski > -----Original Message----- > From: Greg Lucas [mailto:[email protected]] > Sent: Thursday, December 10, 2009 12:23 AM > To: [email protected] > Subject: Re: build failed in trunk - I wish we had maven > > My concerns are related to the general adoption of Maven and the > growing > set of tools that support it. I would suspect that: > > - ODE developers and users are working with multiple projects. > > - Many (most?) potential ODE developers/users are already using > maven; or > are investing in it because of other projects. > > - Some of those potential developers/users have no prior experience > with > Ruby and no other requirement to invest in it. > > > My specific scenario involves adding ODE to an existing environment > that > is used to build/test multiple projects (Apache and otherwise - > including > Karaf, ServiceMix, CXF, Camel, etc). All of these projects have Maven2 > builds. The incremental cost of adding a new maven-based project to the > environment is substantially lower than adding something new. I have > seen > customers maintaining similar environments to build open-source and > in-house projects, so this is not unique. > > > Some pain points: > > 1. Getting ruby/buildr running builds/tests on multiple platforms and > JVMs > (Win/Linux/Unix, 32/64-bit, JDK 1.5/1.6, etc) > > When I started looking at this ODE 1.x required native ruby (installed > & > compiled for various platforms) and buildr 1.2.10. I had numerous > issues > getting that to work - the buildr gem wouldn't install because of > circular > dependencies, the build failed to run with jdk 1.6, etc. Getting the > 1.x > and trunk branches on the latest buildr version helps, as does using > jruby > (although I have an sftp upload issue with jruby). > > 2. Releases that span multiple projects need to ensure consistent > 3rd-party dependencies. > > Representing dependencies with a common model is required to do any > meaningful cross-project validation. I'd echo Kurt's point that > projects > that want to consume ODE artifacts are more likely to know the pom > model. > While creating the OSGi bundle for the JBI component I used svn blame > to > figure out why some transitive dependencies were being used (some no > longer necessary), rather than simply being able to view the dependency > tree. > > Eclipse and IntelliJ understand poms and make it easy to import maven > projects. Buildr can generate IDE-specific projects, but it's not quite > the same: in IntelliJ I can also grab the pom for a dependency, create > a > module, and start building against that module rather than the jar in > my > local repo. > > 3. There are many existing plugins and tools to solve common problems > > For example adding an OSGi bundle for ODE could use the > maven-bundle-plugin which leverages the maven dependency model to do > things that bnd does not - e.g. dealing with test and provided scopes. > Having direct access to Ruby provides lots of flexibility, but in many > cases I'd rather use an existing stable tool than write my own. > > > Individual concerns can be addressed, I'm happy to learn more ruby and > contribute to buildr. But my overall experience so far has been > spending > just as much time with the build system as with ODE itself - effort > toward > a likely result of one project out of many that uses its own dev > infrastructure and requires continual special-case handling. > > > On Wed, 09 Dec 2009 10:54:40 -0500, Kurt T Stam <[email protected]> > wrote: > > > I was going to comment on http://issues.apache.org/jira/browse/ODE- > 729, > > but I think having discussions > > on the mailing list works better then in jira. So I'm going to add > this > > thread and add 2 more pain-points > > > > 1. There can be issues between ruby and java if somehow the bit > versions > > used are out of sync (32 vs 64 bit). It simply blows up without much > > detail as to what happened. So much easier to use 1 environment > (java). > > Yeah I know you will tell me to use jruby. > > > > 2. Adhereing to an Apache standard build tool and environment. Maven > > forces a common layout, build and release process. > > > > 3. Tooling support. I can get my IDE setup easily using a maven- > eclipse > > plugin. > > > > 4. Dependency management. Projects that consume ODE (i.e. Riftsaw) > need > > to know the dependency, compile, runtime and test. Maven does this > for > > me and it makes it easy for me to display it, again though plugins > into > > my IDE. > > > > 5. I have a hard time running multiple buildr versions. I have 1.2.10 > > working now, but as soon as I also install 1.3.x, then 1.2.10 breaks > as > > some gem dependency gets skrewed up. Which forces me to painstakingly > > remove gems until 1.2.10 works again. > > > > 6. I like a minimal build; have it just work, by convention of the > > layout of the project, maven done right does not 'get-in-the-way', > and I > > only have to worry about bugs in one build tool; not in two. > > > > 7. Check the mailing list to see how many people having issues > getting > > their build going. > > > > thx, > > > > --Kurt > > > > > > Jeff Yu wrote: > >> here are couple issues that I had (before I talked about my current > >> task) > >> > >> 1. I knew buildr is quite new, but the adoption is really an issue. > The > >> adoption means the plugins, and the work that I need to do. I > remembered > >> that one task that I was working on is to try to push the artifacts > into > >> maven snapshot repository, which is webdav protocol. Simply I just > >> couldn't > >> find a 'just works' plugin for me to do so. In the end, I used the > >> maven-ant-task to do the publish, as I had a problem by using buildr > >> against > >> our repo, I tried the way as Alex Boisvert pointed out in buildr > >> maillist, > >> couldn't work against our repo, quite frustrating. > >> > >> 2. It requires developer to learn Ruby. I know it sounds interesting > to > >> learn a new language, but sometimes I just want to make my build > system > >> just > >> works and easily been understood. > >> > >> 3. It also depends on specific library version. If you go to the > >> .gem/ruby/1.8/gems/buildr-1.3.5/addon/buildr directory, take > >> xmlbeans.rb as > >> an example, it depends on a specific xmlbeans version, what if I > used a > >> different version in my own project, does it require me to update > this > >> to > >> make these version consistent. same goes to the hibernate.rb etc. > >> > >> 4. Don't have enough documentation for how to write an addon, how > did > >> the > >> buildr work underlie, like I still didn't understand in the > >> dao-hibernate > >> module, how the mvn-hibernate.xml was used when I run 'buildr > publish'. > >> > >> ..... > >> > >> other comments inline. > >> > >> On Wed, Dec 9, 2009 at 9:12 AM, Alexis Midon <[email protected]> > wrote: > >> > >> > >>> Hi Jeff, > >>> > >>> What are your pain points?
