[Proposal] Pom Code Style (WAS svn commit: r670264 - /maven/plugins/trunk/maven-site-plugin/pom.xml)

[Benjamin Bentmann]

Brett Porter wrote:

> I also find a few things weird about the order. IMO,
> - dependencies and repositories should be together
> - dependencies and dependencyManagement should be together
> - build should be after dependencies, etc
> - profiles should be after everything else.

Seems like our latest sketch [0] handles this, doesn't it?


Benjamin


[0]
http://www.nabble.com/Re%3A--Proposal--Pom-Code-Style-(WAS-svn-commit%3A-r670264----maven-plugins-trunk-maven-site-plugin-pom.xml)-p18183300.html

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

[brettporter]

On 01/07/2008, at 12:46 AM, Benjamin Bentmann wrote:

> Brett Porter wrote:
>
>> I also find a few things weird about the order. IMO,
>> - dependencies and repositories should be together
>> - dependencies and dependencyManagement should be together
>> - build should be after dependencies, etc
>> - profiles should be after everything else.
>
> Seems like our latest sketch [0] handles this, doesn't it?

Yes - sorry I thought Vincent was working off that which is why I  
thought it was weird. I might have just read the messages out of order.

- Brett

>
>
>
> Benjamin
>
>
> [0] http://www.nabble.com/Re%3A--Proposal--Pom-Code-Style-(WAS-svn-commit%3A-r670264----maven-plugins-trunk-maven-site-plugin-pom.xml)-p18183300.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[Brian E Fox]

Sorting the dependencies purely for aesthetic reasons is a bad idea given the current first-wins scenario.

-----Original Message-----
From: John Casey [mailto:jdcasey@...]
Sent: Monday, June 30, 2008 9:56 AM
To: Maven Developers List
Subject: Re: [Proposal] Pom Code Style (WAS svn commit: r670264 - /maven/plugins/trunk/maven-site-plugin/pom.xml)

Please keep in mind that the ordering of dependencies can (in some
cases) change which version of a particular transitive dependency is
used. If two direct dependencies both reference a third dependency - but
using different versions - then the current resolution technique keeps
the first one encountered, iff the two references happen at the same
"level" of transitivity (distance from the current POM). Therefore,
simply alphabetizing the dependencies list could change the transitive
dependency list used for your build.

-john

Benjamin Bentmann wrote:

> Paul Gier wrote:
>
>> Anyway, I definitely like the idea of a pom plugin to do
>> "pom:reformat" or "pom:reorder" and maybe I can add a parameter about
>> sorting the dependencies.
>
> Instead of a parameter, I believe sorting the dependencies should be a
> distinct mojo. Otherwise, how to handle the use case of only sorting
> dependencies, i.e. neither reformat nor reorder all the rest?
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/


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

[djencks]

On Jun 30, 2008, at 9:21 AM, Brian E. Fox wrote:

> Sorting the dependencies purely for aesthetic reasons is a bad idea  
> given the current first-wins scenario.

I would rather have the dependency resolver throw an exception or emit  
a very obvious warning in the case where it has to use the order of  
dependencies in the top level pom to decide which version to use, and  
have the easy ability to sort the dependencies.  I've seen too many  
projects with duplicate dependencies because there are a hundred or so  
in random order.

thanks
david jencks

>
>
> -----Original Message-----
> From: John Casey [mailto:jdcasey@...]
> Sent: Monday, June 30, 2008 9:56 AM
> To: Maven Developers List
> Subject: Re: [Proposal] Pom Code Style (WAS svn commit: r670264 - /
> maven/plugins/trunk/maven-site-plugin/pom.xml)
>
> Please keep in mind that the ordering of dependencies can (in some
> cases) change which version of a particular transitive dependency is
> used. If two direct dependencies both reference a third dependency -  
> but
> using different versions - then the current resolution technique keeps
> the first one encountered, iff the two references happen at the same
> "level" of transitivity (distance from the current POM). Therefore,
> simply alphabetizing the dependencies list could change the transitive
> dependency list used for your build.
>
> -john
>
> Benjamin Bentmann wrote:
>> Paul Gier wrote:
>>
>>> Anyway, I definitely like the idea of a pom plugin to do
>>> "pom:reformat" or "pom:reorder" and maybe I can add a parameter  
>>> about
>>> sorting the dependencies.
>>
>> Instead of a parameter, I believe sorting the dependencies should  
>> be a
>> distinct mojo. Otherwise, how to handle the use case of only sorting
>> dependencies, i.e. neither reformat nor reorder all the rest?
>>
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.ejlife.net/blogs/buildchimp/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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

[Paul Gier]

