I don't have a preference over which method gets implemented, but I found the ability to remove code that my application does not actually depend on using autojar nice. Autojar dropped the size of my jar file from 2 meg in Maven to 300k using buildr. As for Spring, it seems that it wouldn't be too hard to implement something to the effect of concat(['META-INF/spring.handlers']) on top of the packaging system.
Brandon -----Original Message----- From: Michael Guymon [mailto:[email protected]] Sent: Thursday, September 29, 2011 9:31 AM To: [email protected] Subject: 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 > >
