You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Shane Witbeck <sh...@digitalsanctum.com> on 2010/01/20 20:47:48 UTC
new version of IntelliJ IDEA Buildr plug-in is available
There's a new version of the Buildr plug-in available for IDEA version
9x thanks to Steven Blundy who forked my old code on github:
http://github.com/digitalsanctum/buildr-plugin
The plug-in is still very basic so additional contributions are welcome!
-Shane
Re: dzone
Posted by Alex Boisvert <al...@gmail.com>.
On Sat, Jan 23, 2010 at 9:25 AM, Alex Boisvert <al...@gmail.com>wrote:
> For better or worse, a distinguishing feature of Buildr remains its ties to
> Ruby. Ruby is a great language with a rich ecosystem and a lively
> culture. It can also be perceived as 'another language to learn' or
> 'introducing yet-another language' into a project. I'd rank these fears as
> our biggest obstacle to popularity. However, these fears are irrational and
> as a small project I don't think there's much we can do to overcome them.
>
Related tweet <http://twitter.com/headius/status/8284505695> from Charles
Nutter (headius) today:
I wish Rubyists realized how much energy and time it takes to promote Ruby
> to Java folks. It's like missionary work...a thankless job.
>
Re: dzone
Posted by Martin Grotzke <ma...@javakaffee.de>.
Really cool! You might want to add this to the wiki HowTos:
http://cwiki.apache.org/confluence/display/BUILDR/Buildr+HowTos
Cheers,
Martin
On Fri, 2010-02-26 at 20:13 -0500, Chetan Sarva wrote:
> Spent a little too much time writing another script to post process my
> list of deps and get a simpler de-duped list.. :)
>
> http://gist.github.com/316361
>
> To use, stick all of your constants containing specs into a file (with
> nothing else) and then feed the file to the script.
>
> On Fri, Feb 26, 2010 at 6:43 PM, Alex Boisvert <al...@gmail.com> wrote:
> > That's the way, uh-huh uh-huh, I like it, uh-huh, uh-huh.
> > That's the way...
> >
> >
> > On Fri, Feb 26, 2010 at 11:51 AM, Chetan Sarva <cs...@gmail.com> wrote:
> >
> >> Love the whitelist idea. I just wrote a simple task which takes care
> >> of my needs at least --
> >>
> >> $ buildr whitelist[org.springframework:spring-web:jar:3.0.1.RELEASE]
> >> (in /Users/chetan/play/buildr_whitelist, development)
> >>
> >> listing all transitive specs for:
> >> org.springframework:spring-web:jar:3.0.1.RELEASE
> >>
> >> SPRING_WEB = [
> >> "activation:activation:jar:1.0.2",
> >> "aopalliance:aopalliance:jar:1.0",
> >> "commons-logging:commons-logging:jar:1.1.1",
> >> "javax.portlet:portlet-api:jar:2.0",
> >> "javax.servlet.jsp:jsp-api:jar:2.1",
> >> "javax.servlet:servlet-api:jar:2.5",
> >> "javax.xml.soap:saaj-api:jar:1.3",
> >> "org.springframework:spring-aop:jar:3.0.1.RELEASE",
> >> "org.springframework:spring-asm:jar:3.0.1.RELEASE",
> >> "org.springframework:spring-beans:jar:3.0.1.RELEASE",
> >> "org.springframework:spring-context:jar:3.0.1.RELEASE",
> >> "org.springframework:spring-core:jar:3.0.1.RELEASE",
> >> "org.springframework:spring-expression:jar:3.0.1.RELEASE",
> >> "org.springframework:spring-web:jar:3.0.1.RELEASE"
> >> ]
> >>
> >>
> >> Completed in 0.711s
> >>
> >> you can grab it here --
> >>
> >>
> >> http://github.com/chetan/misc/blob/master/scripts/buildr_tasks/whitelist.rake
> >>
> >> Hopefully others will find it useful.
> >>
> >> chetan
> >>
> >> On Wed, Feb 24, 2010 at 12:52 PM, Alex Boisvert <al...@gmail.com>
> >> wrote:
> >> > On Wed, Feb 24, 2010 at 8:47 AM, Will Rogers <wj...@gmail.com> wrote:
> >> >
> >> >> On Sat, Jan 23, 2010 at 12:25 PM, Alex Boisvert <
> >> alex.boisvert@gmail.com>
> >> >> wrote:
> >> >> > solid. Whitelisting dependencies has worked very well for many of us
> >> on
> >> >> big
> >> >> > projects and is probably an under-appreciated feature.
> >> >>
> >> >> What does "whitelisting dependencies" mean?
> >> >>
> >> >
> >> > Whilelisting dependencies means explicitly specifying all dependencies in
> >> > your project. No guessing game, all dependencies you use and package are
> >> in
> >> > plain sight.
> >> >
> >> > Compare this to a system where you generate a list of dependencies
> >> through a
> >> > transitive closure (e.g. specifying a dependency on Tomcat automatically
> >> > gets you Servlet API, Apache Commons logging, and probably 10+ other
> >> > dependencies). In such a system, you have to "blacklist" dependencies
> >> you
> >> > want to exclude, say, you don't use JSP pages so you don't need Jasper
> >> > (which is a JSP engine integrated with Tomcat).
> >> >
> >> > Transitive dependencies are typically great to get you started quickly
> >> but
> >> > often come back to haunt you because the automatically-generated list may
> >> > contain surprises. For example, if you have multiple transitive roots
> >> (e.g.
> >> > Tomcat and Axis2), then you may have conflicts and/or duplicate
> >> dependencies
> >> > that may not be detected. In an ideal world, these kinds of things
> >> don't
> >> > happen but ... in reality they happen and either catch you at the least
> >> > opportune moment or turn into long debugging sessions about why this or
> >> that
> >> > isn't working as expected.
> >> >
> >> > I think we're leaning towards support for transitive dependencies that
> >> would
> >> > essentially have a manual, separate phase for resolving dependencies and
> >> > then save/freeze the list so it's not regenerated automatically based on
> >> > changing conditions. Thus making the result easily
> >> > editable/reviewable/auditable when needed.
> >> >
> >> > alex
> >> >
> >>
> >
>
Re: dzone
Posted by Chetan Sarva <cs...@gmail.com>.
Spent a little too much time writing another script to post process my
list of deps and get a simpler de-duped list.. :)
http://gist.github.com/316361
To use, stick all of your constants containing specs into a file (with
nothing else) and then feed the file to the script.
On Fri, Feb 26, 2010 at 6:43 PM, Alex Boisvert <al...@gmail.com> wrote:
> That's the way, uh-huh uh-huh, I like it, uh-huh, uh-huh.
> That's the way...
>
>
> On Fri, Feb 26, 2010 at 11:51 AM, Chetan Sarva <cs...@gmail.com> wrote:
>
>> Love the whitelist idea. I just wrote a simple task which takes care
>> of my needs at least --
>>
>> $ buildr whitelist[org.springframework:spring-web:jar:3.0.1.RELEASE]
>> (in /Users/chetan/play/buildr_whitelist, development)
>>
>> listing all transitive specs for:
>> org.springframework:spring-web:jar:3.0.1.RELEASE
>>
>> SPRING_WEB = [
>> "activation:activation:jar:1.0.2",
>> "aopalliance:aopalliance:jar:1.0",
>> "commons-logging:commons-logging:jar:1.1.1",
>> "javax.portlet:portlet-api:jar:2.0",
>> "javax.servlet.jsp:jsp-api:jar:2.1",
>> "javax.servlet:servlet-api:jar:2.5",
>> "javax.xml.soap:saaj-api:jar:1.3",
>> "org.springframework:spring-aop:jar:3.0.1.RELEASE",
>> "org.springframework:spring-asm:jar:3.0.1.RELEASE",
>> "org.springframework:spring-beans:jar:3.0.1.RELEASE",
>> "org.springframework:spring-context:jar:3.0.1.RELEASE",
>> "org.springframework:spring-core:jar:3.0.1.RELEASE",
>> "org.springframework:spring-expression:jar:3.0.1.RELEASE",
>> "org.springframework:spring-web:jar:3.0.1.RELEASE"
>> ]
>>
>>
>> Completed in 0.711s
>>
>> you can grab it here --
>>
>>
>> http://github.com/chetan/misc/blob/master/scripts/buildr_tasks/whitelist.rake
>>
>> Hopefully others will find it useful.
>>
>> chetan
>>
>> On Wed, Feb 24, 2010 at 12:52 PM, Alex Boisvert <al...@gmail.com>
>> wrote:
>> > On Wed, Feb 24, 2010 at 8:47 AM, Will Rogers <wj...@gmail.com> wrote:
>> >
>> >> On Sat, Jan 23, 2010 at 12:25 PM, Alex Boisvert <
>> alex.boisvert@gmail.com>
>> >> wrote:
>> >> > solid. Whitelisting dependencies has worked very well for many of us
>> on
>> >> big
>> >> > projects and is probably an under-appreciated feature.
>> >>
>> >> What does "whitelisting dependencies" mean?
>> >>
>> >
>> > Whilelisting dependencies means explicitly specifying all dependencies in
>> > your project. No guessing game, all dependencies you use and package are
>> in
>> > plain sight.
>> >
>> > Compare this to a system where you generate a list of dependencies
>> through a
>> > transitive closure (e.g. specifying a dependency on Tomcat automatically
>> > gets you Servlet API, Apache Commons logging, and probably 10+ other
>> > dependencies). In such a system, you have to "blacklist" dependencies
>> you
>> > want to exclude, say, you don't use JSP pages so you don't need Jasper
>> > (which is a JSP engine integrated with Tomcat).
>> >
>> > Transitive dependencies are typically great to get you started quickly
>> but
>> > often come back to haunt you because the automatically-generated list may
>> > contain surprises. For example, if you have multiple transitive roots
>> (e.g.
>> > Tomcat and Axis2), then you may have conflicts and/or duplicate
>> dependencies
>> > that may not be detected. In an ideal world, these kinds of things
>> don't
>> > happen but ... in reality they happen and either catch you at the least
>> > opportune moment or turn into long debugging sessions about why this or
>> that
>> > isn't working as expected.
>> >
>> > I think we're leaning towards support for transitive dependencies that
>> would
>> > essentially have a manual, separate phase for resolving dependencies and
>> > then save/freeze the list so it's not regenerated automatically based on
>> > changing conditions. Thus making the result easily
>> > editable/reviewable/auditable when needed.
>> >
>> > alex
>> >
>>
>
Re: dzone
Posted by Alex Boisvert <al...@gmail.com>.
That's the way, uh-huh uh-huh, I like it, uh-huh, uh-huh.
That's the way...
On Fri, Feb 26, 2010 at 11:51 AM, Chetan Sarva <cs...@gmail.com> wrote:
> Love the whitelist idea. I just wrote a simple task which takes care
> of my needs at least --
>
> $ buildr whitelist[org.springframework:spring-web:jar:3.0.1.RELEASE]
> (in /Users/chetan/play/buildr_whitelist, development)
>
> listing all transitive specs for:
> org.springframework:spring-web:jar:3.0.1.RELEASE
>
> SPRING_WEB = [
> "activation:activation:jar:1.0.2",
> "aopalliance:aopalliance:jar:1.0",
> "commons-logging:commons-logging:jar:1.1.1",
> "javax.portlet:portlet-api:jar:2.0",
> "javax.servlet.jsp:jsp-api:jar:2.1",
> "javax.servlet:servlet-api:jar:2.5",
> "javax.xml.soap:saaj-api:jar:1.3",
> "org.springframework:spring-aop:jar:3.0.1.RELEASE",
> "org.springframework:spring-asm:jar:3.0.1.RELEASE",
> "org.springframework:spring-beans:jar:3.0.1.RELEASE",
> "org.springframework:spring-context:jar:3.0.1.RELEASE",
> "org.springframework:spring-core:jar:3.0.1.RELEASE",
> "org.springframework:spring-expression:jar:3.0.1.RELEASE",
> "org.springframework:spring-web:jar:3.0.1.RELEASE"
> ]
>
>
> Completed in 0.711s
>
> you can grab it here --
>
>
> http://github.com/chetan/misc/blob/master/scripts/buildr_tasks/whitelist.rake
>
> Hopefully others will find it useful.
>
> chetan
>
> On Wed, Feb 24, 2010 at 12:52 PM, Alex Boisvert <al...@gmail.com>
> wrote:
> > On Wed, Feb 24, 2010 at 8:47 AM, Will Rogers <wj...@gmail.com> wrote:
> >
> >> On Sat, Jan 23, 2010 at 12:25 PM, Alex Boisvert <
> alex.boisvert@gmail.com>
> >> wrote:
> >> > solid. Whitelisting dependencies has worked very well for many of us
> on
> >> big
> >> > projects and is probably an under-appreciated feature.
> >>
> >> What does "whitelisting dependencies" mean?
> >>
> >
> > Whilelisting dependencies means explicitly specifying all dependencies in
> > your project. No guessing game, all dependencies you use and package are
> in
> > plain sight.
> >
> > Compare this to a system where you generate a list of dependencies
> through a
> > transitive closure (e.g. specifying a dependency on Tomcat automatically
> > gets you Servlet API, Apache Commons logging, and probably 10+ other
> > dependencies). In such a system, you have to "blacklist" dependencies
> you
> > want to exclude, say, you don't use JSP pages so you don't need Jasper
> > (which is a JSP engine integrated with Tomcat).
> >
> > Transitive dependencies are typically great to get you started quickly
> but
> > often come back to haunt you because the automatically-generated list may
> > contain surprises. For example, if you have multiple transitive roots
> (e.g.
> > Tomcat and Axis2), then you may have conflicts and/or duplicate
> dependencies
> > that may not be detected. In an ideal world, these kinds of things
> don't
> > happen but ... in reality they happen and either catch you at the least
> > opportune moment or turn into long debugging sessions about why this or
> that
> > isn't working as expected.
> >
> > I think we're leaning towards support for transitive dependencies that
> would
> > essentially have a manual, separate phase for resolving dependencies and
> > then save/freeze the list so it's not regenerated automatically based on
> > changing conditions. Thus making the result easily
> > editable/reviewable/auditable when needed.
> >
> > alex
> >
>
Re: dzone
Posted by Chetan Sarva <cs...@gmail.com>.
Love the whitelist idea. I just wrote a simple task which takes care
of my needs at least --
$ buildr whitelist[org.springframework:spring-web:jar:3.0.1.RELEASE]
(in /Users/chetan/play/buildr_whitelist, development)
listing all transitive specs for:
org.springframework:spring-web:jar:3.0.1.RELEASE
SPRING_WEB = [
"activation:activation:jar:1.0.2",
"aopalliance:aopalliance:jar:1.0",
"commons-logging:commons-logging:jar:1.1.1",
"javax.portlet:portlet-api:jar:2.0",
"javax.servlet.jsp:jsp-api:jar:2.1",
"javax.servlet:servlet-api:jar:2.5",
"javax.xml.soap:saaj-api:jar:1.3",
"org.springframework:spring-aop:jar:3.0.1.RELEASE",
"org.springframework:spring-asm:jar:3.0.1.RELEASE",
"org.springframework:spring-beans:jar:3.0.1.RELEASE",
"org.springframework:spring-context:jar:3.0.1.RELEASE",
"org.springframework:spring-core:jar:3.0.1.RELEASE",
"org.springframework:spring-expression:jar:3.0.1.RELEASE",
"org.springframework:spring-web:jar:3.0.1.RELEASE"
]
Completed in 0.711s
you can grab it here --
http://github.com/chetan/misc/blob/master/scripts/buildr_tasks/whitelist.rake
Hopefully others will find it useful.
chetan
On Wed, Feb 24, 2010 at 12:52 PM, Alex Boisvert <al...@gmail.com> wrote:
> On Wed, Feb 24, 2010 at 8:47 AM, Will Rogers <wj...@gmail.com> wrote:
>
>> On Sat, Jan 23, 2010 at 12:25 PM, Alex Boisvert <al...@gmail.com>
>> wrote:
>> > solid. Whitelisting dependencies has worked very well for many of us on
>> big
>> > projects and is probably an under-appreciated feature.
>>
>> What does "whitelisting dependencies" mean?
>>
>
> Whilelisting dependencies means explicitly specifying all dependencies in
> your project. No guessing game, all dependencies you use and package are in
> plain sight.
>
> Compare this to a system where you generate a list of dependencies through a
> transitive closure (e.g. specifying a dependency on Tomcat automatically
> gets you Servlet API, Apache Commons logging, and probably 10+ other
> dependencies). In such a system, you have to "blacklist" dependencies you
> want to exclude, say, you don't use JSP pages so you don't need Jasper
> (which is a JSP engine integrated with Tomcat).
>
> Transitive dependencies are typically great to get you started quickly but
> often come back to haunt you because the automatically-generated list may
> contain surprises. For example, if you have multiple transitive roots (e.g.
> Tomcat and Axis2), then you may have conflicts and/or duplicate dependencies
> that may not be detected. In an ideal world, these kinds of things don't
> happen but ... in reality they happen and either catch you at the least
> opportune moment or turn into long debugging sessions about why this or that
> isn't working as expected.
>
> I think we're leaning towards support for transitive dependencies that would
> essentially have a manual, separate phase for resolving dependencies and
> then save/freeze the list so it's not regenerated automatically based on
> changing conditions. Thus making the result easily
> editable/reviewable/auditable when needed.
>
> alex
>
Re: dzone
Posted by Alex Boisvert <al...@gmail.com>.
On Wed, Feb 24, 2010 at 8:47 AM, Will Rogers <wj...@gmail.com> wrote:
> On Sat, Jan 23, 2010 at 12:25 PM, Alex Boisvert <al...@gmail.com>
> wrote:
> > solid. Whitelisting dependencies has worked very well for many of us on
> big
> > projects and is probably an under-appreciated feature.
>
> What does "whitelisting dependencies" mean?
>
Whilelisting dependencies means explicitly specifying all dependencies in
your project. No guessing game, all dependencies you use and package are in
plain sight.
Compare this to a system where you generate a list of dependencies through a
transitive closure (e.g. specifying a dependency on Tomcat automatically
gets you Servlet API, Apache Commons logging, and probably 10+ other
dependencies). In such a system, you have to "blacklist" dependencies you
want to exclude, say, you don't use JSP pages so you don't need Jasper
(which is a JSP engine integrated with Tomcat).
Transitive dependencies are typically great to get you started quickly but
often come back to haunt you because the automatically-generated list may
contain surprises. For example, if you have multiple transitive roots (e.g.
Tomcat and Axis2), then you may have conflicts and/or duplicate dependencies
that may not be detected. In an ideal world, these kinds of things don't
happen but ... in reality they happen and either catch you at the least
opportune moment or turn into long debugging sessions about why this or that
isn't working as expected.
I think we're leaning towards support for transitive dependencies that would
essentially have a manual, separate phase for resolving dependencies and
then save/freeze the list so it's not regenerated automatically based on
changing conditions. Thus making the result easily
editable/reviewable/auditable when needed.
alex
Re: dzone
Posted by Will Rogers <wj...@gmail.com>.
On Sat, Jan 23, 2010 at 12:25 PM, Alex Boisvert <al...@gmail.com> wrote:
> solid. Whitelisting dependencies has worked very well for many of us on big
> projects and is probably an under-appreciated feature.
What does "whitelisting dependencies" mean?
I have jumped into a project at the deep end and I'm still trying to
familiarize myself with how the Java ecosystem operates, so these
kinds of discussions are very useful to me. Thanks (for the blog too)!
-- Will
AW: dzone
Posted by Klaas Prause <kl...@blau.de>.
If you have an questions about it, just drop me a note. It works like a charm for us but I guess it needs some tweaking for the public. We have covered all of our bases so far.
Klaas
-----Ursprüngliche Nachricht-----
Von: Alex Boisvert [mailto:alex.boisvert@gmail.com]
Gesendet: Sonntag, 24. Januar 2010 20:17
An: users@buildr.apache.org
Betreff: Re: dzone
Yes, that's what I had in mind. I need to take a second serious look at it.
alex
On Sun, Jan 24, 2010 at 11:10 AM, Peter Schröder <ps...@blau.de> wrote:
> did you have a look at ivy4r (
> http://klaasprause.com/2009/07/12/ivy4r-using-apache-ivy-with-ruby/) ?
>
> we are using it for all of our projects.
>
> i think that it would be great to integrate something like that directly
> into buildr.
>
> ________________________________________
> Von: Alex Boisvert [alex.boisvert@gmail.com]
> Gesendet: Samstag, 23. Januar 2010 18:25
> An: users@buildr.apache.org
> Betreff: Re: dzone
>
> Nice article. The comments/reactions to buildr are always interesting.
>
> If I can segway for a moment... The JVM build tool landscape has certainly
> expanded much since buildr started. There are more potent choices
> available
> (e.g. Graddle and SBT). Maven2 has fixed a lot of issues from its early
> days. And now Maven3 on the way... I think it gets more difficult to get
> our message across because some of the alternatives may look similar on the
> surface and may share some/many of the features.
>
> For better or worse, a distinguishing feature of Buildr remains its ties to
> Ruby. Ruby is a great language with a rich ecosystem and a lively
> culture. It can also be perceived as 'another language to learn' or
> 'introducing yet-another language' into a project. I'd rank these fears as
> our biggest obstacle to popularity. However, these fears are irrational
> and
> as a small project I don't think there's much we can do to overcome them.
>
> Beyond the language issue, I think our two most important challenges today
> are 1) ease of installation and 2) a good story on dependency management.
> We've gotten much better on the installation side recently and I hope the
> all-in-one distro will help starting with Buildr 1.4.0.
>
> On the dependency management side, I consider what we have today very
> solid. Whitelisting dependencies has worked very well for many of us on
> big
> projects and is probably an under-appreciated feature. It's hard to
> communicate the value here without people having had bad experiences with
> other transitive dependency management approach. The seduction of
> transitive dependencies is too great -- on paper it always works
> perfectly. So if there's one thing I'd like to improve after Buildr 1.4.0
> it's our story on dependency management. We need to communicate better
> but
> also add better tooling support. I think better/tigher integration with
> Ivy
> would go a long way. There's probably other good approaches out there and
> I'd be interested in hearing about what other people think.
>
> My $0.02 on the buildr state of the union. Thanks for the article! Every
> bit of advocacy helps. Now if I could find some time to blog...
>
> alex
>
> On Thu, Jan 21, 2010 at 12:37 AM, Peter Schröder <ps...@blau.de> wrote:
>
> > hi,
> >
> > i posted a little article about buildr on dzone (
> > http://www.dzone.com/links/the_build_system_that_doesnt_suck.html).
> >
> > i hope that it will create some attention for buildr to let the community
> > grow further.
> >
> > kind regards,
> > peter
>
Re: dzone
Posted by Alex Boisvert <al...@gmail.com>.
Yes, that's what I had in mind. I need to take a second serious look at it.
alex
On Sun, Jan 24, 2010 at 11:10 AM, Peter Schröder <ps...@blau.de> wrote:
> did you have a look at ivy4r (
> http://klaasprause.com/2009/07/12/ivy4r-using-apache-ivy-with-ruby/) ?
>
> we are using it for all of our projects.
>
> i think that it would be great to integrate something like that directly
> into buildr.
>
> ________________________________________
> Von: Alex Boisvert [alex.boisvert@gmail.com]
> Gesendet: Samstag, 23. Januar 2010 18:25
> An: users@buildr.apache.org
> Betreff: Re: dzone
>
> Nice article. The comments/reactions to buildr are always interesting.
>
> If I can segway for a moment... The JVM build tool landscape has certainly
> expanded much since buildr started. There are more potent choices
> available
> (e.g. Graddle and SBT). Maven2 has fixed a lot of issues from its early
> days. And now Maven3 on the way... I think it gets more difficult to get
> our message across because some of the alternatives may look similar on the
> surface and may share some/many of the features.
>
> For better or worse, a distinguishing feature of Buildr remains its ties to
> Ruby. Ruby is a great language with a rich ecosystem and a lively
> culture. It can also be perceived as 'another language to learn' or
> 'introducing yet-another language' into a project. I'd rank these fears as
> our biggest obstacle to popularity. However, these fears are irrational
> and
> as a small project I don't think there's much we can do to overcome them.
>
> Beyond the language issue, I think our two most important challenges today
> are 1) ease of installation and 2) a good story on dependency management.
> We've gotten much better on the installation side recently and I hope the
> all-in-one distro will help starting with Buildr 1.4.0.
>
> On the dependency management side, I consider what we have today very
> solid. Whitelisting dependencies has worked very well for many of us on
> big
> projects and is probably an under-appreciated feature. It's hard to
> communicate the value here without people having had bad experiences with
> other transitive dependency management approach. The seduction of
> transitive dependencies is too great -- on paper it always works
> perfectly. So if there's one thing I'd like to improve after Buildr 1.4.0
> it's our story on dependency management. We need to communicate better
> but
> also add better tooling support. I think better/tigher integration with
> Ivy
> would go a long way. There's probably other good approaches out there and
> I'd be interested in hearing about what other people think.
>
> My $0.02 on the buildr state of the union. Thanks for the article! Every
> bit of advocacy helps. Now if I could find some time to blog...
>
> alex
>
> On Thu, Jan 21, 2010 at 12:37 AM, Peter Schröder <ps...@blau.de> wrote:
>
> > hi,
> >
> > i posted a little article about buildr on dzone (
> > http://www.dzone.com/links/the_build_system_that_doesnt_suck.html).
> >
> > i hope that it will create some attention for buildr to let the community
> > grow further.
> >
> > kind regards,
> > peter
>
AW: dzone
Posted by Peter Schröder <ps...@blau.de>.
did you have a look at ivy4r (http://klaasprause.com/2009/07/12/ivy4r-using-apache-ivy-with-ruby/) ?
we are using it for all of our projects.
i think that it would be great to integrate something like that directly into buildr.
________________________________________
Von: Alex Boisvert [alex.boisvert@gmail.com]
Gesendet: Samstag, 23. Januar 2010 18:25
An: users@buildr.apache.org
Betreff: Re: dzone
Nice article. The comments/reactions to buildr are always interesting.
If I can segway for a moment... The JVM build tool landscape has certainly
expanded much since buildr started. There are more potent choices available
(e.g. Graddle and SBT). Maven2 has fixed a lot of issues from its early
days. And now Maven3 on the way... I think it gets more difficult to get
our message across because some of the alternatives may look similar on the
surface and may share some/many of the features.
For better or worse, a distinguishing feature of Buildr remains its ties to
Ruby. Ruby is a great language with a rich ecosystem and a lively
culture. It can also be perceived as 'another language to learn' or
'introducing yet-another language' into a project. I'd rank these fears as
our biggest obstacle to popularity. However, these fears are irrational and
as a small project I don't think there's much we can do to overcome them.
Beyond the language issue, I think our two most important challenges today
are 1) ease of installation and 2) a good story on dependency management.
We've gotten much better on the installation side recently and I hope the
all-in-one distro will help starting with Buildr 1.4.0.
On the dependency management side, I consider what we have today very
solid. Whitelisting dependencies has worked very well for many of us on big
projects and is probably an under-appreciated feature. It's hard to
communicate the value here without people having had bad experiences with
other transitive dependency management approach. The seduction of
transitive dependencies is too great -- on paper it always works
perfectly. So if there's one thing I'd like to improve after Buildr 1.4.0
it's our story on dependency management. We need to communicate better but
also add better tooling support. I think better/tigher integration with Ivy
would go a long way. There's probably other good approaches out there and
I'd be interested in hearing about what other people think.
My $0.02 on the buildr state of the union. Thanks for the article! Every
bit of advocacy helps. Now if I could find some time to blog...
alex
On Thu, Jan 21, 2010 at 12:37 AM, Peter Schröder <ps...@blau.de> wrote:
> hi,
>
> i posted a little article about buildr on dzone (
> http://www.dzone.com/links/the_build_system_that_doesnt_suck.html).
>
> i hope that it will create some attention for buildr to let the community
> grow further.
>
> kind regards,
> peter
Re: dzone
Posted by Alex Boisvert <al...@gmail.com>.
Nice article. The comments/reactions to buildr are always interesting.
If I can segway for a moment... The JVM build tool landscape has certainly
expanded much since buildr started. There are more potent choices available
(e.g. Graddle and SBT). Maven2 has fixed a lot of issues from its early
days. And now Maven3 on the way... I think it gets more difficult to get
our message across because some of the alternatives may look similar on the
surface and may share some/many of the features.
For better or worse, a distinguishing feature of Buildr remains its ties to
Ruby. Ruby is a great language with a rich ecosystem and a lively
culture. It can also be perceived as 'another language to learn' or
'introducing yet-another language' into a project. I'd rank these fears as
our biggest obstacle to popularity. However, these fears are irrational and
as a small project I don't think there's much we can do to overcome them.
Beyond the language issue, I think our two most important challenges today
are 1) ease of installation and 2) a good story on dependency management.
We've gotten much better on the installation side recently and I hope the
all-in-one distro will help starting with Buildr 1.4.0.
On the dependency management side, I consider what we have today very
solid. Whitelisting dependencies has worked very well for many of us on big
projects and is probably an under-appreciated feature. It's hard to
communicate the value here without people having had bad experiences with
other transitive dependency management approach. The seduction of
transitive dependencies is too great -- on paper it always works
perfectly. So if there's one thing I'd like to improve after Buildr 1.4.0
it's our story on dependency management. We need to communicate better but
also add better tooling support. I think better/tigher integration with Ivy
would go a long way. There's probably other good approaches out there and
I'd be interested in hearing about what other people think.
My $0.02 on the buildr state of the union. Thanks for the article! Every
bit of advocacy helps. Now if I could find some time to blog...
alex
On Thu, Jan 21, 2010 at 12:37 AM, Peter Schröder <ps...@blau.de> wrote:
> hi,
>
> i posted a little article about buildr on dzone (
> http://www.dzone.com/links/the_build_system_that_doesnt_suck.html).
>
> i hope that it will create some attention for buildr to let the community
> grow further.
>
> kind regards,
> peter
dzone
Posted by Peter Schröder <ps...@blau.de>.
hi,
i posted a little article about buildr on dzone (http://www.dzone.com/links/the_build_system_that_doesnt_suck.html).
i hope that it will create some attention for buildr to let the community grow further.
kind regards,
peter