ApacheCon / Thoughtworks TechRadar

[Tammo van Lessen <tv...@gmail.com>]

Hi devs,

I've got two things I'd like to share with you:

First, I got a Buildr talk accepted at ApacheCon EU in Sinsheim, Germany,
which I held just yesterday. I got a lot of positive feedback, people seem
to like the buildr idea although it also seems that Maven improved since
the inception of Buildr and some things are less worse. The most visible
argument against buildr was, however, that people are used to use Maven and
that, if they want to make their project accessible for a broad audience,
they think they'd need to stick to Maven. I guess Gradle tries to address
this issue by providing a "gradle-wrapper", which is a small jar file along
a shell script that you can include into your project and that will
bootstrap a gradle installation automatically. I also figured, that still
many Java developers don't have rubies at hand and don't know how to easily
install a gem.

Anyways, it was a great conference with great people, so I can highly
recommend visiting it or submitting a Buildr talk to the next ApacheCon
(e.g. NA, deadline is Nov 11, the CfP of the Apache Daily track also
mentions Buildr).

Second, I stumbled upon ThoughtWorks TechRadar [2]. In particular, I liked
the first paragraph of the Tools section ;)

Tools
Of all the build tools and languages we use across our projects, the one we
keep coming back to is Rake. Rake is a beautiful, simple and powerful build
language implemented as an internal Domain-Specific Language on Ruby.
Ruby’s ability to run across several virtual-machine platforms means that
Rake is equally available - while leaving open the option to utilize more
language-specific tools for some tasks. Finding a similar combination of
elegance and flexibility is difficult regardless of your platform, so we
recommend trying *Rake for Java and .Net projects*.

Two things have caused fatigue with XML-based build tools like Ant and
Maven: too many angry pointy braces and the coarseness of plug-in
architectures. While syntax issues can be dealt with through generation,
plug-in architectures severely limit the ability for build tools to grow
gracefully as projects become more complex. We have come to feel that
plug-ins are the wrong level of abstraction, and prefer language-based
tools like *Gradle* and Rake instead, because they offer finer-grained
abstractions and more flexibility long term.

They see Maven in the "hold" category, which means: proceed with caution.
However, I have no idea why they don't see Buildr as the tool of choice :)

Best,
  Tammo

[1] http://na.apachecon.com/cfp/
[2] http://www.thoughtworks.com/articles/technology-radar-october-2012

-- 
Tammo van Lessen - http://www.taval.de

Re: ApacheCon / Thoughtworks TechRadar

[Michel Guymon <mi...@gmail.com>]

Heya Tammo,

So the goal LockJar is to provide a list of transitive dependencies that 
is consistent over time. This is why the dependency information is 
stored in the Jarfile.lock. Every dependency for a project should be 
resolved to the Jarfile.lock. This prevents conflicts that can appear 
from ad hoc resolution of dependencies when their transitive 
dependencies overlap.

LockJar already has the concept of "group". There is always the default 
group, but you can add any additional group you want. All of LockJar's 
actions (list,load,etc) can handle group.

The perk of the LockJar integration is it automatically populates the 
compile and test task classpaths. That being said, the integration with 
LockJar does not have to be used. I am a bit basis, but I like seeing 
the dependency information in the buildfile. You can actually skip the 
locking and have LockJar resolve every time using something along the 
lines of:

    dependencies = LockJar.list ( :resolve => true ) do
       jar 'org.eclipse.jetty:example-jetty-embedded:jar:8.1.2.v20120308'
    end
    ....
    compile.with project('api'), dependencies

Or if you want to use a single Jarfile for all projects, than you could call

    dependencies = LockJar.list(['test'])
    ...
    test.with project('api'), dependencies

So, uh, I should point out I have not updated LockJar's buildr 
integration lately, since I have been in the land RoR. Mostly I have not 
put much time into it, since there does not appear to be a lot of 
interest in it.

thanks,
Michael

