qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: Qpid Java Build Instructions - Trunk (M2+)
Date Mon, 04 Dec 2006 21:48:40 GMT

On Dec 4, 2006, at 10:47 AM, Gordon Sim wrote:

> Steve Vinoski wrote:
>> On Dec 4, 2006, at 9:14 AM, Daniel Kulp wrote:
>>> On Monday 04 December 2006 03:59, Gordon Sim wrote:
>>>> Steve Vinoski wrote:
>>>>> Hi Gordon, I guess the issue here is that qpid-run is specifically
>>>>> intended to work within the layout of the installed package  
>>>>> environment.
>>>>> We could
>>>>> 1. Write a new script to be used within your svn working copy,  
>>>>> perhaps
>>>>> boiling the common parts of it and the qpid-run script into a  
>>>>> separate
>>>>> file that each of them source so as to prevent scripting  
>>>>> duplication.
>>>>> 2. Augment qpid-run so that it can also run within the svn  
>>>>> working copy.
>>>> My thought was that if there was an easy way to do it we could  
>>>> have a
>>>> task (or maven equivalent) that setup the installed package  
>>>> layout. We
>>>> used to have this with the ant build.
>>>> The benefit is that it easily allows the same scripts and config  
>>>> files
>>>> to be used in development that will be used for an installed  
>>>> release.
>>>> That in turn makes it more likely that those artifacts are kept in
>>>> working order and have any wrinkles ironed out quickly.
>>> In the assembly (like bin.xml), you should just be able to change
>>> the "formats" section to read something like:
>>>   <formats>
>>>     <format>tar.gz</format>
>>>     <format>zip</format>
>>>     <format>dir</format>
>>>   </formats>
>>> I've never tried it though.   I'm not sure how well that works  
>>> (or what then
>>> happens at install/deploy time for the dir).
>> Thanks Dan. Looks like there's a bug in assembly 2.1 that keeps  
>> this from working [1]. It appears fixed with assembly 2.2- 
>> SNAPSHOT, but using that version causes warnings elsewhere, which  
>> I think I can fix. The result does produce a working copy under  
>> distribution/target/qpid-1.0-incubating-M2-SNAPSHOT-java-bin.dir/ 
>> qpid-1.0-incubating-M2-SNAPSHOT, and if you set QPID_HOME to that  
>> and add $QPID_HOME/bin to your PATH, then qpid-server works fine.
>> Gordon, Robert, everyone: shall we go with this approach then?
> It's better than nothing certainly!
> If the path wasn't so awkward and if you could create that layout  
> from the base java directory (rather than from the distribution  
> directory) it would be ideal. How easy is it to work around these  
> sorts of things in maven?

OK, you can now build a directory version of the java-bin assembly,  
and specify the output directory as well. Let's say you have  
QPID_HOME set to /tmp/qpid/qpid-1.0-incubating-M2-SNAPSHOT . If you  
want to do a quick rebuild and redeploy into QPID_HOME, you can do this:

mvn -Pfastinstall
cd distribution
mvn -Dqpid.targetDir=$QPID_HOME/.. assembly:directory

(Note, these are UNIX command lines. For Windows, change to a  
backslash in the last line.)

The first line is executed at the top level to do a Java build, as  
normal. The "-Pfastinstall" tells it to skip tests, basically, by  
invoking the fastinstall profile. You then change to the distribution  
directory, and tell it you want the assemblies to go to $QPID_HOME/..  
so that the actual new directory contents you're looking for will go  
under $QPID_HOME. You will also get the usual tar and zip files under  
$QPID_HOME/.. as well, but you'll just be ignoring those anyway.

This way, you can set QPID_HOME and PATH once, and overwrite their  
contents as you make changes and rebuild.


View raw message