Benjamin,
Out of curiosity, what kind of performance difference you get with this
optimization vs without it?
Also, I think implementation should behave the same for pom and other
artifacts. I would not want to have to troubleshoot "strange" build
failures should pom get out of sync with the res
This sounds like an issue I raised on the user list today:
http://n2.nabble.com/Canonical-order-of-POM-elements-tc4219932.html#a4219932
I definitely want (but not mandated) a canonical POM ordering of elements.
Paul
On Sun, Dec 27, 2009 at 4:46 PM, Dennis Lundberg wrote:
> I'm -1 on this change
Brian Fox wrote:
I'm in favor of pulling this back or changing it to check for exact
timestamp and size.
I consider both the workflow outlined by Tamás and the need for
optimization valid points so instead of pulling it out completely I
opted to improve the existing logic. In the next alpha
I'm -1 on this change.
We, the Maven project, have our own POM code conventions. Other
project/companies may follow ours or they may have their own
conventions. At my day job we follow the order of the (current) POM
documentation. Reordering the documentation will confuse people that are
already u
+1
Benjamin Bentmann wrote:
> Hi,
>
> Besides updates to some plugin versions, this version of the parent POM
> contains the configuration to create ASF-compliant source distributions
> to finally share those bits with other ASF projects.
>
> Diff to previous version:
> http://svn.apache.org/vie
Is anyone planning on actually doing any bug fixing in the 2.x artifact
resolution code?
Lots of this stuff has been fixed in 3.x and I was just going to push any bugs
I saw in JIRA to 3.x and validate as fixed and for the ones that aren't
schedule them to be fixed.
I don't think at this poin