On 11/10/2012 06:46 AM, Tammo van Lessen wrote:
> Hi Michel,
>
> I did have a look at lock_jar and I really like the idea. Since I like on
> one hand Mavens magic resolution for bootstrapping a projects, on the other
> hand I also want to have the control over the dependencies. What I usually
> do is running something like
>
> pp transitive(LOGBACK).map {|a| a.to_spec}
>
> and copy the result into my buildfile. lockjar could automate this for me,
> right?
>
> However, it was difficult to me to grok how a real-world multi-project
> buildr file would look like. If I'm not mistaken, I would need to add all
> dependencies separately to the projects using the lock_jar dsl? I'd love if
> there would be a more unobtrusive way like saying
>
> compile.with project('api'), lock(AXIS2, AXIOM, OPENJPA)
> test.with lock(TESTNG)
>
> and lockjar would use this information to create the lockfile
> (automatically if not there, otherwise on demand) and return a resolved set
> of dependencies. The lock method could also take an optional group
> parameter in order to define independent resolution groups. Still open
> would be the question how excludes or pinned versions could be expressed.
>
> Do you think such an integration would useful or feasible?
>
> Thanks,
>    Tammo
>
>
> On Sat, Nov 10, 2012 at 5:13 AM, Michel Guymon <mi...@gmail.com>wrote:
>
>> Hi,
>>
>> I figure I would pile onto the Buildr vs Maven discussion, this will be a
>> little non sequitur.
>>
>> What I have been doing is using Maven for project info, mostly defining
>> dependencies and where to deploy to. This is what Maven is actually good
>> at, project markup. The perk is all the existing tools can continue to work
>> with the Project's POM. Everything else I do is handled by Buildr. Using
>> LockJar[1] to import the deps and deployment info from the POM, I am able
>> to build and deploy my artifacts from Buildr.
>>
>> I find this is the sweet spot, being able to live in a Maven world but
>> still able to build my artifacts the way I need to with Buildr. God help me
>> if I ever have to use and XML build tool again. . .
>>
>> thanks,
>> Michael
>>
>>
>> [1] https://github.com/mguymon/**lock_jar#buildr-integration<https://github.com/mguymon/lock_jar#buildr-integration><
>> https://github.com/mguymon/**lock_jar<https://github.com/mguymon/lock_jar>
>>
>> On 11/09/2012 10:04 PM, Peter Donald wrote:
>>
>>> Huya,
>>>
>>> On Sat, Nov 10, 2012 at 5:21 AM, Tammo van Lessen <tv...@gmail.com>
>>> wrote:
>>>
>>>> First, I got a Buildr talk accepted at ApacheCon EU in Sinsheim, Germany,
>>>> which I held just yesterday.
>>>>
>>> congrats!
>>>
>>>   I got a lot of positive feedback, people seem
>>>> to like the buildr idea although it also seems that Maven improved since
>>>> the inception of Buildr and some things are less worse. The most visible
>>>> argument against buildr was, however, that people are used to use Maven
>>>> and
>>>> that, if they want to make their project accessible for a broad audience,
>>>> they think they'd need to stick to Maven.
>>>>
>>> That does seem to be a common view.
>>>
>>>   I guess Gradle tries to address
>>>> this issue by providing a "gradle-wrapper", which is a small jar file
>>>> along
>>>> a shell script that you can include into your project and that will
>>>> bootstrap a gradle installation automatically. I also figured, that still
>>>> many Java developers don't have rubies at hand and don't know how to
>>>> easily
>>>> install a gem.
>>>>
>>> And one stage, Antoine was working on the "all-in-one" distribution
>>> that essentially bundled a version of jruby with buildr and all it's
>>> dependencies in one easy installer. I wonder if we could work on this
>>> to ease adoption of buildr for the casual user.
>>>
>>> Where I work we use Chef (http://www.opscode.com/chef/) extensively
>>> and they release their tool in "omnibus" editions that are essentially
>>> a complete version of ruby for n-different platforms. They preinstall
>>> the chef gems in the ruby they distribute but they make sure that the
>>> only things that are added to the path are the che executables. I
>>> wonder if this would be a good thing for us to consider?
>>>
>>>   Second, I stumbled upon ThoughtWorks TechRadar [2]. In particular, I
>>>> liked
>>>> the first paragraph of the Tools section ;)
>>>>
>>> It is kinda neat. Possibly the best thing we can do is to increase
>>> awareness ... I think your approach to giving a talk is a good idea.
>>>
>>>
>

