Re: Bundling ActiveMQ version 5.x in RPM

On Mon, May 16, 2011 at 6:51 PM, Fernando Nasser <[email protected]> wrote:
> On 11-02-21 2:19 PM, Nico Kadel-Garcia wrote:

>> Unfortunately, I see that the current ActiveMQ release build with
>> Maven, and the Apache published .pod for it has a maven 2.0.9
>> dependency built right into it,
>
> Just patch it to 2.0.8 -- we built lots of things that siad 2.0.9 with 2.0.8
> (well, sometimes
> we had to make small adjustments).

I've given up on RHEL 5.x entirely. Don't need it in my new role, and
the OpenJDK with RHEL 6.x based distributions is much cleaner.

That said, Fedora 14 has Maven 2.2.x in it, so I'm taking a glance
there at build environments. It's not high on my priority list,
though.

>>  and goes out to the Internet at large
>> to grab losts of different components when running "mvn install" on
>
> Use mvn-jpp  Look at some other package that build with maven (some simple
> one) and
> just adapt what is done there.

Tried that over the weekend, when I dumped my last RHEL 5.x
environment. I'm using Scientific Linux 6.0 for testing: CentOS seems
to have lost its way and has been unable to complete a 6.x release,
but with Scientific Linux 6.x out, I've got a good working environment
for cheap beggers.

I even just took a shot at ActiveMQ 5.5.0, the latest release.
Unfortunately, that's got a dependency on "jacrypt", which I don't
have bundled up.

>> it. The result is is, to my mind fragile because it's grabbing
>> components from offsite and of unknown provenance, just as Perl's CPAN
>> utilities tend to grab components which may not be compatible with the
>> existing environment.
>
> Well, the Maven we have will ignore version differences.  If the coordinate
> is a bit difference
> (different groupId) you can add a depmap to the build.
>
> For the things we don't have you will get missing artifact errors.
>  Initially you can just add those as
> binary files, just drop them into your local maven repo before mvn-jpp is
> called.  You can grab them
> from whatever repo they live in.  Then go replacing these with real builds
> that provide them.

I'm looking for jacrypt now.