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 th
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 <
[EMAIL PROTECTED]> wrote:
> The issue is that the order of dependencies does
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 alw
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 mes
>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 o
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 a
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
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,
>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 d
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
From: John Casey [mailto:[EMAIL PROTECTED]
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) c
Sorting the dependencies purely for aesthetic reasons is a bad idea given the
current first-wins scenario.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2008 9:56 AM
To: Maven Developers List
Subject: Re: [Proposal] Pom Code Style (WAS svn commit
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 shou
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 ske
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 e
I've just reverted a portion of the change to distributionManagement
as it was breaking CI (you can't move things between objects).
I also find a few things weird about the order. IMO,
- dependencies and repositories should be together
- dependencies and dependencyManagement should be together
Vincent Siveton wrote:
IMHO devs should be after licenses, since they describe more a project
than a build.
[...]
same reasoning for ML.
[...]
I propose to put dependencyManagement before dependencies to improve
the readingness.
All fine with me. Also taking into account Paul Benedict's sugges
Hi,
2008/6/29, Benjamin Bentmann <[EMAIL PROTECTED]>:
> Vincent Siveton wrote:
>
>
> > FYI I created MNG-3634 and you could see the result here:
> >
> http://people.apache.org/~vsiveton/MNG-3634/maven-2.0.x/site/maven.html
> >
> > Comments are welcome!
> >
>
> I prefer your initial suggestion, wh
If you're going to reorder the POM, put before
or even higher. I've seen them used to specify dependencies, build info, and
alot of other things. Properties aren't just left overs, they are an early
step in the build process and should be "early" in the POM too.
Paul
On Sun, Jun 29, 2008 at 4:
Vincent Siveton wrote:
FYI I created MNG-3634 and you could see the result here:
http://people.apache.org/~vsiveton/MNG-3634/maven-2.0.x/site/maven.html
Comments are welcome!
I prefer your initial suggestion, which might be looking like that after
incorporating the other elements:
Hi,
FYI I created MNG-3634 and you could see the result here:
http://people.apache.org/~vsiveton/MNG-3634/maven-2.0.x/site/maven.html
Comments are welcome!
Cheers,
Vincent
2008/6/23, Vincent Siveton <[EMAIL PROTECTED]>:
> Hi,
>
> I propose to improve [1] to add a code style for our pom files.
I agree with Dennis, though if any reordering is to be done I think
the order proposed by Vincent makes sense.
I agree with Jesse and Paul about adding goals to the POM plugin to
help adjust POMs.
Cheers,
Brett
On 26/06/2008, at 1:29 AM, Jesse McConnell wrote:
+1, great idea
Not sure it
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 cas
I originally just wrote some code because I wanted to put the dependencies in my
pom in alphabetical order and/or grouped by scope. Then I was thinking that
there could be a general pom plugin to do things like sort the dependencies or
reformat etc [1]. I didn't realize that there was already
Jesse McConnell wrote:
pom:reformat would be pretty nice
+1, cool idea. Might we worth to distinguish the use cases "reorder" and
"reformat", i.e. separate indentation stuff from element ordering.
BTW, Paul had once started a Pom Plugin [0], maybe there is something to
reuse/merge.
Benj
+1, great idea
Not sure it was mentioned before or not but would also be nice to have
something like help:reformat goal for juggling things around in the
pom to the correct format. Maybe it would be more appropriate to
clean up and finish off some of the things I had worked on with the
pom plugin
Benjamin Bentmann wrote:
Vincent Siveton schrieb:
I propose to improve [1] to add a code style for our pom files.
+1 for some convention (which is documented as such).
Yep, +1 for a POM code style
I see the following in this order.
Considering other POMs like parent POMs and Mojo, your
+1
On 24-Jun-08, at 9:48 AM, John Casey wrote:
It would probably be a good idea to reorder the fields in the
maven.mdo file inside the maven-model project, to reflect the
preferred style. This should have the effect of reordering the
generated reference documentation and will also affect t
i would say
first the definition of the module (parent, packaging, name, groupid,
artifactid)
latest modelVersion, issuemanagment, scm, deployment
in the middle, i am not sure
Raphaël
2008/6/24 John Casey <[EMAIL PROTECTED]>:
> Does that mean plugin configurations come first? That could be prett
Does that mean plugin configurations come first? That could be pretty
hard to wade through...
Raphaël Piéroni wrote:
Hi folks,
As i lazy user, i would like the automatic ordering to write things
in a specific order: first come the things that have the greater
chance to be changed/read,
and the
Hi folks,
As i lazy user, i would like the automatic ordering to write things
in a specific order: first come the things that have the greater
chance to be changed/read,
and then go to the end of the file with things that are not relevant
for a reader/modifier
ending with modelVersion.
my 2 cents
It would probably be a good idea to reorder the fields in the maven.mdo
file inside the maven-model project, to reflect the preferred style.
This should have the effect of reordering the generated reference
documentation and will also affect the ordering achieved when a POM is
written programma
Vincent Siveton schrieb:
I propose to improve [1] to add a code style for our pom files.
+1 for some convention (which is documented as such).
I see the following in this order.
Considering other POMs like parent POMs and Mojo, your proposal should
finally cover all POM elements (e.g. , ,
Hi,
I propose to improve [1] to add a code style for our pom files. As the
following tags are required: modelVersion, groupId, artifactId and
version (see [2]), I see the following in this order.
if required
if required
if required
if required
34 matches
Mail list logo