Re: ApacheCon / Thoughtworks TechRadar

[Tammo van Lessen <tv...@gmail.com>]

Hi Michel,

I did have a look at lock_jar and I really like the idea. Since I like on
one hand Mavens magic resolution for bootstrapping a projects, on the other
hand I also want to have the control over the dependencies. What I usually
do is running something like

pp transitive(LOGBACK).map {|a| a.to_spec}

and copy the result into my buildfile. lockjar could automate this for me,
right?

However, it was difficult to me to grok how a real-world multi-project
buildr file would look like. If I'm not mistaken, I would need to add all
dependencies separately to the projects using the lock_jar dsl? I'd love if
there would be a more unobtrusive way like saying

compile.with project('api'), lock(AXIS2, AXIOM, OPENJPA)
test.with lock(TESTNG)

and lockjar would use this information to create the lockfile
(automatically if not there, otherwise on demand) and return a resolved set
of dependencies. The lock method could also take an optional group
parameter in order to define independent resolution groups. Still open
would be the question how excludes or pinned versions could be expressed.

Do you think such an integration would useful or feasible?

Thanks,
  Tammo


On Sat, Nov 10, 2012 at 5:13 AM, Michel Guymon <mi...@gmail.com>wrote:

>
> Hi,
>
> I figure I would pile onto the Buildr vs Maven discussion, this will be a
> little non sequitur.
>
> What I have been doing is using Maven for project info, mostly defining
> dependencies and where to deploy to. This is what Maven is actually good
> at, project markup. The perk is all the existing tools can continue to work
> with the Project's POM. Everything else I do is handled by Buildr. Using
> LockJar[1] to import the deps and deployment info from the POM, I am able
> to build and deploy my artifacts from Buildr.
>
> I find this is the sweet spot, being able to live in a Maven world but
> still able to build my artifacts the way I need to with Buildr. God help me
> if I ever have to use and XML build tool again. . .
>
> thanks,
> Michael
>
>
> [1] https://github.com/mguymon/**lock_jar#buildr-integration<https://github.com/mguymon/lock_jar#buildr-integration><
> https://github.com/mguymon/**lock_jar<https://github.com/mguymon/lock_jar>
> >
>
>
> On 11/09/2012 10:04 PM, Peter Donald wrote:
>
>> Huya,
>>
>> On Sat, Nov 10, 2012 at 5:21 AM, Tammo van Lessen <tv...@gmail.com>
>> wrote:
>>
>>> First, I got a Buildr talk accepted at ApacheCon EU in Sinsheim, Germany,
>>> which I held just yesterday.
>>>
>> congrats!
>>
>>  I got a lot of positive feedback, people seem
>>> to like the buildr idea although it also seems that Maven improved since
>>> the inception of Buildr and some things are less worse. The most visible
>>> argument against buildr was, however, that people are used to use Maven
>>> and
>>> that, if they want to make their project accessible for a broad audience,
>>> they think they'd need to stick to Maven.
>>>
>> That does seem to be a common view.
>>
>>  I guess Gradle tries to address
>>> this issue by providing a "gradle-wrapper", which is a small jar file
>>> along
>>> a shell script that you can include into your project and that will
>>> bootstrap a gradle installation automatically. I also figured, that still
>>> many Java developers don't have rubies at hand and don't know how to
>>> easily
>>> install a gem.
>>>
>> And one stage, Antoine was working on the "all-in-one" distribution
>> that essentially bundled a version of jruby with buildr and all it's
>> dependencies in one easy installer. I wonder if we could work on this
>> to ease adoption of buildr for the casual user.
>>
>> Where I work we use Chef (http://www.opscode.com/chef/) extensively
>> and they release their tool in "omnibus" editions that are essentially
>> a complete version of ruby for n-different platforms. They preinstall
>> the chef gems in the ruby they distribute but they make sure that the
>> only things that are added to the path are the che executables. I
>> wonder if this would be a good thing for us to consider?
>>
>>  Second, I stumbled upon ThoughtWorks TechRadar [2]. In particular, I
>>> liked
>>> the first paragraph of the Tools section ;)
>>>
>> It is kinda neat. Possibly the best thing we can do is to increase
>> awareness ... I think your approach to giving a talk is a good idea.
>>
>>
>


