You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rafael Schloming <ra...@redhat.com> on 2009/07/07 22:20:57 UTC
build changes and pom generation
I've attached a patch that generates poms. It uses a script that takes
as input the library dependencies for a given module, and outputs a pom
file for the module. The script works by scanning a directory containing
poms for maven metadata on the dependencies, and uses this metadata to
build a pom for the module.
The patch also modifies the build system to place disposable build
output underneath build/scratch. This is really unrelated to the pom
change, however it was something we discussed doing a while back and
staring at all the crud in the build dir as I was testing the pom patch
provided some motivation for me to actually make the change.
The patch is fairly non-invasive, but I figured I'd give a heads up as
it changes the location of the .class files underneath the build dir,
and this may end up breaking certain dev environments.
Please give me a shout if there are any issues or objections, otherwise
I'll commit this patch tomorrow.
--Rafael
Re: build changes and pom generation
Posted by Marnie McCormack <ma...@googlemail.com>.
Thanks Rafi & Bryan for shedding some light. I hope the battle scars heal
fast (I may still nursing some from M1 tho ..) !
Am comfortable with the approach (very much) but glad to hear that there's a
been a debate (heated or otherwise).
Thanks for the info,
Regards,
Marnie
On Fri, Jul 10, 2009 at 8:44 PM, Bryan Kearney <bk...@redhat.com> wrote:
> Rafael Schloming wrote:
>
>> Marnie McCormack wrote:
>>
>>> Hi Rafi,
>>>
>>> Without in any way wishing to pick the scab off the last discussion about
>>> POM generation, how does this sit with Bryan's work or was there an arm
>>> wrestling session that we missed out on ?
>>>
>>
>> I guess given only those two alternatives the answer would be the latter.
>> ;)
>>
>> After checking out Bryan's patch, I was reluctant to encourage further
>> work in that direction for a number of reasons. The patch was a fairly
>> fundamental change to the build system, and it still needed a fair bit more
>> work to function adequately. Beyond that even if the functional issues could
>> have been addressed, I still wasn't comfortable with the basic approach as I
>> felt that it unnecessarily and undesirably tied us into the whole maven
>> ecosystem. For this reason I developed an alternative less invasive approach
>> for generating poms that I sent around to Bryan and Aidan before posting to
>> the dev list.
>>
>> Did you have any questions/concerns? I'm happy to post the off-list thread
>> if the other participants consent.
>>
>
> Go ahead and post the discussion. BTW... the patch did function, just
> needed to add a few more ivy.xml files. :)
>
> FWIW.. I tend to prefer the ivy approach, but my main goal is to get the
> client jars into the central maven repo. As long as we can achieve that as
> part of the normal build process I am happy. I believe this is important to
> encourage adoption of qmf in java. Regardless of folks opinion of maven, it
> is a common way to consume the jars.
>
> -- bk
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: build changes and pom generation
Posted by Bryan Kearney <bk...@redhat.com>.
Rafael Schloming wrote:
> Marnie McCormack wrote:
>> Hi Rafi,
>>
>> Without in any way wishing to pick the scab off the last discussion about
>> POM generation, how does this sit with Bryan's work or was there an arm
>> wrestling session that we missed out on ?
>
> I guess given only those two alternatives the answer would be the
> latter. ;)
>
> After checking out Bryan's patch, I was reluctant to encourage further
> work in that direction for a number of reasons. The patch was a fairly
> fundamental change to the build system, and it still needed a fair bit
> more work to function adequately. Beyond that even if the functional
> issues could have been addressed, I still wasn't comfortable with the
> basic approach as I felt that it unnecessarily and undesirably tied us
> into the whole maven ecosystem. For this reason I developed an
> alternative less invasive approach for generating poms that I sent
> around to Bryan and Aidan before posting to the dev list.
>
> Did you have any questions/concerns? I'm happy to post the off-list
> thread if the other participants consent.
Go ahead and post the discussion. BTW... the patch did function, just
needed to add a few more ivy.xml files. :)
FWIW.. I tend to prefer the ivy approach, but my main goal is to get the
client jars into the central maven repo. As long as we can achieve that
as part of the normal build process I am happy. I believe this is
important to encourage adoption of qmf in java. Regardless of folks
opinion of maven, it is a common way to consume the jars.
-- bk
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: build changes and pom generation
Posted by Rafael Schloming <ra...@redhat.com>.
Marnie McCormack wrote:
> Hi Rafi,
>
> Without in any way wishing to pick the scab off the last discussion about
> POM generation, how does this sit with Bryan's work or was there an arm
> wrestling session that we missed out on ?
I guess given only those two alternatives the answer would be the latter. ;)
After checking out Bryan's patch, I was reluctant to encourage further
work in that direction for a number of reasons. The patch was a fairly
fundamental change to the build system, and it still needed a fair bit
more work to function adequately. Beyond that even if the functional
issues could have been addressed, I still wasn't comfortable with the
basic approach as I felt that it unnecessarily and undesirably tied us
into the whole maven ecosystem. For this reason I developed an
alternative less invasive approach for generating poms that I sent
around to Bryan and Aidan before posting to the dev list.
Did you have any questions/concerns? I'm happy to post the off-list
thread if the other participants consent.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: build changes and pom generation
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Rafi,
Without in any way wishing to pick the scab off the last discussion about
POM generation, how does this sit with Bryan's work or was there an arm
wrestling session that we missed out on ?
Ducking,
Marnie
On Tue, Jul 7, 2009 at 9:20 PM, Rafael Schloming <ra...@redhat.com> wrote:
> I've attached a patch that generates poms. It uses a script that takes as
> input the library dependencies for a given module, and outputs a pom file
> for the module. The script works by scanning a directory containing poms for
> maven metadata on the dependencies, and uses this metadata to build a pom
> for the module.
>
> The patch also modifies the build system to place disposable build output
> underneath build/scratch. This is really unrelated to the pom change,
> however it was something we discussed doing a while back and staring at all
> the crud in the build dir as I was testing the pom patch provided some
> motivation for me to actually make the change.
>
> The patch is fairly non-invasive, but I figured I'd give a heads up as it
> changes the location of the .class files underneath the build dir, and this
> may end up breaking certain dev environments.
>
> Please give me a shout if there are any issues or objections, otherwise
> I'll commit this patch tomorrow.
>
> --Rafael
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>