qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Qpid Java Build Instructions - Trunk (M2+)
Date Tue, 05 Dec 2006 08:13:31 GMT
Steve Vinoski wrote:
> 
> 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.

Excellent! Thanks, Steve!

Mime
View raw message