ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Lucas" <greg.lu...@gmail.com>
Subject Re: build failed in trunk - I wish we had maven
Date Wed, 09 Dec 2009 23:23:24 GMT
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  

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 <kurt.stam@gmail.com>  

> 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 <midon@intalio.com> wrote:
>>> Hi Jeff,
>>> What are your pain points?

View raw message