You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Marnie McCormack <ma...@googlemail.com> on 2006/12/01 12:07:29 UTC
Qpid Java Build Instructions - Trunk (M2+)
All,
I've made a brief initial contribution to the Build instructions for the
java trunk here:
http://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Build+How+To
Please do contribute to/edit these instructions, especially if you have some
maven tips to share which could be quickly added.
Thanks & Regards,
Marnie
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Steve Vinoski <vi...@iona.com>.
On Dec 2, 2006, at 6:09 PM, Robert Greig wrote:
> On 02/12/06, Steve Vinoski <vi...@iona.com> wrote:
>
>> I don't think there's any need to generate such a script -- maybe we
>> should just create a bin directory at the java top level and add a
>> script there like the one you're describing?
>
> But would that not mean you had to edit the script every time you
> edited the dependencies in the POMs? I was thinking that the automatic
> generation of such a script would avoid having to manage the
> dependencies in two places.
Yes, that's a very good point. But rather than generating a script,
it looks like both Mule and ActiveMQ have simple maven plugins to run
their brokers, so I think it'll be worthwhile for me to look into
borrowing from those.
--steve
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Robert Greig <ro...@gmail.com>.
On 02/12/06, Steve Vinoski <vi...@iona.com> wrote:
> I don't think there's any need to generate such a script -- maybe we
> should just create a bin directory at the java top level and add a
> script there like the one you're describing?
But would that not mean you had to edit the script every time you
edited the dependencies in the POMs? I was thinking that the automatic
generation of such a script would avoid having to manage the
dependencies in two places.
RG
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Steve Vinoski <vi...@iona.com>.
On Dec 1, 2006, at 5:30 PM, Robert Greig wrote:
> On 01/12/06, Steve Vinoski <vi...@iona.com> 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.
>>
>> For users, IMO the first approach would be cleaner. Any other
>> opinions or ideas? I've filed QPID-150 for this, so either post your
>> opinions here or attach them to that issue (or both).
>
> I wondered if there was a maven artifact that could generate a script
> that just set up the classpath? i.e it would set up an environment
> variable that referenced the relevant jars in your maven repository,
> that you could then source in the qpid-run script.
I don't think there's any need to generate such a script -- maybe we
should just create a bin directory at the java top level and add a
script there like the one you're describing?
--steve
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Robert Greig <ro...@gmail.com>.
On 01/12/06, Steve Vinoski <vi...@iona.com> 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.
>
> For users, IMO the first approach would be cleaner. Any other
> opinions or ideas? I've filed QPID-150 for this, so either post your
> opinions here or attach them to that issue (or both).
I wondered if there was a maven artifact that could generate a script
that just set up the classpath? i.e it would set up an environment
variable that referenced the relevant jars in your maven repository,
that you could then source in the qpid-run script.
RG
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Steve Vinoski <vi...@iona.com>.
Yep, it was on my list to do -- done.
On Dec 5, 2006, at 11:56 AM, Marnie McCormack wrote:
> Be great if people could take a moment to copy any useful info from
> this
> thread into the wiki page (see first email in thread) please ?
>
> Thanks vm,
> Marnie
>
>
> On 12/5/06, Steve Vinoski <vi...@iona.com> wrote:
>>
>> [Trimming the email thread down for readability]
>>
>> On Dec 5, 2006, at 7:46 AM, Martin Ritchie wrote:
>>
>> > On 04/12/06, Steve Vinoski <vi...@iona.com> wrote:
>> >> 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.
>> >>
>> >> --steve
>> >
>> > This doesn't seem to work quite right for me. All the zip/tgz still
>> > get built.
>> > I did:
>> > mvn -Pfastinstall
>> > (Wish we could avoid this step and get the dist pom to reference
>> the
>> > local checkout.. and re-compile only if required)
>>
>> You don't have to run this step if you've already built. Just cd to
>> the distribution directory and start from there.
>>
>> Note also that the framing code generation is the biggest culprit in
>> terms of the lack of build avoidance. Maven didn't change this -- the
>> same problem existed with ant. Every time you build, the framing code
>> gets regenerated, and about 100 Java files get recompiled as a
>> result. There are also 2 JMS CTS Java files under the client that get
>> recompiled every time through, not sure why. These two problems add
>> unnecessary time to the build, and again, they existed with ant and
>> are not a maven issue. I filed a jira for the JMS CTS problem, but
>> didn't for the code gen problem because I figured the new code gen
>> stuff would be showing up soon (and hopefully it won't have this
>> problem).
>>
>> > cd distribution
>> > mvn -Dqpid.targetDir=c:/tmp/qpid/ assembly:directory
>> >
>> > Am I doing something wrong that is casuing the zips and tars to be
>> > created each time?
>>
>> No, see my message above, where it says "You will also get the usual
>> tar and zip files under $QPID_HOME/.. as well, but you'll just be
>> ignoring those anyway." The job of this phase is to produce
>> assemblies, so that's what happens. The assembly:directory part
>> simply adds the directory as part of what gets produced.
>>
>> Next to the tars and zips, you should see a directory named qpid-1.0-
>> incubating-M2-SNAPSHOT-java-bin.
>>
>> > Is it possible to stop all the warning messges related to long
>> > paths in the zip?
>>
>> Such warnings are the default, but there's a configuration setting
>> for the assembly plugin called tarLongFileMode that can be set to
>> "gnu" to make the warnings go away. I'll commit that change shortly,
>> unless someone knows of a reason to avoid that setting.
>>
>> --steve
>>
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Marnie McCormack <ma...@googlemail.com>.
Be great if people could take a moment to copy any useful info from this
thread into the wiki page (see first email in thread) please ?
Thanks vm,
Marnie
On 12/5/06, Steve Vinoski <vi...@iona.com> wrote:
>
> [Trimming the email thread down for readability]
>
> On Dec 5, 2006, at 7:46 AM, Martin Ritchie wrote:
>
> > On 04/12/06, Steve Vinoski <vi...@iona.com> wrote:
> >> 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.
> >>
> >> --steve
> >
> > This doesn't seem to work quite right for me. All the zip/tgz still
> > get built.
> > I did:
> > mvn -Pfastinstall
> > (Wish we could avoid this step and get the dist pom to reference the
> > local checkout.. and re-compile only if required)
>
> You don't have to run this step if you've already built. Just cd to
> the distribution directory and start from there.
>
> Note also that the framing code generation is the biggest culprit in
> terms of the lack of build avoidance. Maven didn't change this -- the
> same problem existed with ant. Every time you build, the framing code
> gets regenerated, and about 100 Java files get recompiled as a
> result. There are also 2 JMS CTS Java files under the client that get
> recompiled every time through, not sure why. These two problems add
> unnecessary time to the build, and again, they existed with ant and
> are not a maven issue. I filed a jira for the JMS CTS problem, but
> didn't for the code gen problem because I figured the new code gen
> stuff would be showing up soon (and hopefully it won't have this
> problem).
>
> > cd distribution
> > mvn -Dqpid.targetDir=c:/tmp/qpid/ assembly:directory
> >
> > Am I doing something wrong that is casuing the zips and tars to be
> > created each time?
>
> No, see my message above, where it says "You will also get the usual
> tar and zip files under $QPID_HOME/.. as well, but you'll just be
> ignoring those anyway." The job of this phase is to produce
> assemblies, so that's what happens. The assembly:directory part
> simply adds the directory as part of what gets produced.
>
> Next to the tars and zips, you should see a directory named qpid-1.0-
> incubating-M2-SNAPSHOT-java-bin.
>
> > Is it possible to stop all the warning messges related to long
> > paths in the zip?
>
> Such warnings are the default, but there's a configuration setting
> for the assembly plugin called tarLongFileMode that can be set to
> "gnu" to make the warnings go away. I'll commit that change shortly,
> unless someone knows of a reason to avoid that setting.
>
> --steve
>
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Martin Ritchie <ri...@apache.org>.
On 05/12/06, Steve Vinoski <vi...@iona.com> wrote:
> [Trimming the email thread down for readability]
>
> On Dec 5, 2006, at 7:46 AM, Martin Ritchie wrote:
>
> > On 04/12/06, Steve Vinoski <vi...@iona.com> wrote:
> >> 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.
> >>
> >> --steve
> >
> > This doesn't seem to work quite right for me. All the zip/tgz still
> > get built.
> > I did:
> > mvn -Pfastinstall
> > (Wish we could avoid this step and get the dist pom to reference the
> > local checkout.. and re-compile only if required)
>
> You don't have to run this step if you've already built. Just cd to
> the distribution directory and start from there.
If that is the case what code goes in to the distribution? Am I wrong
in thinking that it pulls all the jars from your maven repository? So
if I do a default 'mvn' on my highly suspect development branch then I
go to the clean head checkout distribution directory and run mvn to
generate a zip will I have the code from the head or code from my
suspect development branch?
> Note also that the framing code generation is the biggest culprit in
> terms of the lack of build avoidance. Maven didn't change this -- the
> same problem existed with ant. Every time you build, the framing code
> gets regenerated, and about 100 Java files get recompiled as a
> result. There are also 2 JMS CTS Java files under the client that get
> recompiled every time through, not sure why. These two problems add
> unnecessary time to the build, and again, they existed with ant and
> are not a maven issue. I filed a jira for the JMS CTS problem, but
> didn't for the code gen problem because I figured the new code gen
> stuff would be showing up soon (and hopefully it won't have this
> problem).
>
> > cd distribution
> > mvn -Dqpid.targetDir=c:/tmp/qpid/ assembly:directory
> >
> > Am I doing something wrong that is casuing the zips and tars to be
> > created each time?
>
> No, see my message above, where it says "You will also get the usual
> tar and zip files under $QPID_HOME/.. as well, but you'll just be
> ignoring those anyway." The job of this phase is to produce
> assemblies, so that's what happens. The assembly:directory part
> simply adds the directory as part of what gets produced.
Ah my mistake I thought the assembly:directory part was to do just the
directory build.
> Next to the tars and zips, you should see a directory named qpid-1.0-
> incubating-M2-SNAPSHOT-java-bin.
>
> > Is it possible to stop all the warning messges related to long
> > paths in the zip?
>
> Such warnings are the default, but there's a configuration setting
> for the assembly plugin called tarLongFileMode that can be set to
> "gnu" to make the warnings go away. I'll commit that change shortly,
> unless someone knows of a reason to avoid that setting.
That would be great.
> --steve
>
--
Martin Ritchie
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Steve Vinoski <vi...@iona.com>.
[Trimming the email thread down for readability]
On Dec 5, 2006, at 7:46 AM, Martin Ritchie wrote:
> On 04/12/06, Steve Vinoski <vi...@iona.com> wrote:
>> 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.
>>
>> --steve
>
> This doesn't seem to work quite right for me. All the zip/tgz still
> get built.
> I did:
> mvn -Pfastinstall
> (Wish we could avoid this step and get the dist pom to reference the
> local checkout.. and re-compile only if required)
You don't have to run this step if you've already built. Just cd to
the distribution directory and start from there.
Note also that the framing code generation is the biggest culprit in
terms of the lack of build avoidance. Maven didn't change this -- the
same problem existed with ant. Every time you build, the framing code
gets regenerated, and about 100 Java files get recompiled as a
result. There are also 2 JMS CTS Java files under the client that get
recompiled every time through, not sure why. These two problems add
unnecessary time to the build, and again, they existed with ant and
are not a maven issue. I filed a jira for the JMS CTS problem, but
didn't for the code gen problem because I figured the new code gen
stuff would be showing up soon (and hopefully it won't have this
problem).
> cd distribution
> mvn -Dqpid.targetDir=c:/tmp/qpid/ assembly:directory
>
> Am I doing something wrong that is casuing the zips and tars to be
> created each time?
No, see my message above, where it says "You will also get the usual
tar and zip files under $QPID_HOME/.. as well, but you'll just be
ignoring those anyway." The job of this phase is to produce
assemblies, so that's what happens. The assembly:directory part
simply adds the directory as part of what gets produced.
Next to the tars and zips, you should see a directory named qpid-1.0-
incubating-M2-SNAPSHOT-java-bin.
> Is it possible to stop all the warning messges related to long
> paths in the zip?
Such warnings are the default, but there's a configuration setting
for the assembly plugin called tarLongFileMode that can be set to
"gnu" to make the warnings go away. I'll commit that change shortly,
unless someone knows of a reason to avoid that setting.
--steve
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Martin Ritchie <ri...@apache.org>.
On 04/12/06, Steve Vinoski <vi...@iona.com> 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.
>
> --steve
This doesn't seem to work quite right for me. All the zip/tgz still get built.
I did:
mvn -Pfastinstall
(Wish we could avoid this step and get the dist pom to reference the
local checkout.. and re-compile only if required)
cd distribution
mvn -Dqpid.targetDir=c:/tmp/qpid/ assembly:directory
Am I doing something wrong that is casuing the zips and tars to be
created each time?
Is it possible to stop all the warning messges related to long paths in the zip?
Cheers
--
Martin Ritchie
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Gordon Sim <gs...@redhat.com>.
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!
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Steve Vinoski <vi...@iona.com>.
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.
--steve
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Gordon Sim <gs...@redhat.com>.
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?
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Steve Vinoski <vi...@iona.com>.
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?
--steve
[1] <http://jira.codehaus.org/browse/MASSEMBLY-119>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Daniel Kulp <da...@iona.com>.
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).
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2006-12-04 at 08:59 +0000, Gordon Sim wrote:
> 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.
This is the way to go: it means developers have to work with the same
structure that users see, so any problems with the installed layout will
be noticed and fixed very quickly.
Cheers,
Alan.
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Gordon Sim <gs...@redhat.com>.
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.
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Steve Vinoski <vi...@iona.com>.
On Dec 1, 2006, at 6:58 AM, Gordon Sim wrote:
> Marnie McCormack wrote:
>> All,
>> I've made a brief initial contribution to the Build instructions
>> for the
>> java trunk here:
>> http://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Build+How
>> +To
>> Please do contribute to/edit these instructions, especially if you
>> have some
>> maven tips to share which could be quickly added.
>
> Particularly if you know an easy way to build and then run the
> broker using the qpid-run scripts without having to create a
> release and untar it.
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.
For users, IMO the first approach would be cleaner. Any other
opinions or ideas? I've filed QPID-150 for this, so either post your
opinions here or attach them to that issue (or both).
--steve
Re: Qpid Java Build Instructions - Trunk (M2+)
Posted by Gordon Sim <gs...@redhat.com>.
Marnie McCormack wrote:
> All,
>
> I've made a brief initial contribution to the Build instructions for the
> java trunk here:
>
> http://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Build+How+To
>
> Please do contribute to/edit these instructions, especially if you have
> some
> maven tips to share which could be quickly added.
Particularly if you know an easy way to build and then run the broker
using the qpid-run scripts without having to create a release and untar it.