Re: Buildr OSX Yosemite (10.10.3)
I stumbled upon this the other day. The installers for Mac (from Oracle) have JNI disabled. I don't have a link handy (on mobile), but tweaking the permission to include JNI fixes the popup. On Jun 14, 2015 11:15 AM, Alex Boisvert alex.boisv...@gmail.com wrote: Since upgrading to OSX Yosemite (10.10.3), whenever I run buildr I get a popup that says: To open This Java application you need to install the legacy Java SE 6 runtime. [More info...] [Ok] My environment remains the same (AFAIK) and I have JAVA_HOME set to: $ echo $JAVA_HOME /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/ Any ideas?
Re: Experiences with transitive dependencies in buildr
So there seems to be agreement on a initial solution. Should this be
tracked in Jira?
I plan on helping out, but work is eating all my spare time right now.
On top of that, I have a queue of patches I need to send out, so I will
not be able to produce anything in the near future.
--M
On 11/04/2011 06:13 AM, Peter Tillotson wrote:
This sounds pretty good - some thoughts inline below
Dependency Resolution
* Dependency resolution is optional
* Resolve Transitive Dependencies for an artifact(s)
* Create/Rebuild a dependency file
* Lock dependencies based on the dependency file
Transitive resolution should be capable of producing the same dependencies as
maven ( possibly via an interface compatible plugin ) and support the full
maven spec.
I'd add filtering and blacklist has been useful as well. I always have to package(:war).libs.reject! { |lib| lib.group == 'servlet-api' } this is a reasonable compile dependency that shouldn't get into runtime.
If the dependencies file something like the following
runtime:
- org.apache.cassandra:cassalndra-all:1.0.1
exclude:
- *:servlet-api:*
- *:junit:*
That would be pretty handy - I really like the idea of the dependency report
effectively acting as the whitelist / blacklist so when the universe changes my
build file doesn't necessarily have to :-)
Maven interop
* Generate a maven POM based on a Buildr project
* Create deploy maven friendly artifacts based on a Buildr project
Would there be any benefit for having Ivy interoperability as well?
p
From: Michael Guymonmichael.guy...@gmail.com
To: dev@buildr.apache.org
Sent: Thursday, 3 November 2011, 23:16
Subject: Re: Experiences with transitive dependencies in buildr
So based on the discussion, it sounds like the following solutions would work
well:
Dependency Resolution
* Dependency resolution is optional
* Resolve Transitive Dependencies for an artifact(s)
* Create/Rebuild a dependency file
* Lock dependencies based on the dependency file
Maven interop
* Generate a maven POM based on a Buildr project
* Create deploy maven friendly artifacts based on a Buildr project
Would there be any benefit for having Ivy interoperability as well?
On 11/02/2011 09:59 PM, Peter Donald wrote:
Hi,
On Thu, Nov 3, 2011 at 12:26 AM, Chiaming Hsucamy...@yahoo.com wrote:
If this becomes part of the core of buildr as Peter suggested, would there be
performance impact when not using transitive dependencies?
I would hope not.
I am not a huge fan of transitive closure across the builds when you
can't lock it down to a specific set (like Gemfile.lock or what Ivy4r
supports it seems). I don't object so much to the network chattiness
but due to the un-reproducible of builds.
Aether would mainly used as the API for interacting with Maven repos
and for implementing transitive dependencies of maven artifacts.
Re: Experiences with transitive dependencies in buildr
So based on the discussion, it sounds like the following solutions would work well: Dependency Resolution * Dependency resolution is optional * Resolve Transitive Dependencies for an artifact(s) * Create/Rebuild a dependency file * Lock dependencies based on the dependency file Maven interop * Generate a maven POM based on a Buildr project * Create deploy maven friendly artifacts based on a Buildr project Would there be any benefit for having Ivy interoperability as well? On 11/02/2011 09:59 PM, Peter Donald wrote: Hi, On Thu, Nov 3, 2011 at 12:26 AM, Chiaming Hsucamy...@yahoo.com wrote: If this becomes part of the core of buildr as Peter suggested, would there be performance impact when not using transitive dependencies? I would hope not. I am not a huge fan of transitive closure across the builds when you can't lock it down to a specific set (like Gemfile.lock or what Ivy4r supports it seems). I don't object so much to the network chattiness but due to the un-reproducible of builds. Aether would mainly used as the API for interacting with Maven repos and for implementing transitive dependencies of maven artifacts.
Re: Experiences with transitive dependencies in buildr
I could not agree more, Buildr should stay lean and mean. Enabling a big dependency resolution framework should be optional. Right now Aether suffers from the same needy networking that Maven has. It wants to check artifacts frequently for changes. While this can be a good thing, it is not always an operation a project should have to do. --M On 11/02/2011 09:26 AM, Chiaming Hsu wrote: If this becomes part of the core of buildr as Peter suggested, would there be performance impact when not using transitive dependencies? I have large projects using buildr (migrated from Maven), and I did strictly white listing without any use of transitive dependencies. Buildr runs at least twice faster then Maven to build the same large project after migration and generates WAR artifacts about half of the size of Maven. I believe using white listing of dependencies without transitive plays a key role in the performance / compactness I saw. I don't want to lose this key benefit of using buildr. In a sense, I would like to see transitive dependencies being optional (as it is in buildr now) and avoid any performance impact for projects not using transitive dependencies, if we brought in more Maven stuff into core buildr library. Cheers, Chiaming Hsu From: Peter Donaldpe...@realityforge.org To: dev@buildr.apache.org Sent: Tuesday, November 1, 2011 8:40 PM Subject: Re: Experiences with transitive dependencies in buildr Hi, On Sat, Oct 29, 2011 at 5:43 AM, Michael Guymon michael.guy...@gmail.com wrote: The integration with buildr is crude and for some reason the rdoc is no longer formated correct. I will update it to make it legible again. https://github.com/mguymon/buildr-resolver nice. This is the ruby wrapper for the Aether java libs, which buildr-resolver depends on https://github.com/mguymon/naether That is quite neat. I wonder if the core of buildr could move across to using (n)Aether and if there is much benefit from that? Last time I looked the project was still relatively volatile. What did you think of working with the library? The one advantage I see is that it would be using the same core as maven and thus guaranteed to be compatible (where as now we know there is scenarios where we are not quite right).
Re: 'add dependencies to jar' feature
Hi Brandon,
I am going to toss my 2 cents in here because I have been working on
ubers with maven and buildr for a little while now.
Using one-jar is the simplest solution and cleanest, since one-jar
implements its own classloader to handle loading of jars. You do not
have to worry about overlap of exploding jars over each other. The
downside is you have to play ball with the one-jar setup and the startup
is a bit slower than manually making an uberjar. I have projects using
this setup running happily for months now.
Whoops about the deps ref in the one-jar example, I updated the gist -
https://gist.github.com/981589.
Maven's shade is akin to the manual uberjarring in Buildr. The one nice
thing it provides though is the helpers for layering in files from
exploded jar. What originally drove me to one jar from manually
creating an uberjar was the META-INF/spring.schemas (and friends) were
being overwritten by each individual Spring jar, when they needed to be
concatenated together. Having this feature wrapped up into a task would
be great.
The one downside with package(:jar) is rubyzip is such a CPU whore. Some
of my Uberjars are beasts, weighing in at ~50 megs, so Rubyzip dogs
wrapping them up. I ended up manually exploding everything to a dir and
calling the jar command from Buildr directly. Here is an example of what
I am using now
https://gist.github.com/1250815
So the short of it is I guess uberjarring has a lot of edge cases, but
making a clever Buildr task for them would be awesome!
--Michael
On 09/29/2011 09:58 AM, Coleman, Brandon wrote:
Hello,
Long time Ruby user, first time 'Buildr' ;)
I am converting a Maven application so that it uses Buildr and have
found 2 different ways to compile all dependencies into a jar, but each
has their issues:
https://gist.github.com/981589
'Only one project name at a time' error when using 'project.name'
variable
https://gist.github.com/981589/62d9beb2aa98c71b1a93fc1f93d9f895cef0e239
deps variable is not set
have to hard code project name into uberjar task
http://stackoverflow.com/questions/1279419/buildr-package-dependencies-i
nto-a-single-jar
does not handle paths with spaces
deletes manifest file
I personally like how dependencies are handled with the stack overflow
solution, but instead of fixing their solution for my needs it just
seems like my time would be better spent modifying buildr to handle this
situation automatically.
So before I get started working on this:
1. Is this something that the Buildr community would be interested
in, if I were to provide the code?
2. I was thinking of implementing something on top of the package
method like package(:jar).with :manifest={},:singleJar, but there is
probably a better way (open to suggestions)
3. Is there an example, or a starting point on how I should
implement this?
Brandon
Re: Auth for Buildr repositories.remote
I created a patch so that
repositories.remote { :url = 'https://a.secure.repo/maven2',
:username = 'blah', :password = 'blah' }
will work for http basic auth. When an artifact is downloaded, the auth
information is passed to the HTTP transport.
https://issues.apache.org/jira/browse/BUILDR-577
There might be an issue with the patch, since it changes the format of
repositories.remote. Instead of just being a String, it is stored as a
hash {:url = URI} or with optional auth {:url = URI, :username =
String, :password = String}. How horrible is this for backwards
compatibility?
thanks,
Michael
On 03/10/2011 12:43 PM, Alex Boisvert wrote:
Hi Michael,
I think it's a good idea and I don't think it would be that much work.
Use of repositories.remote for actual downloading seems to be fairly
localized in buildr/packaging/artifact.rb.
alex
On Thu, Mar 10, 2011 at 8:56 AM, Michael Guymon
michael.guy...@gmail.com mailto:michael.guy...@gmail.com wrote:
So I am interested in getting repositories.remote to support auth.
The goal is to have buildr deploy to private maven repo's I have a
work. What I would like to do is have the following be valid:
repositories.remote 'https://a.secure.repo/maven2'
repositories.remote { :url = 'https://a.secure.repo/maven2' }
repositories.remote { :url =
'https://a.secure.repo/maven2', :username = 'blah', :password =
'blah' }
and possibly
repositories.remote { :url =
'https://a.secure.repo/maven2', :priv_key = 'file' }
I have sourced dived a little to see how repositories.remote is
used, but I am not sure if this change would be a colossal PITA.
If someone has a better/easier solution I would love to hear it.
thanks,
Michael
Auth for Buildr repositories.remote
So I am interested in getting repositories.remote to support auth. The
goal is to have buildr deploy to private maven repo's I have a work.
What I would like to do is have the following be valid:
repositories.remote 'https://a.secure.repo/maven2'
repositories.remote { :url = 'https://a.secure.repo/maven2' }
repositories.remote { :url = 'https://a.secure.repo/maven2',
:username = 'blah', :password = 'blah' }
and possibly
repositories.remote { :url = 'https://a.secure.repo/maven2',
:priv_key = 'file' }
I have sourced dived a little to see how repositories.remote is used,
but I am not sure if this change would be a colossal PITA. If someone
has a better/easier solution I would love to hear it.
thanks,
Michael
Fwd: Dependency resolution with Maven's Aether
So I jumped straight into the fire and have created a basic dependency resolver using Aether for Buildr. https://github.com/mguymon/buildr-resolver It will take an array of dependencies and find their dependencies, returning the total of all dependencies. For example, if you pass it [org.apache.activemq:activemq-spring:jar:5.4.2] it returns an array of org.apache.activemq:activemq-spring:jar:5.4.2 and its 32 dependencies. Not surprising, it still needs work. It requires JRuby but I should be able to get it to work with RJB for vanilla Ruby support. Aether is downloading dependencies on its own, which needs to be disabled, so buildr can handle that part. buildr-resolver may cause conflicts due to the jars required to bootstrap Aether. Needs a way to load Aether without polluting the project runtime. Bootstrap deps - https://github.com/mguymon/naether/blob/master/src/main/java/com/slackworks/Bootstrap.java I made a simple wrapper for Aether that buildr-resolver uses. It does some juggling to make Maven and Gem play nice - https://github.com/mguymon/naether Original Message Subject:Dependency resolution with Maven's Aether Date: Thu, 24 Feb 2011 15:04:02 -0500 From: Michael Guymon michael.guy...@gmail.com To: dev@buildr.apache.org Has anyone looked into using Maven 3's new Aether framework for handling dependency resolution in Buildr? Then lazy developers like me could only have to define a few jar dependencies and Buildr would be able to figure out the rest. I have only done a little bit of reading on the subject and am curious if anyone has any insight if it is plausible and 'a good idea'. thanks, Michael
Re: warbler 1.2 and buildr .1.4.3
I submitted a patch at https://issues.apache.org/jira/browse/BUILDR-546 that will allow using rubyzip 0.9.4 with buildr On 11/12/2010 05:19 PM, Alex Boisvert wrote: It probably goes without saying but ... you may want to comment out our Zip patches to see if the specs pass.It's entirely possible that our patches are no longer correct on rubyzip 0.9.4. We can rework the sorting optimization as a second step (and if still relevant). On Fri, Nov 12, 2010 at 2:16 PM, Alex Boisvertalex.boisv...@gmail.comwrote: We use autoload for all largish gem dependencies so they are loaded lazily and don't affect startup time too much, especially when they are not used in a given buildr execution. We load 'buildr/packaging/zip' because we need to monkeypatch the File class for Ruby 1.9 (see the top of lib/buildr/packaging/zip.rb) and monkeypatch Zip itself to support efficient sorting of entries. alex On Fri, Nov 12, 2010 at 2:02 PM, Michael Guymonmichael.guy...@gmail.comwrote: Hey Alex, When I changed from autoload to require, it broke 239 specs. I was hoping someone could tell me why the autoload :Zip, 'buildr/packaging/zip' is used. Otherwise I need to dig around the specs I broke. Once I get the tests working, I will create a new issue with a patch. --M On 11/12/2010 04:51 PM, Alex Boisvert wrote: Hi Michael, Thanks for your sleuthing! Can you open an issue on https://issues.apache.org/jira/browse/BUILDRand attach a patch/diff of your work? (and check the license attachment to ASF checkbox). This is necesary for us to include your work in buildr. When that's done I'll include the code and upgrade to rubyzip 0.9.4. alex On Fri, Nov 12, 2010 at 1:25 PM, Michael Guymonmichael.guy...@gmail.com wrote: Hello, The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If buildr gemspec is updated to=, a type error pops up due to autoload :Zip, 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the autoload providing? Changing it to a require makes the specs angry, so there is some magic going into the sauce. The yarn: So I kicked maven to the curb for buildr on a spring web + jruby rails project. Oh man, a breath of fresh air. When trying to use the latest warbler to package the project, I got the following: RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError) buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest. Ok, that is simple enough. I cloned buildr at github and updated the gemspec to allow rubyzip= 0.9.1. Unfortunately, that turned up: TypeError : superclass mismatch for class ZipFile Hrm, odd. I started poking around buildr a little and figured out the lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip' which is causing problems when warbler is requiring rubyzip. So I blindly changed the autoload to require 'buildr/packaging/zip' and that fixed that issue, but another error sprung up directly from rubyzip: NoMethodError : undefined method `length' for -1:Fixnum /home/zinger/.rvm/gems/jruby-1@rails3 /gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in `write_c_dir_entry' Curses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1 when it expects a string, the angry line of code: 732: @comment ? comment.length : 0, Somehow, the entry's comment being produced from buildr returns a -1. Yet again, swinging in the dark, I override the write_c_dir_entry method in buildr and simply add a to_s method call to comment: @comment ? comment.to_s.length : 0, Horray, the project builds! I thought about directly patching rubyzip, but it is crammed in cvs under sourceforge and I have had enough abuse for the time being. I added the override to lb/buildr/packaging/zip.rb My fork of buildr on github - https://github.com/mguymon/buildr versions zin...@imperator:~/devel/src/ruby/mguymon-buildr$ java -version java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) zin...@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586) [amd64-java] zin...@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version Buildr 1.4.3 thanks, Michael
Re: warbler 1.2 and buildr .1.4.3
Hey Alex, When I changed from autoload to require, it broke 239 specs. I was hoping someone could tell me why the autoload :Zip, 'buildr/packaging/zip' is used. Otherwise I need to dig around the specs I broke. Once I get the tests working, I will create a new issue with a patch. --M On 11/12/2010 04:51 PM, Alex Boisvert wrote: Hi Michael, Thanks for your sleuthing! Can you open an issue on https://issues.apache.org/jira/browse/BUILDR and attach a patch/diff of your work? (and check the license attachment to ASF checkbox). This is necesary for us to include your work in buildr. When that's done I'll include the code and upgrade to rubyzip 0.9.4. alex On Fri, Nov 12, 2010 at 1:25 PM, Michael Guymonmichael.guy...@gmail.comwrote: Hello, The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If buildr gemspec is updated to=, a type error pops up due to autoload :Zip, 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the autoload providing? Changing it to a require makes the specs angry, so there is some magic going into the sauce. The yarn: So I kicked maven to the curb for buildr on a spring web + jruby rails project. Oh man, a breath of fresh air. When trying to use the latest warbler to package the project, I got the following: RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError) buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest. Ok, that is simple enough. I cloned buildr at github and updated the gemspec to allow rubyzip= 0.9.1. Unfortunately, that turned up: TypeError : superclass mismatch for class ZipFile Hrm, odd. I started poking around buildr a little and figured out the lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip' which is causing problems when warbler is requiring rubyzip. So I blindly changed the autoload to require 'buildr/packaging/zip' and that fixed that issue, but another error sprung up directly from rubyzip: NoMethodError : undefined method `length' for -1:Fixnum /home/zinger/.rvm/gems/jruby-1@rails3/gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in `write_c_dir_entry' Curses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1 when it expects a string, the angry line of code: 732: @comment ? comment.length : 0, Somehow, the entry's comment being produced from buildr returns a -1. Yet again, swinging in the dark, I override the write_c_dir_entry method in buildr and simply add a to_s method call to comment: @comment ? comment.to_s.length : 0, Horray, the project builds! I thought about directly patching rubyzip, but it is crammed in cvs under sourceforge and I have had enough abuse for the time being. I added the override to lb/buildr/packaging/zip.rb My fork of buildr on github - https://github.com/mguymon/buildr versions zin...@imperator:~/devel/src/ruby/mguymon-buildr$ java -version java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) zin...@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586) [amd64-java] zin...@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version Buildr 1.4.3 thanks, Michael
