>
> all these linux distributions are about dependency management. and
> when building a package there needs to be all dependent "libraries"
> already available and installed. it seems rather difficult to adopt
> the ant script in a way that ant builds from the packages of the
> distribution rather then the jars files from the code repository. dito
> is probably true for maven. but most big linux distributions can
> provide ant and maven more or less up-to-date.
>
From a gentoo perspective we find ant to be orders of magnitude easier to
handle than maven. In fact we have NO ebuilds that build packages using maven
directly. There are ones that use the build.xml files from mvn ant:ant but a
lot of the time even that isn't good enough.
I don't want to go into this in too much detail but sadly unlike (a lot of)
C/C++ developers, java developers do not package their projects in a way that
makes them easy to package on linux. I believe there is just this
expectation that java apps will just be untarred and run, therefore they need
all their deps, they are jarjar them, unzip and combine/patch before rejaring.
Maybe it is just that gentoo requires everything being built from source and
it is actually easier to do on binary distro's. I would still believe that
they would have issues tho.
> next issue I see with buildr. none of the distributions I know have
> any buildr package.
>
> and the big thing is the dependency management. and "assume" buildr is
> a better maven it does a lot of dependency management and here things
> become tricky for the distributions. like debian and rubygems (another
> dependency management something) - debian disallows to "sudo gem
> update --system" since this would break the system consistency.
>
True.
> the moment jruby has a build system which is not ant or maven based
> you will not see jruby in these linux distributions for a long time
> (<- my prediction).
>
Well if it is maven based then that will be the end of jruby on gentoo. That
isn't a prediction but sadly the cold hard truth.
It is partly ant based if I remember correctly. Im pretty sure that we sed
out jarjar calls as we don't want jruby to include all everything in one
"nice" (for some, not for us) jar. I understand why you guys do it, doesn't
mean I have to like it. Us unjarjaring jruby means for one that your unit
tests don't run correctly.
I would have no problem it being more rake based. Or buildr based if buildr
ran on ruby{18,19,ee}
> if I look how buildr wants me to install buildr on linux
> (http://buildr.apache.org/installing.html#linux) is basically fouling
> apt or yum the packagemanagers by first replacing rubygems with a
> version which is not "known" by apt or yum and then "sudo gem install
> .... " which might pull in even more gems which will not match what
> the package management knows. (better change the docs to a "gem
> install --user-install ..." and start to behave nice with the
> underlying OS.)
Aint that the maven way.
>
> anyways my wish-list for any build system would be: source + javadocs
> artifact attached to the jruby/jruby-complete artifact so maven based
> IDEs can use these to provide access to source + javadocs. and correct
> checksums (which is not the case right now for some org.jruby.extra.*
> jars).
>
> On Mon, Aug 16, 2010 at 8:29 PM, Antoine Toulme <anto...@lunar-ocean.com>
wrote:
> > So I pick up 3 concerns:
> > 1. It has to do at least a better job than the previous build, and be
> > easy to adopt.
> > 2. It has to build from source.
> > 3. It depends on jruby.
> > 1. in my opinion is a no-brainer. If there is no advantage and it's hard
> > to play with, why bother.
> > 2. is tricky, because it sounds deceptively easy. After all, if you want
> > to build with buildr, you can checkout the tag and do buildr package,
> > and you'll be done with it. I'm not sure what gentoo needs additionally
> > to make it happen. Alistair, can you explain some more the pitfalls
> > there please ?
>
> first you need a buildr ebuild so you can use it as tool for building
> other packages. then dissect the buildfile so the actual build uses
> the packages from Gentoo and NOT the ones from the maven repository or
> from the git repository. and so on and on and on.
>
> > 3. In my opinion, there is no circular dependency. Either install buildr
> > with MRI, or use our standalone integration with jruby over its last
> > release. Buildr is then available in the same way ant is, and you won't
> > see that it's powered by jruby.
> > As long as you can build with a given combination of jruby+buildr, you
> > won't need to depend on either HEAD.
>
> question: how do build jruby without jruby. which is needed if you
> build an OS from source from scratch.
>
> regards Kristian
>
>
> Eventually, adding your buildr build to your
>
> > integration tests would probably help (Buildr was broken with jruby 1.5
> > over the implementation of Array#detect if I remember well).
> > Buildr is very stable, we're packing changes and building an integration
> > test suite, but most of the action is going on in extensions these days
> > (at least that's where my free time goes, sadly).
> > Overall that sounds like normal concerns, and I don't see a blocker. My
> > plan is to contribute a buildfile, and you guys can gradually switch to
> > Buildr if you feel at ease with it. It's a good learning process for
> > Buildr as well. Thanks,
> > Antoine
> >
> > On Sun, Aug 15, 2010 at 07:25, Wayne Meissner <wmeiss...@gmail.com> wrote:
> >> Those are my concerns too. For those things like jffi and jruby
> >> itself where using buildr would create a circular dependency, having
> >> buildr as an alternative is fine, just not the main build system.
> >>
> >> If it could exterminate the maven vermin, it would be well worth it.
> >>
> >> On 13 August 2010 09:12, Charles Oliver Nutter <head...@headius.com>
> >>
> >> wrote:
> >> > Here's my concerns:
> >> >
> >> > * We've already started moving our build into Rake a bit by bit, and
> >> > the bootstrapping question becomes apparent very quickly. In other
> >> > words, we need JRuby (or Ruby) to run Buildr/Rake, but need
> >> > Buildr/Rake to build JRuby.
> >> > * Our Ant build has been a bitch to maintain, but now that it works
> >> > pretty much everyone can build out of the box. That's very valuable.
> >> >
> >> > I would guess that Buildr would make our Maven nonsense easier, and
> >> > maybe even allow us to yank out of our src the libraries that can be
> >> > directly fetched from Maven (like we have experimented with using Ivy
> >> > in the past), so that's definitely a bonus. And of course not having
> >> > to maintain the Ant script is a benefit in any case.
> >> >
> >> > I am interested in hearing other opinions.
> >> >
> >> > - Charlie
> >> >
> >> > On Thu, Aug 12, 2010 at 5:08 PM, Antoine Toulme
> >> >
> >> > <antoine.tou...@gmail.com> wrote:
> >> >> Hi devs,
> >> >> I would like to contribute a Buildr based build to JRuby. Buildr is a
> >> >> Rake-based build system that integrates well with Maven repositories,
> >> >> has a
> >> >> goal-based lifecycle that is very easy to extend and work with.
> >> >> Buildr works on top of MRI or JRuby.
> >> >> I recently contributed a build using Buildr for jffi that shows a
> >> >> drastic
> >> >> reduction of the complexity of the ant build files.
> >> >> It is currently waiting for review on jira, and there may be more
> >> >> work as my
> >> >> C skills didn't allow me to finish the C compilation part:
> >> >> http://jira.codehaus.org/browse/JRUBY-4970
> >> >> This email is meant to test the waters. Please also note I would work
> >> >> on the
> >> >> build system on my own as time permits, so I cannot give a firm date
> >> >> to contribute it.
> >> >> Any strong objections ?
> >> >> Thanks,
> >> >> Antoine
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe from this list, please visit:
> >> >
> >> > http://xircles.codehaus.org/manage_email
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >> http://xircles.codehaus.org/manage_email
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
