great plans. Unfortunately I'm so busy lately that I'm not of big help.
Anyways, I have a couple of thoughts ;)
First, indeed, installing Buildr is still too cumbersome. Maven and Gradle
meanwhile provide wrappers that are basically little jar with
multi-platform batch scripts that download Gradle/Maven into the project's
directory and execute them there. I personally also like the Docker
approach, also because it ensures repeatable builds (i.e. ensuring the very
same JDK version when releasing a patch for a years old release). If this
could become a first class citizen for a in-project bootstrapping process,
that could be a nice thing. I'm a Windows user btw, so I'm happy to help
with improvements in this direction.
Another interesting topic is dependency handling. I always had interesting
discussions defending Buildrs approach to not automatically resolve nested
dependencies. I really like lock_jars approach, which allows to name
dependencies but they are resolved on demand and the resolution is also
under version control. I think this is a big differentiator compared to
Maven or Gradle and makes builds more stable over time.
On Sun, Oct 9, 2016 at 3:06 AM, Antoine Toulme <anto...@toulme.name> wrote:
> > On Oct 8, 2016, at 12:50, Peter Donald <pe...@realityforge.org> wrote:
> >> On Sat, Oct 8, 2016 at 3:44 PM, Antoine Toulme <anto...@toulme.name>
> >> I have a few big items in mind for this release:
> >> -Work around Buildr itself, fix the web site, add more examples that can
> >> also be used as integration tests.
> >> -Take a hard look at the addons folder. Knock out what’s old and crusty,
> >> and maybe move a few into the main code line (I started using custom_pom
> >> and I like it a lot!)
> >> -Communicate and analyze what’s going on. Buildr has been very quiet for
> >> the longest time, but the gem downloads are nothing less than
> > From my observations it seems that Buildr is mostly in use at big
> > organisations with complex build processes that none the less want some
> > sort of standard build process across their system. It could explain the
> > high usage with not a lot of chat. I wonder if we can simplify the
> > started/installation process that we may start to get people interested
> > from the OSS world?
> >> -Our installation story needs an overhaul and we should look at Docker
> >> onbuild, and if there are new ways to bundle Buildr into an executable.
> > All of these sound like good ideas. That last step could be of particular
> > use for windows users who tend to have a little more difficulty getting
> > started. A few plugins may have to be looked at (namely IDEA and eclipse
> > project generation) so that they can generate projects appropriate for
> > outer OS but other than that I think dockerizing it would be a very
> > interesting idea.
> Good point, I'm taking note travis should run on windows.
> > There may also be other issues that arise but several people who use
> > virtualbox to run buildr on windows report this as the only major
> >> I also think that 1.5 was a big release, and I would be in favor of
> >> reacting quickly and cutting a release if - when we see bug reports
> >> in.
> > Yep.
> > We are doing our roll out this next week so hopefully we will identify
> > issues soon.
> That's awesome!
> >> Ideally, I’d like 1.5.1 to be out by Christmas unless something comes
> >> What do you think?
> > All sounds good.
> > --
> > Cheers,
> > Peter Donald
Tammo van Lessen - http://www.taval.de