POM file changes: unnecessary declarations of projectId and versionId

Ian Springer ian.springer at redhat.com
Mon Oct 10 16:54:24 UTC 2011


The change should be fine. We have a lot of residual stuff in our poms 
from either 1) workarounds for early bugs in Maven 2 (we started using 
it in the 2.0.0 era when it was very buggy), and 2) stuff we did before 
we were as familiar with Maven 2 as we are now.

Another example of 2) is that in many places we declare explicit 
versions for Maven plugins - this is a bad practice, because you end up 
using different versions of the same plugins throughout the project; 
instead all plugin versions should be declared in the pluginManagement 
section of the root pom and inherited from there by all other poms. I've 
been gradually fixing these as I come across them; please do the same if 
you notice any of them.

On 10/10/2011 09:20 AM, Jay Shaughnessy wrote:
> "...you can remove the groupId"  != "you should remove..." : )
>
> Anyway, we've bent over backwards at times to get maven to do what it
> says it should do.  mazz was simply implying that there may, or may
> not,  be a reason it is like it is.  Simplifying the poms is great if
> maven is working the way it's supposed to.  I think the take away here
> is just to do a quick due diligence to see if anyone knows a reason
> behind the current coding.  And of course a reminder to document in line
> to help future folks understand why something was done in a certain way.
>
>
> On 10/10/2011 8:52 AM, John Mazzitelli wrote:
>> My concern wasn't that what you did was wrong, rather, it was "ask ips
>> to see what he says because I remember him taking things out of the pom,
>> like what you just did, and while you'd think it would work because the
>> docs says it would work, it didn't for one reason or another".
>>
>> I'm thinking specifically of the release script we have and how it uses
>> some sort of maven release plugin that goes through and modifies the
>> poms - there were bugs in that process that I remember ips having to fight.
>>
>> Now back to our regularly scheduled program.
>>
>> On 10/10/2011 08:40 AM, Robert Buck wrote:
>>>     Guys,
>>>
>>> Please refrain from forming judgments not based in fact. Rather, letting
>>> the facts be known, let me draw your attention to the manual
>>> (Introduction to the POM, Section 4, Paragraph 5):
>>>
>>>       "...if we want the groupId and / or the version of your modules to
>>>       be the same as their parents, you can remove the groupId and / or
>>>       the version identity of your module in its POM."
>>>
>>>
>>> This stuff has been in Maven since its dawn of time. And as this reduces
>>> the defect surface and improves developer productivity, I think you
>>> should reconsider your positions.
>>>
>>> I think we should be encouraging folks to reduce both the attack and
>>> defect surface of JON, not increase it or acquiesce to the ways things
>>> have always been done, especially when they aren't right.
>>>
>>> -Bob
>>>
>>> On 10/07/2011 10:41 AM, Charles Crouch wrote:
>>>> Well the base hudson build of master passed with these changes, but I echo your concerns mazz.
>>>> If this causes problems for spinder and stefan re: the releases builds, we're going to have to roll it back.
>>>>
>>>> I don't think there is any disagreement that our build can be improved, it just needs to be done carefully and in concert for all parts of our process, not just dev builds.
>>>>
>>>> Thanks
>>>> Charles
>>>> ----- Original Message -----
>>>>> I can tell you way back when, our poms did not specify things that
>>>>> should have been inherited from the parent but it didn't work
>>>>> (probably
>>>>> due to maven bugs perhaps) and so we had to add them back in. Things
>>>>> you
>>>>> wouldn't think would be needed were.
>>>>>
>>>>> So, I would be careful when doing things like this without discussing
>>>>> with Ian. Ian did ALOT of tweeking of these poms over the years and
>>>>> many
>>>>> times I noticed he added or removed things that you would think
>>>>> wouldn't
>>>>> be needed but were.
>>>>>
>>>>>
>>>>> On 10/07/2011 09:25 AM, Robert Buck wrote:
>>>>>>      Hello,
>>>>>>
>>>>>> I just pushed a change to some of the Maven POM files; I cleaned up
>>>>>> some
>>>>>> redundant declarations that made using IntelliJ with the RHQ
>>>>>> project
>>>>>> intolerable. Prior to this change nearly every third-party import,
>>>>>> reference to types, and the like, would show up in red-line mode in
>>>>>> source files, making it impossible to distinguish between
>>>>>> legitimate
>>>>>> coding typos/mistakes and Maven ones. While the change does not
>>>>>> completely fix all Maven-to-IntelliJ integration issues, it does at
>>>>>> least make use of IntelliJ tolerable with the RHQ project.
>>>>>>
>>>>>> Properties that are inherited from a parent-POM should not be
>>>>>> redeclared
>>>>>> a second time. If this is done, source files in that module will
>>>>>> show up
>>>>>> as code-red files.
>>>>>>
>>>>>> <parent>
>>>>>> <groupId>org.rhq</groupId>
>>>>>> <artifactId>rhq-core-parent</artifactId>
>>>>>> <version>4.1.0-SNAPSHOT</version>
>>>>>> </parent>
>>>>>>
>>>>>> *<groupId>org.rhq</groupId>*<    UNNECESSSARY
>>>>>> <artifactId>rhq-core-domain</artifactId>
>>>>>> <packaging>ejb</packaging>
>>>>>>
>>>>>> The fix was simple, to remove the second groupId declaration.
>>>>>>
>>>>>> diff --git a/modules/enterprise/server/ear/pom.xml
>>>>>> b/modules/enterprise/server/ear/pom.xml
>>>>>> index 783e377..b0a5468 100644
>>>>>> --- a/modules/enterprise/server/ear/pom.xml
>>>>>> +++ b/modules/enterprise/server/ear/pom.xml
>>>>>> @@ -9,7 +9,6 @@
>>>>>> <relativePath>../../../../pom.xml</relativePath>
>>>>>> </parent>
>>>>>>
>>>>>> *-<groupId>org.rhq</groupId>*
>>>>>> <artifactId>rhq-enterprise-server-ear</artifactId>
>>>>>> <packaging>ear</packaging>
>>>>>>
>>>>>> For those IntelliJ users out there, hope your life is easier now.
>>>>>> Lets
>>>>>> find other ways of improving the POM files so that other IntelliJ
>>>>>> limitations due to our use of Maven are resolved.
>>>>>>
>>>>>> -Bob
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> rhq-devel mailing list
>>>>>> rhq-devel at lists.fedorahosted.org
>>>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>> _______________________________________________
>>>>> rhq-devel mailing list
>>>>> rhq-devel at lists.fedorahosted.org
>>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>>
>>>> _______________________________________________
>>>> rhq-devel mailing list
>>>> rhq-devel at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer at redhat.com



More information about the rhq-devel mailing list