I understand your concerns, but the same issue can happen when adding or
removing a dependency, not just reordering.  I would rather recommend that
people rely on dependency management to control transitive versions than rely on
the order in the pom.  Then you should be able to organize deps in your pom
anyway you want.

Brian E. Fox wrote:

> Sorting the dependencies purely for aesthetic reasons is a bad idea given the current first-wins scenario.
>
> -----Original Message-----
> From: John Casey [mailto:jdcasey@...]
> Sent: Monday, June 30, 2008 9:56 AM
> To: Maven Developers List
> Subject: Re: [Proposal] Pom Code Style (WAS svn commit: r670264 - /maven/plugins/trunk/maven-site-plugin/pom.xml)
>
> Please keep in mind that the ordering of dependencies can (in some
> cases) change which version of a particular transitive dependency is
> used. If two direct dependencies both reference a third dependency - but
> using different versions - then the current resolution technique keeps
> the first one encountered, iff the two references happen at the same
> "level" of transitivity (distance from the current POM). Therefore,
> simply alphabetizing the dependencies list could change the transitive
> dependency list used for your build.
>
> -john
>
> Benjamin Bentmann wrote:
>> Paul Gier wrote:
>>
>>> Anyway, I definitely like the idea of a pom plugin to do
>>> "pom:reformat" or "pom:reorder" and maybe I can add a parameter about
>>> sorting the dependencies.
>> Instead of a parameter, I believe sorting the dependencies should be a
>> distinct mojo. Otherwise, how to handle the use case of only sorting
>> dependencies, i.e. neither reformat nor reorder all the rest?
>>
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>

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

[Brian E Fox]

>I understand your concerns, but the same issue can happen when adding or
>removing a dependency, not just reordering.  I would rather recommend that
>people rely on dependency management to control transitive versions than rely on
>the order in the pom.  Then you should be able to organize deps in your pom
>anyway you want.

As would I, but allowing people to completely hose their build for no good reason isn't a good idea. At a minimum, this goal should back up the existing pom and give a stern warning that they may get build or runtime issues by doing this. Remember, the issue may not show up immediately but only later at runtime.

[Paul Benedict-2]

When you reorder, you should be able to do a -DdryRun and let it produce for
you a "pom.xml.reorder" file.

And when you run the reordering for real, let it create a "pom.xml.backup"

Hey, doesn't this sound just like the philosophy of the release plugin? :-)

Paul

On Tue, Jul 1, 2008 at 11:26 AM, Brian E. Fox <brianf@...>
wrote:

>
> >I understand your concerns, but the same issue can happen when adding or
> >removing a dependency, not just reordering.  I would rather recommend that
> >people rely on dependency management to control transitive versions than
> rely on
> >the order in the pom.  Then you should be able to organize deps in your
> pom
> >anyway you want.
>
> As would I, but allowing people to completely hose their build for no good
> reason isn't a good idea. At a minimum, this goal should back up the
> existing pom and give a stern warning that they may get build or runtime
> issues by doing this. Remember, the issue may not show up immediately but
> only later at runtime.
>

[Paul Gier]

Brian E. Fox wrote:
>> I understand your concerns, but the same issue can happen when adding or
>> removing a dependency, not just reordering.  I would rather recommend that
>> people rely on dependency management to control transitive versions than rely on
>> the order in the pom.  Then you should be able to organize deps in your pom
>> anyway you want.
>
> As would I, but allowing people to completely hose their build for no good reason isn't a good idea. At a minimum, this goal should back up the existing pom and give a stern warning that they may get build or runtime issues by doing this. Remember, the issue may not show up immediately but only later at runtime.

If people want to hose their build, there is not much we can do to stop them ;)
Are you thinking that this dependency sort would run automatically during the
release process?  I was imagining this used during the development cycle, so
that any changes it causes would go through some cycles of testing.  Obviously,
I would be very concerned if something like this was run during the release process.

I'm fine with adding a warning, but this goal doesn't need to create a backup
(at least not by default) because there should already be a backup of the pom in
svn/cvs/etc.  Anyone who makes any changes to their pom and then doesn't test it
before committing to svn is going to have the same problem of breaking the build
with or without a local backup copy.

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

[Benjamin Bentmann]

Paul Gier wrote:

> I was imagining this used during the
> development cycle, so that any changes it causes would go through some
> cycles of testing.

Maybe the first test could be performed by the POM Plugin itself, i.e.
have it calculate the transitive deps before the POM change and
afterwards and output a detailed warning in case the two artifact sets
differ.

> but this goal doesn't need to create a
> backup (at least not by default) because there should already be a
> backup of the pom in svn/cvs/etc.

