On 08/12/09 3:34 PM, Alex Boisvert wrote:
> On Tue, Dec 8, 2009 at 12:00 PM, Jeremy Huiskamp<
> jeremy.huiskamp@karoshealth.com> wrote:
>
>
>> I've noticed that the pom.xml generated by the upload task and placed in
>> the target maven repository doesn't include dependency information, which is
>> kind of a pain when my maven-using colleagues want to use libraries I've
>> built with buildr and they have to go and list all of my dependencies
>> explicitly. Can the pom generation include a list of artifacts and, if so,
>> how can I specify it? I'd be fine with handcrafting a pom.xml and having
>> the task use that instead of a generated one but doing it in the buildfile
>> would be nicer.
>>
>>
> To provide your own pom.xml:
>
> package(:jar).pom.from _("pom.xml")
>
> If you want to craft a pom from within your buildfile, do can do something
> along the lines of
>
> file("target/pom.xml") do |file|
> pkg = package(:jar)
> File.open(file.to_s, 'w') do |file|
> xml = Builder::XmlMarkup.new(:target=>file, :indent=>2)
> xml.project do
> xml.modelVersion '4.0.0'
> xml.groupId pkg.group
> xml.artifactId pkg.id
> xml.version pkg.version
> # add more information ...
> end
> end
> end
> package(:jar).pom.from _("target/pom.xml")
>
> Hope this helps,
> alex
>
>
Great, thanks. That should get me where I need to go.
nice! Am 08.12.2009 um 22:33 schrieb Alex Boisvert: > FYI, the github mirror is now up to date :) > > http://github.com/apache/buildr > > (Well, more or less, there's still a lag of one hour or something like that) > > alex > > On Tue, Nov 17, 2009 at 3:46 PM, Rhett Sutphin <rhett@detailedbalance.net>wrote: > >> Hi Peter, >> >> >> On Nov 17, 2009, at 2:49 PM, Peter Schröder wrote: >> >> hi antoine, >>> >>> i am currently using the apache mirror right after noticing that the one >>> on github is out of sync. >>> >>> but i have some problems with that: >>> >>> 1. i like github and contributing/sharing code on it with my collegues >>> >> >> Agree. >> >> >> 2. i dont know how to keep my buildr fork on github in sync with the >>> apache-buildr repo painlessly >>> >> >> You can do this with multiple remotes on your local repo. I haven't done >> it myself, but I believe someone outlined the process on the mailing list a >> while back. >> >> >> 3. i would like to use github for pulling changes instead of opening up >>> tickets in jira (currently 104 issues) >>> >> >> If you want to submit code to buildr you will have to eventually submit a >> patch in JIRA. As I understand it, the Apache Foundation requires this to >> make explicit that you are granting a license to incorporate your code into >> buildr. >> >> I agree, though, that making your changes available on github first and >> discussing them on the mailing list is a better way of getting feedback than >> enhancement requests in JIRA. >> >> Rhett >> >> >> 4. i dont think that the documentation should encourage using the github >>> repo as long as its out of sync! >>> >>> i commented on your ticket and i hope that we can reuse github for this >>> one soon. >>> >>> kind regards, >>> peter >>> ________________________________________ >>> Von: antoine.toulme@gmail.com [antoine.toulme@gmail.com] im Auftrag von >>> Antoine Toulme [antoine@lunar-ocean.com] >>> Gesendet: Dienstag, 17. November 2009 20:54 >>> An: users@buildr.apache.org >>> Betreff: Re: documentation about git on github and buildr >>> >>> Hey Peter, >>> >>> I fork the git repository from the Apache mirror directly: >>> git://git.apache.org/buildr.git >>> >>> <git://git.apache.org/buildr.git>Yep, the github mirror is outdated and I >>> had opened a ticket about it: >>> >>> http://support.github.com/discussions/repos/1568-apache-buildr-mirror-is-out-of-date >>> >>> Please feel free to weigh in! >>> >>> Antoine >>> >>> On Tue, Nov 17, 2009 at 11:40, Peter Schröder <Peter.Schroeder@blau.de >>>> wrote: >>> >>> there is some documentation under 'contributing' about how to use github >>>> for helping contributing code for buildr. >>>> >>>> is this still up to date? the github repo is outdated and i dont think >>>> that >>>> i would like to work on that one for my contributions... >>>> >>> >>
On Tue, Dec 8, 2009 at 5:55 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: > OK I just tried, it worked for me. > Cool! > For some reason rake -T doesn't return all-in-one ? > Fixed. alex
OK I just tried, it worked for me. For some reason rake -T doesn't return all-in-one ? Cheers, Antoine On Tue, Dec 8, 2009 at 17:40, Alex Boisvert <alex.boisvert@gmail.com> wrote: > On Tue, Dec 8, 2009 at 4:12 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: > >> >> Do you mind sharing how you bundled jruby with buildr ? Do you have a >>>> script for that ? >>>> >>> >>> I don't have a script yet; I just whipped it out manually. >>> >>> I'll add it to Buildr's rakefile now(ish). >>> >> > Ok, committed a first shot. Try "rake all-in-one". I'm curious to know if > it runs on MacOS. And there's probably more cleanup to do... far from > ready for a release but good enough to get the ball rolling. > > alex > >
On Tue, Dec 8, 2009 at 4:12 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: > > Do you mind sharing how you bundled jruby with buildr ? Do you have a >>> script for that ? >>> >> >> I don't have a script yet; I just whipped it out manually. >> >> I'll add it to Buildr's rakefile now(ish). >> > Ok, committed a first shot. Try "rake all-in-one". I'm curious to know if it runs on MacOS. And there's probably more cleanup to do... far from ready for a release but good enough to get the ball rolling. alex
On Tue, Dec 8, 2009 at 16:11, Alex Boisvert <alex.boisvert@gmail.com> wrote: > On Tue, Dec 8, 2009 at 3:51 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: > >> >> >> On Tue, Dec 8, 2009 at 15:43, Alex Boisvert <alex.boisvert@gmail.com>wrote: >> >>> On Tue, Dec 8, 2009 at 3:14 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: >>> >>>> I have been working a bit with the standalone distrib of Buildr mounted >>>> on >>>> JRuby and I liked it so far, I think it offers a very simple way to have >>>> buildr around. >>>> >>> >>> Good to hear. >>> >>> I had the need to install gems on that jruby installation and my quick >>>> fix >>>> was to edit the buildr executable, remove the mention of _buildr, run: >>>> buildr gem install mygem >>>> >>> >>> That's the kind of feedback I was hoping for :) >>> >>> >>>> Two questions: >>>> 1. Can we have a way to install Buildr gems as part of Buildr in an easy >>>> way? >>>> >>> >>> Yes, we could leave the original jruby executable/scripts in the distro >>> for that purpose. >>> >> Indeed. >> >>> >>> >>>> 2. Can we prepackage Buildr with one or more plugins and distribute it >>>> that >>>> way ? Either on apache.org or at the plugin website ? If yes, what >>>> would be >>>> the instructions to do that ? >>>> >>> >>> Possible but I'd personally rather do #1. Sooner or later you want to >>> add another plugin and I'd rather avoid the combinational explosion of >>> distros. >>> >> After giving it some more thought, I think in that case, such a distro >> would not be buildr anymore. Buildr would be bundled in there, but the >> distro would be something else. >> Do you mind sharing how you bundled jruby with buildr ? Do you have a >> script for that ? >> > > I don't have a script yet; I just whipped it out manually. > > I'll add it to Buildr's rakefile now(ish). > ok(ish) Thanks! > > alex >
On Tue, Dec 8, 2009 at 3:51 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: > > > On Tue, Dec 8, 2009 at 15:43, Alex Boisvert <alex.boisvert@gmail.com>wrote: > >> On Tue, Dec 8, 2009 at 3:14 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: >> >>> I have been working a bit with the standalone distrib of Buildr mounted >>> on >>> JRuby and I liked it so far, I think it offers a very simple way to have >>> buildr around. >>> >> >> Good to hear. >> >> I had the need to install gems on that jruby installation and my quick fix >>> was to edit the buildr executable, remove the mention of _buildr, run: >>> buildr gem install mygem >>> >> >> That's the kind of feedback I was hoping for :) >> >> >>> Two questions: >>> 1. Can we have a way to install Buildr gems as part of Buildr in an easy >>> way? >>> >> >> Yes, we could leave the original jruby executable/scripts in the distro >> for that purpose. >> > Indeed. > >> >> >>> 2. Can we prepackage Buildr with one or more plugins and distribute it >>> that >>> way ? Either on apache.org or at the plugin website ? If yes, what would >>> be >>> the instructions to do that ? >>> >> >> Possible but I'd personally rather do #1. Sooner or later you want to >> add another plugin and I'd rather avoid the combinational explosion of >> distros. >> > After giving it some more thought, I think in that case, such a distro > would not be buildr anymore. Buildr would be bundled in there, but the > distro would be something else. > Do you mind sharing how you bundled jruby with buildr ? Do you have a > script for that ? > I don't have a script yet; I just whipped it out manually. I'll add it to Buildr's rakefile now(ish). alex
On Tue, Dec 8, 2009 at 15:43, Alex Boisvert <alex.boisvert@gmail.com> wrote: > On Tue, Dec 8, 2009 at 3:14 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: > >> I have been working a bit with the standalone distrib of Buildr mounted on >> JRuby and I liked it so far, I think it offers a very simple way to have >> buildr around. >> > > Good to hear. > > I had the need to install gems on that jruby installation and my quick fix >> was to edit the buildr executable, remove the mention of _buildr, run: >> buildr gem install mygem >> > > That's the kind of feedback I was hoping for :) > > >> Two questions: >> 1. Can we have a way to install Buildr gems as part of Buildr in an easy >> way? >> > > Yes, we could leave the original jruby executable/scripts in the distro for > that purpose. > Indeed. > > >> 2. Can we prepackage Buildr with one or more plugins and distribute it >> that >> way ? Either on apache.org or at the plugin website ? If yes, what would >> be >> the instructions to do that ? >> > > Possible but I'd personally rather do #1. Sooner or later you want to add > another plugin and I'd rather avoid the combinational explosion of distros. > After giving it some more thought, I think in that case, such a distro would not be buildr anymore. Buildr would be bundled in there, but the distro would be something else. Do you mind sharing how you bundled jruby with buildr ? Do you have a script for that ? Thanks, Antoine
On Tue, Dec 8, 2009 at 3:14 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: > I have been working a bit with the standalone distrib of Buildr mounted on > JRuby and I liked it so far, I think it offers a very simple way to have > buildr around. > Good to hear. I had the need to install gems on that jruby installation and my quick fix > was to edit the buildr executable, remove the mention of _buildr, run: > buildr gem install mygem > That's the kind of feedback I was hoping for :) > Two questions: > 1. Can we have a way to install Buildr gems as part of Buildr in an easy > way? > Yes, we could leave the original jruby executable/scripts in the distro for that purpose. > 2. Can we prepackage Buildr with one or more plugins and distribute it that > way ? Either on apache.org or at the plugin website ? If yes, what would > be > the instructions to do that ? > Possible but I'd personally rather do #1. Sooner or later you want to add another plugin and I'd rather avoid the combinational explosion of distros. alex
Hi guys, I have been working a bit with the standalone distrib of Buildr mounted on JRuby and I liked it so far, I think it offers a very simple way to have buildr around. I had the need to install gems on that jruby installation and my quick fix was to edit the buildr executable, remove the mention of _buildr, run: buildr gem install mygem Two questions: 1. Can we have a way to install Buildr gems as part of Buildr in an easy way ? 2. Can we prepackage Buildr with one or more plugins and distribute it that way ? Either on apache.org or at the plugin website ? If yes, what would be the instructions to do that ? Thanks, Antoine
FYI, the github mirror is now up to date :) http://github.com/apache/buildr (Well, more or less, there's still a lag of one hour or something like that) alex On Tue, Nov 17, 2009 at 3:46 PM, Rhett Sutphin <rhett@detailedbalance.net>wrote: > Hi Peter, > > > On Nov 17, 2009, at 2:49 PM, Peter Schröder wrote: > > hi antoine, >> >> i am currently using the apache mirror right after noticing that the one >> on github is out of sync. >> >> but i have some problems with that: >> >> 1. i like github and contributing/sharing code on it with my collegues >> > > Agree. > > > 2. i dont know how to keep my buildr fork on github in sync with the >> apache-buildr repo painlessly >> > > You can do this with multiple remotes on your local repo. I haven't done > it myself, but I believe someone outlined the process on the mailing list a > while back. > > > 3. i would like to use github for pulling changes instead of opening up >> tickets in jira (currently 104 issues) >> > > If you want to submit code to buildr you will have to eventually submit a > patch in JIRA. As I understand it, the Apache Foundation requires this to > make explicit that you are granting a license to incorporate your code into > buildr. > > I agree, though, that making your changes available on github first and > discussing them on the mailing list is a better way of getting feedback than > enhancement requests in JIRA. > > Rhett > > > 4. i dont think that the documentation should encourage using the github >> repo as long as its out of sync! >> >> i commented on your ticket and i hope that we can reuse github for this >> one soon. >> >> kind regards, >> peter >> ________________________________________ >> Von: antoine.toulme@gmail.com [antoine.toulme@gmail.com] im Auftrag von >> Antoine Toulme [antoine@lunar-ocean.com] >> Gesendet: Dienstag, 17. November 2009 20:54 >> An: users@buildr.apache.org >> Betreff: Re: documentation about git on github and buildr >> >> Hey Peter, >> >> I fork the git repository from the Apache mirror directly: >> git://git.apache.org/buildr.git >> >> <git://git.apache.org/buildr.git>Yep, the github mirror is outdated and I >> had opened a ticket about it: >> >> http://support.github.com/discussions/repos/1568-apache-buildr-mirror-is-out-of-date >> >> Please feel free to weigh in! >> >> Antoine >> >> On Tue, Nov 17, 2009 at 11:40, Peter Schröder <Peter.Schroeder@blau.de >> >wrote: >> >> there is some documentation under 'contributing' about how to use github >>> for helping contributing code for buildr. >>> >>> is this still up to date? the github repo is outdated and i dont think >>> that >>> i would like to work on that one for my contributions... >>> >> >
On Tue, Dec 8, 2009 at 12:00 PM, Jeremy Huiskamp <
jeremy.huiskamp@karoshealth.com> wrote:
> I've noticed that the pom.xml generated by the upload task and placed in
> the target maven repository doesn't include dependency information, which is
> kind of a pain when my maven-using colleagues want to use libraries I've
> built with buildr and they have to go and list all of my dependencies
> explicitly. Can the pom generation include a list of artifacts and, if so,
> how can I specify it? I'd be fine with handcrafting a pom.xml and having
> the task use that instead of a generated one but doing it in the buildfile
> would be nicer.
>
To provide your own pom.xml:
package(:jar).pom.from _("pom.xml")
If you want to craft a pom from within your buildfile, do can do something
along the lines of
file("target/pom.xml") do |file|
pkg = package(:jar)
File.open(file.to_s, 'w') do |file|
xml = Builder::XmlMarkup.new(:target=>file, :indent=>2)
xml.project do
xml.modelVersion '4.0.0'
xml.groupId pkg.group
xml.artifactId pkg.id
xml.version pkg.version
# add more information ...
end
end
end
package(:jar).pom.from _("target/pom.xml")
Hope this helps,
alex
I've noticed that the pom.xml generated by the upload task and placed in the target maven repository doesn't include dependency information, which is kind of a pain when my maven-using colleagues want to use libraries I've built with buildr and they have to go and list all of my dependencies explicitly. Can the pom generation include a list of artifacts and, if so, how can I specify it? I'd be fine with handcrafting a pom.xml and having the task use that instead of a generated one but doing it in the buildfile would be nicer. Thanks, Jeremy
Hi,
I have a build script which uses this stanza to enable JSP compilation on Jetty:
Java.classpath.concat([
"org.mortbay.jetty:jsp-api-2.1:jar:#{Buildr::Jetty::VERSION}",
"org.mortbay.jetty:jsp-2.1:jar:#{Buildr::Jetty::VERSION}"
])
It works fine on Java 5 (1.5.0_20 on OS X 10.5) but on Java 6 (1.6.0_17[1] on OS X 10.6),
I get compilation failure exceptions from jasper. There's circumstantial evidence that it's
a javac problem -- the exceptions indicate that certain classes and methods derived from compiling
some JSP tagfiles don't exist. The classfiles themselves exist (and seem to be in the right
place) but I can't get any decompiler to decompile them.
I've just started looking into it, but I thought I'd ask to see if anyone else had run into
this problem and could offer a pointer.
Thanks,
Rhett
[1]: It also failed on the previous version of Java 6 on Snow Leopard.
I've been successful with the "all-in-one" JRuby 1.4.0 + Buildr 1.3.5 distro http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip Haven't tried the manual install on Windows. alex On Thu, Dec 3, 2009 at 1:04 PM, Shane Witbeck <shane@digitalsanctum.com>wrote: > Has anyone been able to install buildr via the latest jruby 1.4.0 on > windows? I'm getting the following even after installing > jruby-openssl: > > C:\installs>jruby -S gem install buildr > JRuby limited openssl loaded. gem install jruby-openssl for full support. > http://jruby.kenai.com/pages/JRuby_Builtin_OpenSSL > C:/jruby-1.4.0/lib/ruby/site_ruby/shared/jruby/openssl/autoloads/ssl.rb:8: > OpenSSL::SSL requires the > jruby-openssl gem (LoadError) > from > C:/jruby-1.4.0/lib/ruby/site_ruby/shared/jruby/openssl/autoloads/ssl.rb:124:in > `use_ssl > =' > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:242:in > `connection_for > ' > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:320:in > `request' > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:279:in > `open_uri_or_pa > th' > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:288:in > `open_uri_or_pa > th' > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:164:in > `fetch_path' > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:108:in > `download' > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in > `install' > > ... 7 levels... > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in > `run' > from > C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in > `run' > from C:/jruby-1.4.0/bin/gem:24 > > -Shane >
Has anyone been able to install buildr via the latest jruby 1.4.0 on
windows? I'm getting the following even after installing
jruby-openssl:
C:\installs>jruby -S gem install buildr
JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://jruby.kenai.com/pages/JRuby_Builtin_OpenSSL
C:/jruby-1.4.0/lib/ruby/site_ruby/shared/jruby/openssl/autoloads/ssl.rb:8:
OpenSSL::SSL requires the
jruby-openssl gem (LoadError)
from C:/jruby-1.4.0/lib/ruby/site_ruby/shared/jruby/openssl/autoloads/ssl.rb:124:in
`use_ssl
='
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:242:in
`connection_for
'
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:320:in
`request'
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:279:in
`open_uri_or_pa
th'
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:288:in
`open_uri_or_pa
th'
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:164:in
`fetch_path'
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:108:in
`download'
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in
`install'
... 7 levels...
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in
`run'
from C:/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in
`run'
from C:/jruby-1.4.0/bin/gem:24
-Shane
hi sebastian, i am currently scraping the documentation for bugs and there is an open ticket for this: https://issues.apache.org/jira/browse/BUILDR-345 i will propose a patch if you like. there are also some working examples in the buildr-wiki: http://cwiki.apache.org/confluence/display/BUILDR/Buildr+HowTos and i started a little example project on github that are based on the examples provided in the docs: http://github.com/phoet/buildr-examples kind regards, peter Am 03.12.2009 um 16:01 schrieb Sebastian Hennebrueder: > Hello, > > the page http://buildr.apache.org/quick_start.html#custom-tasks has two bugs > > should use > Project.local_task :deploy > instead of just local_task > and > project.version '0.1.0' > should be > project.version='0.1.0' > > -- > Best Regards / Viele Grüße > > Sebastian Hennebrueder > ----- > Software Developer and Trainer for Hibernate / Java Persistence > http://www.laliluna.de > > >
Hello, the page http://buildr.apache.org/quick_start.html#custom-tasks has two bugs should use Project.local_task :deploy instead of just local_task and project.version '0.1.0' should be project.version='0.1.0' -- Best Regards / Viele GrĆ¼Će Sebastian Hennebrueder ----- Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de
Nifty! Very nice work. Daniel On Wed, Dec 2, 2009 at 9:20 PM, Antoine Toulme <antoine@lunar-ocean.com>wrote: > Hi all, > > I just made available a cool Buildr extension that packages a .exe Win32 > installer using makeNSIS. > > The code is located here: > http://github.com/intalio/package_as_exe > > The first gem was just pushed to gemcutter: > http://gemcutter.org/gems/buildr-package-as-exe > > I'll add it to the wiki. Contributions, remarks, critics are most welcome. > > Thanks, > > Antoine >
Hi all, I just made available a cool Buildr extension that packages a .exe Win32 installer using makeNSIS. The code is located here: http://github.com/intalio/package_as_exe The first gem was just pushed to gemcutter: http://gemcutter.org/gems/buildr-package-as-exe I'll add it to the wiki. Contributions, remarks, critics are most welcome. Thanks, Antoine
Yes, I would be quite interested in integrating your enhancements. We
should try to remain backward compatible with the existing transitive() but
apart from that, the field is pretty open for improvements. Give it your
best shot!
alex
On Wed, Dec 2, 2009 at 3:27 PM, Sebastian Hennebrueder
<usenet@laliluna.de>wrote:
> Hello
>
> I started to use buildr and was slightly annoyed by the limited maven
> support.
>
> Apart from not resolving properly, I had poms which couldn't be parsed. I
> switched the parser to Nokogiri and improved the code to deliver better
> results.
>
> Well it does work know but I run into the next big problem:
>
> The transitive methods split up a hash of dependencies and resolves them
> individually. Naturally this doesn't work because I need to know all
> dependencies to avoid duplicate instances.
>
> The consequence is that I have to change the API. It could look like the
> following code snippet. Before I start working on this, is there interest to
> integrate this or is there anybody working on something like this?
>
> MY_DEPS = maven do
> add("org.hibernate:hibernate-ehcache:jar:3.3.2.GA:
> compile").transient.exclude("foo:bar")
> add({ :groupId=>"org.hibernate", :artifactId =>"hibernate-ehcache",
> :version=>"3.3.2.GA", :scope=> "compile"}).transient
> add("foo:bar:1.0").exclude('foo:*') end
> define 'laliluna' do
> project.version = '1.1'
> package :jar
> compile.with MY_DEPS
> end
>
> --
> Best Regards / Viele Grüße
>
> Sebastian Hennebrueder
> -----
> Software Developer and Trainer for Hibernate / Java Persistence
> http://www.laliluna.de
>
>
>
>
Hello
I started to use buildr and was slightly annoyed by the limited maven
support.
Apart from not resolving properly, I had poms which couldn't be parsed.
I switched the parser to Nokogiri and improved the code to deliver
better results.
Well it does work know but I run into the next big problem:
The transitive methods split up a hash of dependencies and resolves them
individually. Naturally this doesn't work because I need to know all
dependencies to avoid duplicate instances.
The consequence is that I have to change the API. It could look like the
following code snippet. Before I start working on this, is there
interest to integrate this or is there anybody working on something like
this?
MY_DEPS = maven do
add("org.hibernate:hibernate-ehcache:jar:3.3.2.GA:compile").transient.exclude("foo:bar")
add({ :groupId=>"org.hibernate", :artifactId =>"hibernate-ehcache",
:version=>"3.3.2.GA", :scope=> "compile"}).transient
add("foo:bar:1.0").exclude('foo:*')
end
define 'laliluna' do
project.version = '1.1'
package :jar
compile.with MY_DEPS
end
--
Best Regards / Viele GrĆ¼Će
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
-----Original Message-----
From: Alex Boisvert [mailto:alex.boisvert@gmail.com]
Sent: Monday, 30 November 2009 4:27 PM
To: users@buildr.apache.org
Subject: Re: Depoying emma enchanced classes.
You can create an alternate packaging with instrumented classes, for
example:
package(:jar, :classifier => 'instrumented').tap do |pkg|
pkg.include _('target/instrumented/classes'), :as => '.'
end
alex
Many Thanks..
Cheers Megan
You can create an alternate packaging with instrumented classes, for
example:
package(:jar, :classifier => 'instrumented').tap do |pkg|
pkg.include _('target/instrumented/classes'), :as => '.'
end
alex
On Sun, Nov 29, 2009 at 2:05 PM, Megan Woods <megan_woods@toll.com.au>wrote:
> Hi,
>
> Basically I am attempting do code coverage on some in-container integration
> tests.
>
> How can I get Buildr to deploy the enchanced packages.?
>
> or
>
> Is there a way I can intercept the package task so I could create somthing
> along the lines of a pre or post package task.?
>
>
> Cheers Megan
>
>
>
>
An error occured while fetching this message, sorry !
Looks good to me. I normally set things up to use svn+ssh with ssh keys to
avoid having to manage passwords for continuous integration builds.
If you can open a Jira issue and attach your code, I'll merge it into the
codebase.
thanks,
alex
On Fri, Nov 27, 2009 at 3:31 AM, Danny O'Connor
<danny.oconnor@propylon.com>wrote:
> Hi All,
>
> When you're using buildr with the hudson continuous integration server, the
> 'release' task won't work because buildr needs a credential for svn. This
> would probably happen in any situation where you don't cached authentication
> for svn servers.
>
> A quick patch is to allow svn username and password be set as environment
> variables like so:
>
> # Modified to allow usernames/passwords for svn
> module Buildr
> module Svn
> module_function
> def svn(*args)
> if ENV["svn_username"] and ENV["svn_password"] then
> svn_command = "svn --username #{ENV["svn_username"]} --password
> #{ENV["svn_password"]} #{args.shift} #{args.map { |arg| arg.inspect }.join('
> ')}"
> else
> svn_command = "svn #{args.shift} #{args.map { |arg| arg.inspect
> }.join(' ')}"
> end
> output = `#{svn_command}`
> fail "SVN command failed with status #{$?.exitstatus}" unless
> $?.exitstatus == 0
> return output
> end
> end
> end
>
>
> I'm not sure if this is entirely correct though.
>
> Regards,
> Danny.
>
>
Neat! I added this to our How-To section.
http://cwiki.apache.org/confluence/display/BUILDR/How+to+include+dependencies+in+.jar+packages
Thanks for sharing.
alex
On Fri, Nov 27, 2009 at 4:31 AM, Levin Alexander
<levin.alexander@gmail.com>wrote:
> On Fri, Nov 27, 2009 at 9:44 AM, tommycli <tommycli@ucla.edu> wrote:
> >
> > I use buildr with the transitive compile.with artifact specifications.
> >
> > My problem is this: After buildr makes its package, I have a nice JAR
> file,
> > but I cannot run it without its dependency JARs.
> >
> > I don't even know which JARs it depends on. How do you find out which
> JARs
> > you need to distribute with your project? Can buildr package all of it
> into
> > one file?
>
> I am using autojar with builder to find and bundle dependencies to the Jar:
>
> def add_dependencies(pkg)
> tempfile = pkg.to_s.sub(/.jar$/, "-without-dependencies.jar")
> mv pkg.to_s, tempfile
>
> dependencies = compile.dependencies.map { |d| "-c #{d}"}.join(" ")
> sh "java -jar tools/autojar.jar -baev -o #{pkg} #{dependencies}
> #{tempfile}"
> end
>
> package(:jar).enhance { |pkg| pkg.enhance { |pkg| add_dependencies(pkg) }}
>
> <
> http://stackoverflow.com/questions/1279419/buildr-package-dependencies-into-a-single-jar/1285293#1285293
> >
>
> this is a hack and potentially has problems (it uses autojar's
> dependency resolution mechanism and therefore cannot find dynamically
> added dependencies) but for us it works quite well in practice.
>
> -Levin
>
On Fri, Nov 27, 2009 at 9:44 AM, tommycli <tommycli@ucla.edu> wrote:
>
> I use buildr with the transitive compile.with artifact specifications.
>
> My problem is this: After buildr makes its package, I have a nice JAR file,
> but I cannot run it without its dependency JARs.
>
> I don't even know which JARs it depends on. How do you find out which JARs
> you need to distribute with your project? Can buildr package all of it into
> one file?
I am using autojar with builder to find and bundle dependencies to the Jar:
def add_dependencies(pkg)
tempfile = pkg.to_s.sub(/.jar$/, "-without-dependencies.jar")
mv pkg.to_s, tempfile
dependencies = compile.dependencies.map { |d| "-c #{d}"}.join(" ")
sh "java -jar tools/autojar.jar -baev -o #{pkg} #{dependencies} #{tempfile}"
end
package(:jar).enhance { |pkg| pkg.enhance { |pkg| add_dependencies(pkg) }}
<http://stackoverflow.com/questions/1279419/buildr-package-dependencies-into-a-single-jar/1285293#1285293>
this is a hack and potentially has problems (it uses autojar's
dependency resolution mechanism and therefore cannot find dynamically
added dependencies) but for us it works quite well in practice.
-Levin
Hi All,
When you're using buildr with the hudson continuous integration server,
the 'release' task won't work because buildr needs a credential for svn.
This would probably happen in any situation where you don't cached
authentication for svn servers.
A quick patch is to allow svn username and password be set as
environment variables like so:
# Modified to allow usernames/passwords for svn
module Buildr
module Svn
module_function
def svn(*args)
if ENV["svn_username"] and ENV["svn_password"] then
svn_command = "svn --username #{ENV["svn_username"]} --password
#{ENV["svn_password"]} #{args.shift} #{args.map { |arg| arg.inspect
}.join(' ')}"
else
svn_command = "svn #{args.shift} #{args.map { |arg| arg.inspect
}.join(' ')}"
end
output = `#{svn_command}`
fail "SVN command failed with status #{$?.exitstatus}" unless
$?.exitstatus == 0
return output
end
end
end
I'm not sure if this is entirely correct though.
Regards,
Danny.
I use buildr with the transitive compile.with artifact specifications. My problem is this: After buildr makes its package, I have a nice JAR file, but I cannot run it without its dependency JARs. I don't even know which JARs it depends on. How do you find out which JARs you need to distribute with your project? Can buildr package all of it into one file? Tommy -- View this message in context: http://old.nabble.com/Including-dependencies-with-a-JAR-package-tp26537708p26537708.html Sent from the Buildr - User mailing list archive at Nabble.com.
i think that we wont do this right now, cause cobertura-coverage is not interesting in our system-test-setup, so we just ignore them when test.options[:integration] is set. i will report back if we come back to this issue in the next month. ________________________________________ Von: Alex Boisvert [alex.boisvert@gmail.com] Gesendet: Donnerstag, 26. November 2009 20:21 An: users@buildr.apache.org Betreff: Re: cobertura tasks and test.using :integration On Wed, Nov 25, 2009 at 10:36 PM, Peter Schröder <ps@blau.de> wrote: > you mean a self-defined task with a zip-task to create the report-artifact? > yes. > we probably would need to create some other kind of top-level > package-report task, because we join all created reports (cobertura, junit, > javadoc...) into one big reports-zip and upload this to our bamboo-server, > so that we can attach all reports to a build. > yes, that would be very nice. if you implement this, I would be very interested in bringing it into buildr. alex
On Wed, Nov 25, 2009 at 10:36 PM, Peter Schröder <ps@blau.de> wrote: > you mean a self-defined task with a zip-task to create the report-artifact? > yes. > we probably would need to create some other kind of top-level > package-report task, because we join all created reports (cobertura, junit, > javadoc...) into one big reports-zip and upload this to our bamboo-server, > so that we can attach all reports to a build. > yes, that would be very nice. if you implement this, I would be very interested in bringing it into buildr. alex
you mean a self-defined task with a zip-task to create the report-artifact? we probably would need to create some other kind of top-level package-report task, because we join all created reports (cobertura, junit, javadoc...) into one big reports-zip and upload this to our bamboo-server, so that we can attach all reports to a build. Am 25.11.2009 um 20:58 schrieb Alex Boisvert: > Create a package task for the cobertura reports (which is not a dependency > of :package) and add it as a dependency of :upload ? > > On Nov 25, 2009 4:54 AM, "Peter Schröder" <ps@blau.de> wrote: > > hi, > > we have an issue regarding the order of task when running cobertura-tasks in > the test-integration mode. > > we want to package the cobertura-results, so that an reports-artifact can be > created and uploaded, but the package task needs to be run before the > test-integration setup and teardown. but the cobertura task needs to run the > tests... > > any ideas?
Create a package task for the cobertura reports (which is not a dependency of :package) and add it as a dependency of :upload ? On Nov 25, 2009 4:54 AM, "Peter Schröder" <ps@blau.de> wrote: hi, we have an issue regarding the order of task when running cobertura-tasks in the test-integration mode. we want to package the cobertura-results, so that an reports-artifact can be created and uploaded, but the package task needs to be run before the test-integration setup and teardown. but the cobertura task needs to run the tests... any ideas?
hi, we have an issue regarding the order of task when running cobertura-tasks in the test-integration mode. we want to package the cobertura-results, so that an reports-artifact can be created and uploaded, but the package task needs to be run before the test-integration setup and teardown. but the cobertura task needs to run the tests... any ideas?
In case anyone else hits this: The error is misleading, see <http://rubyforge.org/tracker/?func=detail&aid=23981&group_id=274&atid=1125> I applied the patch to get a better error message, now at least I get Net::SSH::AuthenticationFailed Not sure what changed to cause this, but it's a start. (I get a different error running on windows, but that seems to be a known issue with jruby/ssh). On Tue, 24 Nov 2009 12:19:07 -0500, Greg Lucas <greg.lucas@gmail.com> wrote: > I have a build that uses SFTP to upload to a maven repo. This was > working at one point, but since updating from buildr 1.2.10 to buildr > 1.3.5 + JRuby 1.4 I'm getting the following: > > undefined method `shutdown!' for nil:NilClass > > Looks like Net::SSH.start is returning a nil session, the trace is: > >> buildr-1.3.5-jruby-1.4.0/lib/ruby/gems/1.8/gems/net-sftp-2.0.2/lib/net/sftp.rb:43:in >> `start' >> buildr-1.3.5-jruby-1.4.0/lib/ruby/gems/1.8/gems/buildr-1.3.5-java/lib/buildr/core/transports.rb:442:in >> `write_internal' > > Has anyone else run in to this? > > Thanks, > -- Greg Lucas
I have a build that uses SFTP to upload to a maven repo. This was working at one point, but since updating from buildr 1.2.10 to buildr 1.3.5 + JRuby 1.4 I'm getting the following: undefined method `shutdown!' for nil:NilClass Looks like Net::SSH.start is returning a nil session, the trace is: > buildr-1.3.5-jruby-1.4.0/lib/ruby/gems/1.8/gems/net-sftp-2.0.2/lib/net/sftp.rb:43:in > `start' > buildr-1.3.5-jruby-1.4.0/lib/ruby/gems/1.8/gems/buildr-1.3.5-java/lib/buildr/core/transports.rb:442:in > `write_internal' Has anyone else run in to this? Thanks, -- Greg Lucas
Yea basically I get the full java command line dumped to stdout.. Thanks for your help. Cheers Megan -----Original Message----- From: Alex Boisvert [mailto:alex.boisvert@gmail.com] Sent: Tuesday, 24 November 2009 2:44 AM To: users@buildr.apache.org Subject: Re: Reducing Java::Commands:Java output Yes, a few people have noticed this. Looks like it's coming from Rake. I'll look into it. alex On Sun, Nov 22, 2009 at 3:23 PM, Megan Woods <megan_woods@toll.com.au>wrote: > Hi all, > > Is it possible to stop Java::Commands:Java from producing so much output.? > > I have been digging through the buildr source code and can confirm > that the following are: > > Buildr.application.options.trace is nil > :verbose is false > > which I have confirmed by putting puts statements in the appropriate > places within \lib\buildr\java\commands.rb > > Buildr version is: > > buildr-1.3.5-x86-mswin32 > > Cheers Megan > > > >
Ok, I've changed this.
Here's how things work now,
1) $HOME/.buildr/buildr.rb is now loaded in preference.
2) If $HOME/.buildr/buildr.rb doesn't exist, $HOME/buildr.rb is loaded and a
deprecation warning is printed.
If you still use prior versions of Buildr and you don't want to duplicate
the content of your buildr.rb file, you can move you existing
$HOME/buildr.rb to $HOME/.buildr/buildr.b and create a new $HOME/buildr.rb
containing:
# Backward compatibility: Buildr 1.4+ uses $HOME/.buildr/buildr.rb
load File.expand_path('buildr.rb', Buildr.application.home_dir)
alex
On Sun, Nov 22, 2009 at 12:01 PM, Peter Schröder <ps@blau.de> wrote:
> oh, i didn't know that yet...
>
> so putting the file in there would be fine too.
> ________________________________________
> Von: Alex Boisvert [alex.boisvert@gmail.com]
> Gesendet: Sonntag, 22. November 2009 18:24
> An: users@buildr.apache.org
> Betreff: Re: default buildr.rb
>
> I agree it's clutter.
>
> Since we already use the ~/.buildr directory, why not move it into that
> directory?
>
> alex
>
> On Sun, Nov 22, 2009 at 8:49 AM, Peter Schröder <ps@blau.de> wrote:
>
> > i would like the default buildr include (~/buildr.rb) to be a hidden file
> > .buildr f.e. so that it wont clutter the user-directory.
> >
> > what do you thing about this?
> >
> > kind regards,
> > peter
>
Yes, a few people have noticed this. Looks like it's coming from Rake. I'll look into it. alex On Sun, Nov 22, 2009 at 3:23 PM, Megan Woods <megan_woods@toll.com.au>wrote: > Hi all, > > Is it possible to stop Java::Commands:Java from producing so much output.? > > I have been digging through the buildr source code and can confirm that the > following are: > > Buildr.application.options.trace is nil > :verbose is false > > which I have confirmed by putting puts statements in the appropriate places > within \lib\buildr\java\commands.rb > > Buildr version is: > > buildr-1.3.5-x86-mswin32 > > Cheers Megan > > > >