POM file changes: unnecessary declarations of projectId and versionId

Stefan Negrea snegrea at redhat.com
Tue Oct 11 15:00:16 UTC 2011



----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Monday, October 10, 2011 7:52:45 AM
> Subject: Re: POM file changes: unnecessary declarations of	projectId	and	versionId
> 
> 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.

A clarification, the RHQ release script is no longer using maven release plugin (and will not use it in the future!). During the refactoring I moved the scripts to use the much simpler maven versions plugin. So this will not be an issue going forward.

> 
> 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
> 


More information about the rhq-devel mailing list