Older 3.x versions of Blacklight may have put a solrmarc.jar inside your 
app's ./config/SolrMarc.  That may not be caught by your slug ignore.

This was an error, it was never meant to do that. If you have one in a 
BL 3.x you should be safe to remove it.

Other than that, I'm curious what's making a BL app so large!

Incidentally, you don't need a ./jetty in your local app _at all_, 
unless you actually want to keep a jetty Solr there. BL will optionally 
install one there, but it's not required.

(Does slug size include your gem dependencies? I am not familiar with 
heroku. Cause the BL gem itself _does_ also include a SolrMarc.jar, if 
that's a problem, we'd have to refactor things on the BL side to make it 
an optional dependency instead of baked into BL).

On 3/29/2012 12:37 PM, Chris Fitzpatrick wrote:
> Hey Sean,
>
> Jah, I did that...my .slugignore is:
> tmp/*
> log/*
> coverage/*
> spec/*
> koha/*
> jetty/*
>
> That dropped it down to 30 from ~50mb, so that's good .
> (koha has some scripts wrote to pull from our ILS).
>
> I think the slug size is a really minor issue. Heroku says under 25mb
> is good, but over 50mb is not so good.  Not "Good",  but not "Chaotic
> Evil" . "Neutral Good".
>
>
>
> On Thu, Mar 29, 2012 at 6:26 PM, Sean Hannan<[log in to unmask]>  wrote:
>> If you already have everything indexed in Solr elsewhere, a way to cut down
>> the BL slug size is to remove/ignore the SolrMarc.jar. It's pretty sizable.
>>
>> -Sean
>>
>>
>> On 3/29/12 12:16 PM, "Chris Fitzpatrick"<[log in to unmask]>  wrote:
>>
>>> Hi,
>>>
>>> I've deployed Blacklight on both Heroku and Elastic BeanStalk.
>>>
>>> Heroku is still a much better choice. The only issue I had was I
>>> needed to make sure the sass-rails gem in installed in the :production
>>> gem group and not just development.
>>>
>>>   I still have an issue of getting heroku to compile all my
>>> sass/coffeescript/etc assets on update, but it actually doesn't seem
>>> to make much of an impact on performance. The minor issue is that it
>>> would be nice to figure out a way to slim down BL's slug size. The
>>> lowest I've been able to get it is about 30mb and Heroku recommends
>>> having it be below 25mb.
>>>
>>> I have not used Heroku's solr service (I still use EC2 for my solr
>>> deployments).
>>> EngineYard would also be another option.
>>>
>>> There is also an AMI for DSpace, so deploying that to EC2 should be
>>> pretty easy....
>>>
>>> b,chris.
>>>
>>>
>>>
>>> On Thu, Mar 29, 2012 at 3:55 PM, Rosalyn Metz<[log in to unmask]>  wrote:
>>>> Erik,
>>>>
>>>> I haven't tried it (recently) on PaaS providers, but I have on IaaS.  The
>>>> AMIs I've created in association with start up scripts (if you're
>>>> interested in seeing those let me know, I'd have to look for them somewhere
>>>> or other) mean that the application automagically starts up on its own, all
>>>> you need to do is go to the URL.  I've used this as a back up method in the
>>>> past and I think would be a great way for people to be able to play with
>>>> the different apps before committing.
>>>>
>>>> To this end, I created an AMI for Blacklight a while back:
>>>> http://www.rosalynmetz.com/ami-3c10f255/  I guarantee you it is grossly out
>>>> of date.  I also have instructions on creating an EBS backed AMI:
>>>> http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which
>>>> is the method I used for creating the Blacklight AMI. These instructions
>>>> are also fairly old, but I still get comments on my blog now and then that
>>>> the method works.
>>>>
>>>> I also played around with it on Heroku, but that was so long ago I don't
>>>> think any of the things I learned still apply (this was when Heroku was
>>>> fairly new to the scene).  Hope some of this helps.
>>>>
>>>> Rosalyn
>>>>
>>>>
>>>>
>>>> On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hooland<[log in to unmask]>wrote:
>>>>
>>>>> Dear Erik,
>>>>>
>>>>> Bram Wiercx and myself have given a talk on how to put together a package
>>>>> to install CollectiveAccess on Red Hat's OpenShift:
>>>>> http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacce
>>>>> s-as-a-service-solution
>>>>> .
>>>>>
>>>>> My students are currently happily playing around with CollectiveAccess,
>>>>> which they have installed on OpenShift. My teaching assistant Max De Wilde
>>>>> has developed clear guidelines on how to run the installation procedure:
>>>>> http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf.
>>>>>
>>>>> It would be wonderful to aggregate these kind of installation procedure's
>>>>> for other types of LIS applications...
>>>>>
>>>>> Kind regards and looking forward to your book!
>>>>>
>>>>> Seth van Hooland
>>>>> Président du Master en Sciences et Technologies de l'Information et de la
>>>>> Communication (MaSTIC)
>>>>> Université Libre de Bruxelles
>>>>> Av. F.D. Roosevelt, 50 CP 123  | 1050 Bruxelles
>>>>> http://homepages.ulb.ac.be/~svhoolan/
>>>>> http://twitter.com/#!/sethvanhooland
>>>>> http://mastic.ulb.ac.be
>>>>> 0032 2 650 4765
>>>>> Office: DC11.113
>>>>>
>>>>> Le 29 mars 2012 à 14:10, Erik Mitchell a écrit :
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have been toying with the process of implementing common LIS
>>>>>> applications (e.g. Vufind, Dspace, Blacklight. .  .) on PaaS providers
>>>>>> like Heroku and Amazon Elastic Beanstalk.  I have just tried out of
>>>>>> the box distributions so far and have not made much progress but was
>>>>>> wondering if someone else had tried this or had ideas about what
>>>>>> issues I might run into.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>> Erik Mitchell
>>>>>> Assistant Professor
>>>>>> College of Information Studies
>>>>>> University of Maryland, College Park
>>>>>> http://ischool.umd.edu