You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Kurt T Stam <ku...@gmail.com> on 2009/12/03 14:53:16 UTC
Re: build failed in trunk - I wish we had maven
Tammo van Lessen wrote:
> On 03.12.2009 14:41, Jeff Yu wrote:
>
>> Hi Tammo,
>>
>> It WORKS great with buildr 1.3.4. ;-)
>>
>> Do you know any reason that why I would get 'segmentation fault' against
>> JDK1.6? I am seeing this quite frequently, but just for 1.3.5, I believe it
>> is same for buildr 1.2.10
>>
>
> No, sorry. I had them a year ago on a linux machine. I though that it
> was related to the ruby-java bridge, but that's just wild guessing.
> Using JRuby might help.
>
> Tammo
>
>
Yeah I believe the issue is mixing the bit (32/64) versions between ruby
and java. I have it all working on my machine - and have given it 6
months to get used to - but have to say I'm not a huge fan of using
ruby and buildr. It's a very fragile setup, and it increases the number
of links in the chain. I think 20% of all msgs on the user/dev list are
about this particular issue..
my 2 cents
--Kurt
Re: Maven Build system design (was Re: build failed in trunk - I wish
we had maven)
Posted by Jeff Yu <je...@gmail.com>.
Daniel Dominguez has finished 6 modules, great work, lets keep going... ;)
-Jeff
On Wed, Dec 16, 2009 at 10:37 PM, Kurt T Stam <ku...@gmail.com> wrote:
> Thanks Jeff,
>
> Let's make sure we keep the wiki page update so that we document what
> build functionality each module has. This should make it easier to keep the
> two build systems in sync.
>
> Also let's try to get our feature wishes in, so we can agree on the needs
> we are trying to solve for.
>
> --Kurt
>
>
> Jeff Yu wrote:
>
>> FYI, I've already started working on this task.
>>
>> Currently finished the parent (project pom), utils, jacob-ap, jacob. and
>> working on the bpel-schema at the moment.
>> If you started working on a module, it is better that you update the wiki,
>> or follow up this thread to say which module you are working on, so that
>> you
>> won't double our efforts. ;-)
>>
>> Regards
>> Jeff
>>
>> On Tue, Dec 15, 2009 at 1:46 AM, Kurt T Stam <ku...@gmail.com> wrote:
>>
>>
>>> I created a new page:
>>> http://wiki.apache.org/ode/MavenBuildDesignApacheODE
>>> .
>>>
>>> Cheers,
>>>
>>> --Kurt
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
--
Cheers,
Jeff Yu
----------------
blog: http://jeff.familyyu.net
Re: Maven Build system design (was Re: build failed in trunk - I
wish we had maven)
Posted by Kurt T Stam <ku...@gmail.com>.
Thanks Jeff,
Let's make sure we keep the wiki page update so that we document what
build functionality each module has. This should make it easier to keep
the two build systems in sync.
Also let's try to get our feature wishes in, so we can agree on the
needs we are trying to solve for.
--Kurt
Jeff Yu wrote:
> FYI, I've already started working on this task.
>
> Currently finished the parent (project pom), utils, jacob-ap, jacob. and
> working on the bpel-schema at the moment.
> If you started working on a module, it is better that you update the wiki,
> or follow up this thread to say which module you are working on, so that you
> won't double our efforts. ;-)
>
> Regards
> Jeff
>
> On Tue, Dec 15, 2009 at 1:46 AM, Kurt T Stam <ku...@gmail.com> wrote:
>
>> I created a new page: http://wiki.apache.org/ode/MavenBuildDesignApacheODE
>> .
>>
>> Cheers,
>>
>> --Kurt
>>
>>
>>
>
>
Re: Maven Build system design (was Re: build failed in trunk - I wish
we had maven)
Posted by Jeff Yu <je...@gmail.com>.
FYI, I've already started working on this task.
Currently finished the parent (project pom), utils, jacob-ap, jacob. and
working on the bpel-schema at the moment.
If you started working on a module, it is better that you update the wiki,
or follow up this thread to say which module you are working on, so that you
won't double our efforts. ;-)
Regards
Jeff
On Tue, Dec 15, 2009 at 1:46 AM, Kurt T Stam <ku...@gmail.com> wrote:
>
>
> I created a new page: http://wiki.apache.org/ode/MavenBuildDesignApacheODE
> .
>
> Cheers,
>
> --Kurt
>
>
--
Cheers,
Jeff Yu
----------------
blog: http://jeff.familyyu.net
Re: Maven Build system design (was Re: build failed in trunk - I
wish we had maven)
Posted by Kurt T Stam <ku...@gmail.com>.
Thanks Matthieu,
I created a new page: http://wiki.apache.org/ode/MavenBuildDesignApacheODE.
Cheers,
--Kurt
(reply all this time!)
Matthieu Riou wrote:
> On Sun, Dec 13, 2009 at 11:20 AM, Kurt T Stam <kurt.stam@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi guys,
>
> I have created a wiki page where we can discuss the build design.
> Do we have a wiki for ODE?
>
>
> We do, there's a Confluence committer-only one for the site (as it
> gets live every night) but there's also a MoinMoin instance that's
> open to all, you just need to signup:
>
> http://wiki.apache.org/ode/
>
> Somewhat outdated but should be good enough for the purpose of
> creating isolated pages. It could use some cleanup as well anyhow. I'd
> rather avoid wiki fragmentation with some pages being at Apache and
> others being at JBoss.
>
> Thanks,
> Matthieu
>
>
> I was not able to find it, so I created this one for now:
> http://community.jboss.org/wiki/MavenBuildDesignApacheODE. I'm
> thinking we target the ODE-2.0 trunk? We can always decide to port
> back to ODE-1.3.x once things are working?
>
> What do you think about using this thread to discuss and then add
> to the wiki page as we go along? As Jeff mentioned in
> http://issues.apache.org/jira/browse/ODE-729 We now have a branch
> with the latest ODE code: the work branch is hosted at:
> http://anonsvn.jboss.org/repos/riftsaw/branches/ODE/ODE-2.0-maven/
> or https://svn.jboss.org/repos/riftsaw/branches/ODE/ODE-2.0-maven/
> (for committers). Looks like we have Jeff, Daniel, Greg and myself
> who are interested to work on this. Rafal I heard from Jeff you
> where interested also? Anyway if anyone else would like to give a
> hand on this, please feel free to join in.
>
> I think we should map out what artifacts are created in each
> module, and map out how the rakefile would map to a maven based
> build. IMO we should try to keep it as simple as possible as to
> make it very straightforward to maintain it, and we should
> document the build process as we go along.
>
> Opening the floor for further discussion..
>
> Cheers,
>
> --Kurt
>
>
> Kurt T Stam wrote:
>
> Sounds good, I'll talk to Jeff, Greg and whoever else is
> interested, and see if we can work on this together. Since
> neither one of us has commit rights yet, we may just work on a
> copy of the ODE-2.0 trunk in the Riftsaw SVN until things
> start working, and we can then supply the patch back.
>
> --Kurt
>
> Alexis Midon wrote:
>
> As a developer, my experiences with Maven were painful and
> time consuming.
> Maven gets in your way anytime you need to do a task as
> simple as moving a
> file, assuming you find a plugin for it. If you don't,
> well, you have to
> write some ant tasks or your own plugin... where a simple
> ruby line or a
> nicely integrated Rake task does the job.
> As an ODE developer, I enjoy not to have to deal with xml
> files all over the
> place, plugin release management, transitive dependencies.
> And I love fast,
> repeatable and consistent builds. Personal tastes I guess...
>
> Anyway we could discuss endlessly about Maven pros and cons :)
> If you guys want to contribute a Maven build, that's fine.
> Your pom's will
> be much welcomed. You could imagine having both as long as
> it does not break
> the current build and that we have people to maintain them.
>
>
> On Wed, Dec 9, 2009 at 3:23 PM, Greg Lucas
> <greg.lucas@gmail.com <ma...@gmail.com>> wrote:
>
>
>
> 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
> <kurt.stam@gmail.com <ma...@gmail.com>>
> 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
> <midon@intalio.com <ma...@intalio.com>>
> wrote:
>
>
> Hi Jeff,
>
>
> What are your pain points?
>
>
>
>
>
>
>
>
>
Re: Maven Build system design (was Re: build failed in trunk - I wish
we had maven)
Posted by Matthieu Riou <ma...@gmail.com>.
On Sun, Dec 13, 2009 at 11:20 AM, Kurt T Stam <ku...@gmail.com> wrote:
> Hi guys,
>
> I have created a wiki page where we can discuss the build design. Do we
> have a wiki for ODE?
We do, there's a Confluence committer-only one for the site (as it gets live
every night) but there's also a MoinMoin instance that's open to all, you
just need to signup:
http://wiki.apache.org/ode/
Somewhat outdated but should be good enough for the purpose of creating
isolated pages. It could use some cleanup as well anyhow. I'd rather avoid
wiki fragmentation with some pages being at Apache and others being at
JBoss.
Thanks,
Matthieu
> I was not able to find it, so I created this one for now:
> http://community.jboss.org/wiki/MavenBuildDesignApacheODE. I'm thinking we
> target the ODE-2.0 trunk? We can always decide to port back to ODE-1.3.x
> once things are working?
>
> What do you think about using this thread to discuss and then add to the
> wiki page as we go along? As Jeff mentioned in
> http://issues.apache.org/jira/browse/ODE-729 We now have a branch with the
> latest ODE code: the work branch is hosted at:
> http://anonsvn.jboss.org/repos/riftsaw/branches/ODE/ODE-2.0-maven/ or
> https://svn.jboss.org/repos/riftsaw/branches/ODE/ODE-2.0-maven/ (for
> committers). Looks like we have Jeff, Daniel, Greg and myself who are
> interested to work on this. Rafal I heard from Jeff you where interested
> also? Anyway if anyone else would like to give a hand on this, please feel
> free to join in.
>
> I think we should map out what artifacts are created in each module, and
> map out how the rakefile would map to a maven based build. IMO we should try
> to keep it as simple as possible as to make it very straightforward to
> maintain it, and we should document the build process as we go along.
>
> Opening the floor for further discussion..
>
> Cheers,
>
> --Kurt
>
>
> Kurt T Stam wrote:
>
>> Sounds good, I'll talk to Jeff, Greg and whoever else is interested, and
>> see if we can work on this together. Since neither one of us has commit
>> rights yet, we may just work on a copy of the ODE-2.0 trunk in the Riftsaw
>> SVN until things start working, and we can then supply the patch back.
>>
>> --Kurt
>>
>> Alexis Midon wrote:
>>
>>> As a developer, my experiences with Maven were painful and time
>>> consuming.
>>> Maven gets in your way anytime you need to do a task as simple as moving
>>> a
>>> file, assuming you find a plugin for it. If you don't, well, you have to
>>> write some ant tasks or your own plugin... where a simple ruby line or a
>>> nicely integrated Rake task does the job.
>>> As an ODE developer, I enjoy not to have to deal with xml files all over
>>> the
>>> place, plugin release management, transitive dependencies. And I love
>>> fast,
>>> repeatable and consistent builds. Personal tastes I guess...
>>>
>>> Anyway we could discuss endlessly about Maven pros and cons :)
>>> If you guys want to contribute a Maven build, that's fine. Your pom's
>>> will
>>> be much welcomed. You could imagine having both as long as it does not
>>> break
>>> the current build and that we have people to maintain them.
>>>
>>>
>>> On Wed, Dec 9, 2009 at 3:23 PM, Greg Lucas <gr...@gmail.com> wrote:
>>>
>>>
>>>
>>>> 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 <ku...@gmail.com>
>>>> 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 <mi...@intalio.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Jeff,
>>>>>>
>>>>>>
>>>>>>> What are your pain points?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>>
>>
>>
>
Maven Build system design (was Re: build failed in trunk - I wish
we had maven)
Posted by Kurt T Stam <ku...@gmail.com>.
Hi guys,
I have created a wiki page where we can discuss the build design. Do we
have a wiki for ODE? I was not able to find it, so I created this one
for now: http://community.jboss.org/wiki/MavenBuildDesignApacheODE. I'm
thinking we target the ODE-2.0 trunk? We can always decide to port back
to ODE-1.3.x once things are working?
What do you think about using this thread to discuss and then add to the
wiki page as we go along? As Jeff mentioned in
http://issues.apache.org/jira/browse/ODE-729 We now have a branch with
the latest ODE code: the work branch is hosted at:
http://anonsvn.jboss.org/repos/riftsaw/branches/ODE/ODE-2.0-maven/ or
https://svn.jboss.org/repos/riftsaw/branches/ODE/ODE-2.0-maven/ (for
committers). Looks like we have Jeff, Daniel, Greg and myself who are
interested to work on this. Rafal I heard from Jeff you where interested
also? Anyway if anyone else would like to give a hand on this, please
feel free to join in.
I think we should map out what artifacts are created in each module, and
map out how the rakefile would map to a maven based build. IMO we should
try to keep it as simple as possible as to make it very straightforward
to maintain it, and we should document the build process as we go along.
Opening the floor for further discussion..
Cheers,
--Kurt
Kurt T Stam wrote:
> Sounds good, I'll talk to Jeff, Greg and whoever else is interested,
> and see if we can work on this together. Since neither one of us has
> commit rights yet, we may just work on a copy of the ODE-2.0 trunk in
> the Riftsaw SVN until things start working, and we can then supply the
> patch back.
>
> --Kurt
>
> Alexis Midon wrote:
>> As a developer, my experiences with Maven were painful and time consuming.
>> Maven gets in your way anytime you need to do a task as simple as moving a
>> file, assuming you find a plugin for it. If you don't, well, you have to
>> write some ant tasks or your own plugin... where a simple ruby line or a
>> nicely integrated Rake task does the job.
>> As an ODE developer, I enjoy not to have to deal with xml files all over the
>> place, plugin release management, transitive dependencies. And I love fast,
>> repeatable and consistent builds. Personal tastes I guess...
>>
>> Anyway we could discuss endlessly about Maven pros and cons :)
>> If you guys want to contribute a Maven build, that's fine. Your pom's will
>> be much welcomed. You could imagine having both as long as it does not break
>> the current build and that we have people to maintain them.
>>
>>
>> On Wed, Dec 9, 2009 at 3:23 PM, Greg Lucas <gr...@gmail.com> wrote:
>>
>>
>>> 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 <ku...@gmail.com>
>>> 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 <mi...@intalio.com> wrote:
>>>>>
>>>>>
>>>>> Hi Jeff,
>>>>>
>>>>>> What are your pain points?
>>>>>>
>>>>>>
>>
>>
>
Re: build failed in trunk - I wish we had maven
Posted by Kurt T Stam <ku...@gmail.com>.
Sounds good, I'll talk to Jeff, Greg and whoever else is interested, and
see if we can work on this together. Since neither one of us has commit
rights yet, we may just work on a copy of the ODE-2.0 trunk in the
Riftsaw SVN until things start working, and we can then supply the patch
back.
--Kurt
Alexis Midon wrote:
> As a developer, my experiences with Maven were painful and time consuming.
> Maven gets in your way anytime you need to do a task as simple as moving a
> file, assuming you find a plugin for it. If you don't, well, you have to
> write some ant tasks or your own plugin... where a simple ruby line or a
> nicely integrated Rake task does the job.
> As an ODE developer, I enjoy not to have to deal with xml files all over the
> place, plugin release management, transitive dependencies. And I love fast,
> repeatable and consistent builds. Personal tastes I guess...
>
> Anyway we could discuss endlessly about Maven pros and cons :)
> If you guys want to contribute a Maven build, that's fine. Your pom's will
> be much welcomed. You could imagine having both as long as it does not break
> the current build and that we have people to maintain them.
>
>
> On Wed, Dec 9, 2009 at 3:23 PM, Greg Lucas <gr...@gmail.com> wrote:
>
>
>> 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 <ku...@gmail.com>
>> 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 <mi...@intalio.com> wrote:
>>>>
>>>>
>>>> Hi Jeff,
>>>>
>>>>> What are your pain points?
>>>>>
>>>>>
>
>
Re: build failed in trunk - I wish we had maven
Posted by Alexis Midon <al...@gmail.com>.
As a developer, my experiences with Maven were painful and time consuming.
Maven gets in your way anytime you need to do a task as simple as moving a
file, assuming you find a plugin for it. If you don't, well, you have to
write some ant tasks or your own plugin... where a simple ruby line or a
nicely integrated Rake task does the job.
As an ODE developer, I enjoy not to have to deal with xml files all over the
place, plugin release management, transitive dependencies. And I love fast,
repeatable and consistent builds. Personal tastes I guess...
Anyway we could discuss endlessly about Maven pros and cons :)
If you guys want to contribute a Maven build, that's fine. Your pom's will
be much welcomed. You could imagine having both as long as it does not break
the current build and that we have people to maintain them.
On Wed, Dec 9, 2009 at 3:23 PM, Greg Lucas <gr...@gmail.com> wrote:
> 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 <ku...@gmail.com>
> 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 <mi...@intalio.com> wrote:
>>>
>>>
>>> Hi Jeff,
>>>>
>>>> What are your pain points?
>>>>
>>>
RE: build failed in trunk - I wish we had maven
Posted by "Nowakowski, Mateusz" <Ma...@sabre-holdings.com>.
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:greg.lucas@gmail.com]
> Sent: Thursday, December 10, 2009 12:23 AM
> To: dev@ode.apache.org
> 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 <ku...@gmail.com>
> 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 <mi...@intalio.com>
> wrote:
> >>
> >>
> >>> Hi Jeff,
> >>>
> >>> What are your pain points?
Re: build failed in trunk - I wish we had maven
Posted by Greg Lucas <gr...@gmail.com>.
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 <ku...@gmail.com>
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 <mi...@intalio.com> wrote:
>>
>>
>>> Hi Jeff,
>>>
>>> What are your pain points?
Re: build failed in trunk - I wish we had maven
Posted by Kurt T Stam <ku...@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 <mi...@intalio.com> wrote:
>
>
>> Hi Jeff,
>>
>> What are your pain points?
>>
>>
>
> see my above
>
>
>
>> how does your task look like? Do you know you can easily reuse Ant tasks
>> from Buildr?
>>
>>
>
> I belive my task would be like the openjpa.rb, one thing I need to
> understand is do I need to put my *.rb into the buildr's addon directory? or
> where should I put? sorry if it sounds obvious. I knew it last time when I
> work on the buidr with my maven snapshot repo. I didn't try it this time as
> I want to do it like what openjpa.rb or hibernate.rb did now. But I will try
> it again some time.
>
>
>
>
>> see $ode/tasks/derby.rake for instance.
>>
>> The learning might feel steep but once you passed that point, you'll see
>> how
>> crazy it is to write Maven plugins.
>>
>>
>
> It seems that I didn't pass that point yet. :(
>
> -Jeff
>
>
>
>
>> Alexis
>>
>> On Thu, Dec 3, 2009 at 6:37 AM, Jeff Yu <je...@gmail.com> wrote:
>>
>>
>>> +1.
>>>
>>> It really adds a steep learning curve for newcomers to contribute to ODE.
>>>
>> I
>>
>>> don't know how long it will take me to write the task to use Hibernate
>>> builtin tool to generate ddl from the JPA's annotation. :-(, wish someone
>>> else could help me on this task.
>>>
>>> -Jeff
>>>
>>> On Thu, Dec 3, 2009 at 9:53 PM, Kurt T Stam <ku...@gmail.com> wrote:
>>>
>>>
>>>> Tammo van Lessen wrote:
>>>>
>>>>
>>>>> On 03.12.2009 14:41, Jeff Yu wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi Tammo,
>>>>>>
>>>>>> It WORKS great with buildr 1.3.4. ;-)
>>>>>>
>>>>>> Do you know any reason that why I would get 'segmentation fault'
>>>>>>
>>> against
>>>
>>>>>> JDK1.6? I am seeing this quite frequently, but just for 1.3.5, I
>>>>>>
>>> believe
>>>
>>>>>> it
>>>>>> is same for buildr 1.2.10
>>>>>>
>>>>>>
>>>>>>
>>>>> No, sorry. I had them a year ago on a linux machine. I though that it
>>>>> was related to the ruby-java bridge, but that's just wild guessing.
>>>>> Using JRuby might help.
>>>>>
>>>>> Tammo
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Yeah I believe the issue is mixing the bit (32/64) versions between
>>>>
>> ruby
>>
>>>> and java. I have it all working on my machine - and have given it 6
>>>>
>>> months
>>>
>>>> to get used to - but have to say I'm not a huge fan of using ruby and
>>>> buildr. It's a very fragile setup, and it increases the number of links
>>>>
>>> in
>>>
>>>> the chain. I think 20% of all msgs on the user/dev list are about this
>>>> particular issue..
>>>>
>>>> my 2 cents
>>>>
>>>> --Kurt
>>>>
>>>>
>
>
>
>
Re: build failed in trunk - I wish we had maven
Posted by Jeff Yu <je...@gmail.com>.
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 <mi...@intalio.com> wrote:
> Hi Jeff,
>
> What are your pain points?
>
see my above
> how does your task look like? Do you know you can easily reuse Ant tasks
> from Buildr?
>
I belive my task would be like the openjpa.rb, one thing I need to
understand is do I need to put my *.rb into the buildr's addon directory? or
where should I put? sorry if it sounds obvious. I knew it last time when I
work on the buidr with my maven snapshot repo. I didn't try it this time as
I want to do it like what openjpa.rb or hibernate.rb did now. But I will try
it again some time.
> see $ode/tasks/derby.rake for instance.
>
> The learning might feel steep but once you passed that point, you'll see
> how
> crazy it is to write Maven plugins.
>
It seems that I didn't pass that point yet. :(
-Jeff
>
> Alexis
>
> On Thu, Dec 3, 2009 at 6:37 AM, Jeff Yu <je...@gmail.com> wrote:
>
> > +1.
> >
> > It really adds a steep learning curve for newcomers to contribute to ODE.
> I
> > don't know how long it will take me to write the task to use Hibernate
> > builtin tool to generate ddl from the JPA's annotation. :-(, wish someone
> > else could help me on this task.
> >
> > -Jeff
> >
> > On Thu, Dec 3, 2009 at 9:53 PM, Kurt T Stam <ku...@gmail.com> wrote:
> >
> > > Tammo van Lessen wrote:
> > >
> > >> On 03.12.2009 14:41, Jeff Yu wrote:
> > >>
> > >>
> > >>> Hi Tammo,
> > >>>
> > >>> It WORKS great with buildr 1.3.4. ;-)
> > >>>
> > >>> Do you know any reason that why I would get 'segmentation fault'
> > against
> > >>> JDK1.6? I am seeing this quite frequently, but just for 1.3.5, I
> > believe
> > >>> it
> > >>> is same for buildr 1.2.10
> > >>>
> > >>>
> > >>
> > >> No, sorry. I had them a year ago on a linux machine. I though that it
> > >> was related to the ruby-java bridge, but that's just wild guessing.
> > >> Using JRuby might help.
> > >>
> > >> Tammo
> > >>
> > >>
> > >>
> > > Yeah I believe the issue is mixing the bit (32/64) versions between
> ruby
> > > and java. I have it all working on my machine - and have given it 6
> > months
> > > to get used to - but have to say I'm not a huge fan of using ruby and
> > > buildr. It's a very fragile setup, and it increases the number of links
> > in
> > > the chain. I think 20% of all msgs on the user/dev list are about this
> > > particular issue..
> > >
> > > my 2 cents
> > >
> > > --Kurt
> > >
> >
>
--
Cheers,
Jeff Yu
----------------
blog: http://jeff.familyyu.net
twitter: http://www.twitter.com/jeffyuchang
Re: build failed in trunk - I wish we had maven
Posted by Alexis Midon <mi...@intalio.com>.
Hi Jeff,
What are your pain points?
how does your task look like? Do you know you can easily reuse Ant tasks
from Buildr?
see $ode/tasks/derby.rake for instance.
The learning might feel steep but once you passed that point, you'll see how
crazy it is to write Maven plugins.
Alexis
On Thu, Dec 3, 2009 at 6:37 AM, Jeff Yu <je...@gmail.com> wrote:
> +1.
>
> It really adds a steep learning curve for newcomers to contribute to ODE. I
> don't know how long it will take me to write the task to use Hibernate
> builtin tool to generate ddl from the JPA's annotation. :-(, wish someone
> else could help me on this task.
>
> -Jeff
>
> On Thu, Dec 3, 2009 at 9:53 PM, Kurt T Stam <ku...@gmail.com> wrote:
>
> > Tammo van Lessen wrote:
> >
> >> On 03.12.2009 14:41, Jeff Yu wrote:
> >>
> >>
> >>> Hi Tammo,
> >>>
> >>> It WORKS great with buildr 1.3.4. ;-)
> >>>
> >>> Do you know any reason that why I would get 'segmentation fault'
> against
> >>> JDK1.6? I am seeing this quite frequently, but just for 1.3.5, I
> believe
> >>> it
> >>> is same for buildr 1.2.10
> >>>
> >>>
> >>
> >> No, sorry. I had them a year ago on a linux machine. I though that it
> >> was related to the ruby-java bridge, but that's just wild guessing.
> >> Using JRuby might help.
> >>
> >> Tammo
> >>
> >>
> >>
> > Yeah I believe the issue is mixing the bit (32/64) versions between ruby
> > and java. I have it all working on my machine - and have given it 6
> months
> > to get used to - but have to say I'm not a huge fan of using ruby and
> > buildr. It's a very fragile setup, and it increases the number of links
> in
> > the chain. I think 20% of all msgs on the user/dev list are about this
> > particular issue..
> >
> > my 2 cents
> >
> > --Kurt
> >
>
Re: build failed in trunk - I wish we had maven
Posted by Jeff Yu <je...@gmail.com>.
+1.
It really adds a steep learning curve for newcomers to contribute to ODE. I
don't know how long it will take me to write the task to use Hibernate
builtin tool to generate ddl from the JPA's annotation. :-(, wish someone
else could help me on this task.
-Jeff
On Thu, Dec 3, 2009 at 9:53 PM, Kurt T Stam <ku...@gmail.com> wrote:
> Tammo van Lessen wrote:
>
>> On 03.12.2009 14:41, Jeff Yu wrote:
>>
>>
>>> Hi Tammo,
>>>
>>> It WORKS great with buildr 1.3.4. ;-)
>>>
>>> Do you know any reason that why I would get 'segmentation fault' against
>>> JDK1.6? I am seeing this quite frequently, but just for 1.3.5, I believe
>>> it
>>> is same for buildr 1.2.10
>>>
>>>
>>
>> No, sorry. I had them a year ago on a linux machine. I though that it
>> was related to the ruby-java bridge, but that's just wild guessing.
>> Using JRuby might help.
>>
>> Tammo
>>
>>
>>
> Yeah I believe the issue is mixing the bit (32/64) versions between ruby
> and java. I have it all working on my machine - and have given it 6 months
> to get used to - but have to say I'm not a huge fan of using ruby and
> buildr. It's a very fragile setup, and it increases the number of links in
> the chain. I think 20% of all msgs on the user/dev list are about this
> particular issue..
>
> my 2 cents
>
> --Kurt
>