+1, scm diff/revert should suffice.


Benjamin

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

[Brian E Fox]

>If people want to hose their build, there is not much we can do to stop them ;)
>Are you thinking that this dependency sort would run automatically during the
>release process?  I was imagining this used during the development cycle, so
>that any changes it causes would go through some cycles of testing.  Obviously,
>I would be very concerned if something like this was run during the release process.

I'm concerned that we're just giving people a loaded gun that we hope they don't shoot themselves with...particularly when the end result didn't really do much useful other than pretty up their source. If the tool can somehow analyze the transitive results of the changes, great. Actually I think this part of the tool might be the best piece to have so you can analyze results across any pom changes, not just sorting.

[Paul Benedict-2]

I must have missed something in the discussion. Please forgive my ignorance
here, but why is so much discussion happening on reordering the
dependencies? Honestly, they shouldn't be reordered. I list out my
dependencies in pure alphabetical order by group and artifact, and I
wouldn't want those messed with when I clean up the POM.

Paul

On Wed, Jul 2, 2008 at 1:58 PM, Brian E. Fox <brianf@...>
wrote:

>
> >If people want to hose their build, there is not much we can do to stop
> them ;)
> >Are you thinking that this dependency sort would run automatically during
> the
> >release process?  I was imagining this used during the development cycle,
> so
> >that any changes it causes would go through some cycles of testing.
>  Obviously,
> >I would be very concerned if something like this was run during the
> release process.
>
> I'm concerned that we're just giving people a loaded gun that we hope they
> don't shoot themselves with...particularly when the end result didn't really
> do much useful other than pretty up their source. If the tool can somehow
> analyze the transitive results of the changes, great. Actually I think this
> part of the tool might be the best piece to have so you can analyze results
> across any pom changes, not just sorting.
>

[Stephen Connolly-2]

The issue is that the order of dependencies does matter.

Resolving transitive dependencies is based on how near the dependency
is to the pom and the order in which dependencies are listed...

Listing them in alpha order, if you've always done this is fine and
won't change your build (as you've always done so)

but if you now change the order to random order, because the
resolution of transitive dependencies uses the order dependencies are
listed in the pom as the penalty-shoot-out, your build _may_ pull in
different dependencies.

Actually, penalty shoot out is probably not the best analogy, more
like number of away goals... you've matched on points, you've matched
on goal difference, you've matched on away wins and the only thing
left to decide who wins the league is away goals.

Personally, I think if Maven can provide a warning when your build is
resolving dependencies based on dependency order in a pom, that would
be a _good thing_

-Stephen

On Thu, Jul 3, 2008 at 4:37 AM, Paul Benedict <pbenedict@...> wrote:

> I must have missed something in the discussion. Please forgive my ignorance
> here, but why is so much discussion happening on reordering the
> dependencies? Honestly, they shouldn't be reordered. I list out my
> dependencies in pure alphabetical order by group and artifact, and I
> wouldn't want those messed with when I clean up the POM.
>
> Paul
>
> On Wed, Jul 2, 2008 at 1:58 PM, Brian E. Fox <brianf@...>
> wrote:
>
>>
>> >If people want to hose their build, there is not much we can do to stop
>> them ;)
>> >Are you thinking that this dependency sort would run automatically during
>> the
>> >release process?  I was imagining this used during the development cycle,
>> so
>> >that any changes it causes would go through some cycles of testing.
>>  Obviously,
>> >I would be very concerned if something like this was run during the
>> release process.
>>
>> I'm concerned that we're just giving people a loaded gun that we hope they
>> don't shoot themselves with...particularly when the end result didn't really
>> do much useful other than pretty up their source. If the tool can somehow
>> analyze the transitive results of the changes, great. Actually I think this
>> part of the tool might be the best piece to have so you can analyze results
>> across any pom changes, not just sorting.
>>
>

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

[Paul Benedict-2]

Stephen,

That's fine, but I thought the proposal was to reorder the dependencies in
the POM? Is there a plan to clean the POM without reordering the
dependencies?

Paul

On Thu, Jul 3, 2008 at 3:03 AM, Stephen Connolly <
stephen.alan.connolly@...> wrote:

