message.
We want to put everything into one jar file which we'll publish via Maven. So
we include our command line tools, and replace the un-proguarded jar with the
proguarded one during the packaging step.
I may look into not renaming the Getdown code so that apps (like Bang) that
link against some of it, can use this jar file. Or I'll just figure out
specifically what apps are likely to link against and not rename just that.
It's probably not a huge size increase either way.
hair-pulling and ball-ache. We now have Maven call out to an Ivy-based Ant task
to do the Proguard build (with Ivy maintaining a parallel copy of the
dependencies, unfortunately). It's a twisty maze of passages, but it gets the
Proguard build done during the right Maven phase so that all of its magical
building, version number changing, SVN commits, etc. can happen as usual during
the publishing process.
to build and publish Getdown. Everything builds with Maven, but getting
Proguard to work inside Maven is an exercise in gouge-my-eyes-out-now, so I'll
be doing the Proguard bits in a separate Ant script which will use Ivy to
obtain dependencies sanely. This too is rife with PITA, but less so than doing
everything in Maven. Ivy bits don't yet work.