qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Maven parent
Date Tue, 06 Oct 2015 11:10:46 GMT
On 6 October 2015 at 10:57, Oleksandr Rudyy <orudyy@gmail.com> wrote:
> Hi guys,
>
> We have a maven project in  Qpid svn root [1]. At the moment it does
> not have much attention and care. Thus, it contains outdated
> information. Only Qpid java components depend on it at the moment.
>
> I am going to remove that dependency in qpid-java-6 and move some of
> useful parent pom functionality into qpid-java pom.xml in order to
> implement some urgent changes to license generation and checks
> reported as blocker [2]. Otherwise, we need to release a new parent
> pom version with the changes. That requires separate release process,
> including voting, which is unnecessary overhead to our release
> process.
>
> When I remove the dependency to Qpid parent pom from qpid-java, it
> will became unused and potentially could be deleted.
>
> Shall we delete it? Any thoughts?
>
> In future we are planning to split qpid-java into 2 separate projects:
> qpid java broker and qpid legacy jms client. We might need parent pom
> project for them but I am not sure.
>
> Kind Regards,
> Alex
>
> [1] https://svn.apache.org/repos/asf/qpid/maven
> [2] https://issues.apache.org/jira/browse/QPID-6772
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>

The parent seemed like a reasonable idea at the time. Once Andrew
picked up the early maven build work I did a couple years ago, he set
about cleaning up some of the hackery that had 'evolved' over the
weeks of 30mins-here-and-there I had put it together in. One set of
that was a huge group of overrides for the plugin versions I had,
since the apache parent pom was quite out of date at the time in terms
of its plugin versions, and updating them all gave very significant
feature and performance benefits. It seemed reasonable to share all
the overrides rather than saddle the main pom in each tree with
similarly huge config, and added to that were versions for
dependencies etc to ease alignment.

Fast forwarding, other components aren't using the parent, the apache
parent is kept much fresher these days so there isn't need to override
plugins much, and in hindsight the various components dont share many
dependencies that alignment is of real concern. Adding in the overhead
of releasing the parent, I'd agree it makes sense not to bother with
it given all it is really doing now. I'd delete it.

As an aside....I wouldnt really consider [2] a blocker. Its an
optional developer aid that has no effect by default, isnt strictly
necessary at all, and is basically reporting a non-issue due to some
config tweaking needed to address its inherantly fragile nature.

Robbie

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message