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

["Brian E. Fox" <br...@reply.infinity.nu>]

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

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

[Paul Gier <pg...@redhat.com>]

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@gmail.com> 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 <pb...@apache.org>
>> 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 <br...@reply.infinity.nu>
>>> 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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 


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

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

[Paul Benedict <pb...@apache.org>]

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@gmail.com> 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 <pb...@apache.org>
> 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 <br...@reply.infinity.nu>
> > 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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

[Stephen Connolly <st...@gmail.com>]

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 <pb...@apache.org> 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 <br...@reply.infinity.nu>
> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

[Paul Benedict <pb...@apache.org>]

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 <br...@reply.infinity.nu>
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.
>

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

["Brian E. Fox" <br...@reply.infinity.nu>]

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

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

[Benjamin Bentmann <be...@udo.edu>]

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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

[Paul Gier <pg...@redhat.com>]

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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

[Paul Benedict <pb...@apache.org>]

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 <br...@reply.infinity.nu>
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.
>