-- 
Tammo van Lessen - http://www.taval.de

Re: ApacheCon / Thoughtworks TechRadar

[Michel Guymon <mi...@gmail.com>]

Hi,

I figure I would pile onto the Buildr vs Maven discussion, this will be 
a little non sequitur.

What I have been doing is using Maven for project info, mostly defining 
dependencies and where to deploy to. This is what Maven is actually good 
at, project markup. The perk is all the existing tools can continue to 
work with the Project's POM. Everything else I do is handled by Buildr. 
Using LockJar[1] to import the deps and deployment info from the POM, I 
am able to build and deploy my artifacts from Buildr.

I find this is the sweet spot, being able to live in a Maven world but 
still able to build my artifacts the way I need to with Buildr. God help 
me if I ever have to use and XML build tool again. . .

thanks,
Michael


[1] https://github.com/mguymon/lock_jar#buildr-integration 
<https://github.com/mguymon/lock_jar>

On 11/09/2012 10:04 PM, Peter Donald wrote:
> Huya,
>
> On Sat, Nov 10, 2012 at 5:21 AM, Tammo van Lessen <tv...@gmail.com> wrote:
>> First, I got a Buildr talk accepted at ApacheCon EU in Sinsheim, Germany,
>> which I held just yesterday.
> congrats!
>
>> I got a lot of positive feedback, people seem
>> to like the buildr idea although it also seems that Maven improved since
>> the inception of Buildr and some things are less worse. The most visible
>> argument against buildr was, however, that people are used to use Maven and
>> that, if they want to make their project accessible for a broad audience,
>> they think they'd need to stick to Maven.
> That does seem to be a common view.
>
>> I guess Gradle tries to address
>> this issue by providing a "gradle-wrapper", which is a small jar file along
>> a shell script that you can include into your project and that will
>> bootstrap a gradle installation automatically. I also figured, that still
>> many Java developers don't have rubies at hand and don't know how to easily
>> install a gem.
> And one stage, Antoine was working on the "all-in-one" distribution
> that essentially bundled a version of jruby with buildr and all it's
> dependencies in one easy installer. I wonder if we could work on this
> to ease adoption of buildr for the casual user.
>
> Where I work we use Chef (http://www.opscode.com/chef/) extensively
> and they release their tool in "omnibus" editions that are essentially
> a complete version of ruby for n-different platforms. They preinstall
> the chef gems in the ruby they distribute but they make sure that the
> only things that are added to the path are the che executables. I
> wonder if this would be a good thing for us to consider?
>
>> Second, I stumbled upon ThoughtWorks TechRadar [2]. In particular, I liked
>> the first paragraph of the Tools section ;)
> It is kinda neat. Possibly the best thing we can do is to increase
> awareness ... I think your approach to giving a talk is a good idea.
>

Re: ApacheCon / Thoughtworks TechRadar

[Antoine Toulme <an...@lunar-ocean.com>]

FWIW the all-in-one bundle was there before and Alex coded most if not all
of it :)

