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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
