I believe it's the case see http://jira.codehaus.org/browse/MNG-5724
On 12 December 2014 at 07:16, Mark Nelson mark.x.nel...@oracle.com wrote:
Hi Jason,
Would that proposed release make the new http wagon 2.8 the default wagon?
Thanks,
Mark Nelson | Architect | 61.2.9491.1177
Platform
Hi,
i'm currently trying to upgrade maven-archetype from Modello 1.7 to
1.8.X but unfortunately i got failures which means the compile process
show that a class is not there:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on
FYI, EntityReplacementMap isn't a generated file - looking at plexus-utils
commit history it was added in 3.0.13:
https://github.com/sonatype/plexus-utils/commit/235796a03400472840626cf3195d05932158c71cz
Upgrading to at least that version of plexus-utils should solve the problem.
On 14 Dec 2014
Hi Stuart,
On 12/14/14 11:51 AM, Stuart McCulloch wrote:
FYI, EntityReplacementMap isn't a generated file - looking at
plexus-utils commit history it was added in 3.0.13:
https://github.com/sonatype/plexus-utils/commit/235796a03400472840626cf3195d05932158c71cz
Upgrading to at least that
Github user ananich commented on the pull request:
https://github.com/apache/maven/pull/31#issuecomment-66915459
Is there anything else I can do to help to merge this change?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
No worries, btw for those interested, here's the corresponding change in
the 1.8 modello code generator:
https://github.com/sonatype/modello/commit/2c55132415675f36919a1ff0dc6352e715da72f8
On 14 Dec 2014 12:40, Karl Heinz Marbaise khmarba...@gmx.de wrote:
Hi Stuart,
On 12/14/14 11:51 AM,
GitHub user todor opened a pull request:
https://github.com/apache/maven-plugins/pull/39
Support for purging output directory before unpacking. If a new version ...
...of the artifact is available and part of the contents is deleted in this
new version, it should be deleted after
Hi,
Time to release Maven 3.2.5!
Here is a link to Jira with 22 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=20819
Staging repo:
https://repository.apache.org/content/repositories/maven-1104/
The distributable binaries and sources for testing can be
+1
Analyzing release validity...
stagingUrl: https://repository.apache.org/content/repositories/maven-1104
groupId: org.apache.maven
artifactId: apache-maven
version: 3.2.5
Source ZIP url exists.
+1. As you guys have agreed not to reuse tags, we should apply the same
procedure as the Tomcat team does. When a staged build does not fit, it is
abandoned but tag remains. A not relased is added to the change log:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html see version 7.0.51.
In
There is no agreement to do this. The RM does what he finds most
practical in this case.
If you want to change the long-running policy in this project to
re-use failed votes I suggest you hold a proper vote and establish the
proceure in a real discussion, not just bog down release threads.
I'll post on another thread but I think we tentatively agreed (without voting)
to skip the failed versions and I forgot.
On Dec 14, 2014, at 2:30 PM, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:
There is no agreement to do this. The RM does what he finds most
practical in this
Everyone else still follows the established practice in maven, which
include re-use of failed releases and re-cutting tags. But the
established practice is also that the RM makes the ultimate decisions,
so I'm not arguing with 3.2.5. We have too many components to do these
discussions in-line with
+1 tested with some pat projects.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Sun, Dec 14, 2014 at 8:35 PM, Jason van Zyl ja...@takari.io wrote:
I'll post on another
documentation published: http://maven.apache.org/ref/3-LATEST/
just need svn cp once the release vote is over
Regards,
Hervé
Le dimanche 14 décembre 2014 13:00:12 Jason van Zyl a écrit :
Hi,
Time to release Maven 3.2.5!
Here is a link to Jira with 22 issues resolved:
Hi,
The discussion keeps resurfacing about how we deal with failed releases so I'll
summarize how I think it should ultimately be done as a starting point.
I'll go over the cases we've encountered thus far:
1) The user case prefers non-disjunct sets of releases, or from our PoV re-used
Thank /***, finally some movement in the right direction! :-D
Please also try to remember that EVERY single one of your users is a
*developer* and should comprehend that a version is an arbitrary label on a
piece of software to be used to uniquely identify it. If not, they should
be educated.
A further definition of a qualifier is that it applies to all artifacts in a
multi-module project (MMP). Unfortunately, at present, SNAPSHOTs are
fundamentally flawed in that all artifacts produced in an MMP do not get the
same timestamp. Each artifact gets its own which makes it impossible to
OK, well, classifiers works for me, then. It certainly seems like SNAPSHOTs
are not the go-forward plan, at least, without your fix.
Is it true that you can't use 4 part versions with Maven without confusing
some logic that is hard coded to look for 1.2.3 rather than
N.N+1.N+2N+M ? If not
On 15 Dec 2014, at 7:00, Jason van Zyl wrote:
Time to release Maven 3.2.5!
Just hit an interesting problem (that may not actually be a problem):
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
Deploying 1.0.6-SNAPSHOT to staging with version
I somehow think we need to decide if we want to change anything :)
Without changing anything there seem to be only so many approaches
out there, this is well known territory. While initially confusing,
jetty's 9.2.3.v20140905 approach is quite good. I assume they might
have had a failing
21 matches
Mail list logo