> The issue is that the order of dependencies does matter.
>
> Resolving transitive dependencies is based on how near the dependency
> is to the pom and the order in which dependencies are listed...
>
> Listing them in alpha order, if you've always done this is fine and
> won't change your build (as you've always done so)
>
> but if you now change the order to random order, because the
> resolution of transitive dependencies uses the order dependencies are
> listed in the pom as the penalty-shoot-out, your build _may_ pull in
> different dependencies.
>
> Actually, penalty shoot out is probably not the best analogy, more
> like number of away goals... you've matched on points, you've matched
> on goal difference, you've matched on away wins and the only thing
> left to decide who wins the league is away goals.
>
> Personally, I think if Maven can provide a warning when your build is
> resolving dependencies based on dependency order in a pom, that would
> be a _good thing_
>
> -Stephen
>
> On Thu, Jul 3, 2008 at 4:37 AM, Paul Benedict <pbenedict@...>
> wrote:
> > I must have missed something in the discussion. Please forgive my
> ignorance
> > here, but why is so much discussion happening on reordering the
> > dependencies? Honestly, they shouldn't be reordered. I list out my
> > dependencies in pure alphabetical order by group and artifact, and I
> > wouldn't want those messed with when I clean up the POM.
> >
> > Paul
> >
> > On Wed, Jul 2, 2008 at 1:58 PM, Brian E. Fox <brianf@...>
> > wrote:
> >
> >>
> >> >If people want to hose their build, there is not much we can do to stop
> >> them ;)
> >> >Are you thinking that this dependency sort would run automatically
> during
> >> the
> >> >release process?  I was imagining this used during the development
> cycle,
> >> so
> >> >that any changes it causes would go through some cycles of testing.
> >>  Obviously,
> >> >I would be very concerned if something like this was run during the
> >> release process.
> >>
> >> I'm concerned that we're just giving people a loaded gun that we hope
> they
> >> don't shoot themselves with...particularly when the end result didn't
> really
> >> do much useful other than pretty up their source. If the tool can
> somehow
> >> analyze the transitive results of the changes, great. Actually I think
> this
> >> part of the tool might be the best piece to have so you can analyze
> results
> >> across any pom changes, not just sorting.
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Paul Gier]

Yes, this thread started as a way to just clean up the formatting of the POM.
Sorting the dependencies alphabetically would be a separate mojo of the
formatting plugin or just an option to this formatting.

Paul Benedict wrote:

> Stephen,
>
> That's fine, but I thought the proposal was to reorder the dependencies in
> the POM? Is there a plan to clean the POM without reordering the
> dependencies?
>
> Paul
>
> On Thu, Jul 3, 2008 at 3:03 AM, Stephen Connolly <
> stephen.alan.connolly@...> wrote:
>
>> The issue is that the order of dependencies does matter.
>>
>> Resolving transitive dependencies is based on how near the dependency
>> is to the pom and the order in which dependencies are listed...
>>
>> Listing them in alpha order, if you've always done this is fine and
>> won't change your build (as you've always done so)
>>
>> but if you now change the order to random order, because the
>> resolution of transitive dependencies uses the order dependencies are
>> listed in the pom as the penalty-shoot-out, your build _may_ pull in
>> different dependencies.
>>
>> Actually, penalty shoot out is probably not the best analogy, more
>> like number of away goals... you've matched on points, you've matched
>> on goal difference, you've matched on away wins and the only thing
>> left to decide who wins the league is away goals.
>>
>> Personally, I think if Maven can provide a warning when your build is
>> resolving dependencies based on dependency order in a pom, that would
>> be a _good thing_
>>
>> -Stephen
>>
>> On Thu, Jul 3, 2008 at 4:37 AM, Paul Benedict <pbenedict@...>
>> wrote:
>>> I must have missed something in the discussion. Please forgive my
>> ignorance
>>> here, but why is so much discussion happening on reordering the
>>> dependencies? Honestly, they shouldn't be reordered. I list out my
>>> dependencies in pure alphabetical order by group and artifact, and I
>>> wouldn't want those messed with when I clean up the POM.
>>>
>>> Paul
>>>
>>> On Wed, Jul 2, 2008 at 1:58 PM, Brian E. Fox <brianf@...>
>>> wrote:
>>>
>>>>> If people want to hose their build, there is not much we can do to stop
>>>> them ;)
>>>>> Are you thinking that this dependency sort would run automatically
>> during
>>>> the
>>>>> release process?  I was imagining this used during the development
>> cycle,
>>>> so
>>>>> that any changes it causes would go through some cycles of testing.
>>>>  Obviously,
>>>>> I would be very concerned if something like this was run during the
>>>> release process.
>>>>
>>>> I'm concerned that we're just giving people a loaded gun that we hope
>> they
>>>> don't shoot themselves with...particularly when the end result didn't
>> really
>>>> do much useful other than pretty up their source. If the tool can
>> somehow
>>>> analyze the transitive results of the changes, great. Actually I think
>> this
>>>> part of the tool might be the best piece to have so you can analyze
>> results
>>>> across any pom changes, not just sorting.
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>

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