If I remember correctly, building the all-in-one is supported by a rake
task.


On Fri, Nov 9, 2012 at 7:04 PM, Peter Donald <pe...@realityforge.org> wrote:

> Huya,
>
> On Sat, Nov 10, 2012 at 5:21 AM, Tammo van Lessen <tv...@gmail.com>
> wrote:
> > First, I got a Buildr talk accepted at ApacheCon EU in Sinsheim, Germany,
> > which I held just yesterday.
>
> congrats!
>
> > I got a lot of positive feedback, people seem
> > to like the buildr idea although it also seems that Maven improved since
> > the inception of Buildr and some things are less worse. The most visible
> > argument against buildr was, however, that people are used to use Maven
> and
> > that, if they want to make their project accessible for a broad audience,
> > they think they'd need to stick to Maven.
>
> That does seem to be a common view.
>
> > I guess Gradle tries to address
> > this issue by providing a "gradle-wrapper", which is a small jar file
> along
> > a shell script that you can include into your project and that will
> > bootstrap a gradle installation automatically. I also figured, that still
> > many Java developers don't have rubies at hand and don't know how to
> easily
> > install a gem.
>
> And one stage, Antoine was working on the "all-in-one" distribution
> that essentially bundled a version of jruby with buildr and all it's
> dependencies in one easy installer. I wonder if we could work on this
> to ease adoption of buildr for the casual user.
>
> Where I work we use Chef (http://www.opscode.com/chef/) extensively
> and they release their tool in "omnibus" editions that are essentially
> a complete version of ruby for n-different platforms. They preinstall
> the chef gems in the ruby they distribute but they make sure that the
> only things that are added to the path are the che executables. I
> wonder if this would be a good thing for us to consider?
>
> > Second, I stumbled upon ThoughtWorks TechRadar [2]. In particular, I
> liked
> > the first paragraph of the Tools section ;)
>
> It is kinda neat. Possibly the best thing we can do is to increase
> awareness ... I think your approach to giving a talk is a good idea.
>
> --
> Cheers,
>
> Peter Donald
>

Re: ApacheCon / Thoughtworks TechRadar

[Peter Donald <pe...@realityforge.org>]

Huya,

On Sat, Nov 10, 2012 at 5:21 AM, Tammo van Lessen <tv...@gmail.com> wrote:
> First, I got a Buildr talk accepted at ApacheCon EU in Sinsheim, Germany,
> which I held just yesterday.

congrats!

> I got a lot of positive feedback, people seem
> to like the buildr idea although it also seems that Maven improved since
> the inception of Buildr and some things are less worse. The most visible
> argument against buildr was, however, that people are used to use Maven and
> that, if they want to make their project accessible for a broad audience,
> they think they'd need to stick to Maven.

That does seem to be a common view.

> I guess Gradle tries to address
> this issue by providing a "gradle-wrapper", which is a small jar file along
> a shell script that you can include into your project and that will
> bootstrap a gradle installation automatically. I also figured, that still
> many Java developers don't have rubies at hand and don't know how to easily
> install a gem.

And one stage, Antoine was working on the "all-in-one" distribution
that essentially bundled a version of jruby with buildr and all it's
dependencies in one easy installer. I wonder if we could work on this
to ease adoption of buildr for the casual user.

Where I work we use Chef (http://www.opscode.com/chef/) extensively
and they release their tool in "omnibus" editions that are essentially
a complete version of ruby for n-different platforms. They preinstall
the chef gems in the ruby they distribute but they make sure that the
only things that are added to the path are the che executables. I
wonder if this would be a good thing for us to consider?

> Second, I stumbled upon ThoughtWorks TechRadar [2]. In particular, I liked
> the first paragraph of the Tools section ;)

It is kinda neat. Possibly the best thing we can do is to increase
awareness ... I think your approach to giving a talk is a good idea.

-- 
Cheers,

Peter Donald