Hi,
I'm in favor to not reuse the version. Like many others I'm often lost
between intermediate and final versions (but we can see it also as a maven
dev and advanced users privilege/constraint too - thus applying to very few
people).
We discussed about it many times and AFAIK we have 2
Clarification to 2): Sonatype uses the x.y.z-b version scheme (dash, not
underscore) which works with Maven's suggsted version syntax. This is also
the syntax I use for all customers I work with and that use staging.
The 'b' is the release build, which starts on '1' and is incremented for
each new
On 12 February 2014 08:35, Arnaud Héritier aherit...@gmail.com wrote:
Hi,
I'm in favor to not reuse the version. Like many others I'm often lost
between intermediate and final versions (but we can see it also as a maven
dev and advanced users privilege/constraint too - thus applying to
I prefer not to rehash what we all went painstakingly over a few months
back...
On Wed, Feb 12, 2014 at 8:06 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 12 February 2014 08:35, Arnaud Héritier aherit...@gmail.com wrote:
Hi,
I'm in favor to not reuse the version.
I lean towards keeping the current implementation as-is. Jococo maven
plugin relies on a bug in Maven core, there are at least two ways the
problem can be addressed by the plugin in a way compatible with 3.2.x
and earlier versions of Maven, and I think maintaining both the old
buggy code path and
Hi all,
Some of you already know me through MOJO and my posts here, and I would
like to try to get more involved in that Apache Maven tool I really like.
I am interested in the following areas:
enforcer, scm, release, and some others when needed...
If anyone knows any issues that I could take a
Woot! School roll is back up to 2!!!
Patches that apply cleanly using the backing SCM system are best... so if
the component is using GIT then patches that GIt can apply should be
recommended. If the component is using Subversion, then patches that `svn
patch` can apply are recommended (of course
Ok, that's fixed now.
On Feb 11, 2014, at 12:57 PM, jieryn jie...@gmail.com wrote:
Regression from Apache Maven 3.1.1, seen via:
bash$ mvn -e -Dmaven.test.skip=true -DskipTests=true -T 2.0C clean install
$@
[ERROR] Error executing Maven.
java.lang.NumberFormatException: For input string:
I'll gladly do some low-hanging JIRA maintenance like create the 3.2.1
version if someone can grant me that karma.
On Tue, Feb 11, 2014 at 6:42 PM, Tony Chemit che...@codelutin.com wrote:
On Wed, 12 Feb 2014 00:29:58 +
Stephen Connolly stephen.alan.conno...@gmail.com wrote:
Hurrah! At
Hi,
i have a question. The following situation. Pom file which uses the
following parent:
parent
groupIdorg.codehaus/groupId
artifactIdcodehaus-parent/artifactId
version4/version
/parent
prerequisites
maven${mavenVersion}/maven
/prerequisites
and
Hello Igor,
so you consider this a bug? While I agree with your xkcd (and may
easily work around the issue in the jacoco-maven-plugin) I do not see
any documentation on what artifactMap should hold, the String key is
not documented[0]. I see why you do not want to update the Major
version of
We are not changing the public api signature, and the keys were
undocumented previously, so this does not need a bump to 4.0 IMHO (even if
that would get modelVersion 5.0 aligned with the Maven version)
On Wednesday, 12 February 2014, Mirko Friedenhagen mfriedenha...@gmail.com
wrote:
Hello
I plan to restore the old/buggy behaviour and introduce new/correct api
later today.
--
Regards,
Igor
On 2/12/2014, 16:15, Mirko Friedenhagen wrote:
Hello Igor,
so you consider this a bug? While I agree with your xkcd (and may
easily work around the issue in the jacoco-maven-plugin) I do not
Hi,
The vote has passed with the following result:
+1 (binding): Jason, Olivier, Benson, Hervé
+1 (non binding): Igor
I will promote the artifacts to the central repo.
Can somebody with the awesome PMC powers copy the source release to the
Apache Distribution Area?
--
Regards,
Igor
I develop behind a proxy. Some of our servers sit behind that proxy as well,
including our Nexus Repository. I have configured my settings.xml to point to
our proxy but to ignore the hosts that are behind that proxy. If I use a
comma-delimited list in my nonProxyHosts, Maven seems to ignore
Hello,
I want to write a plugin which does dump/verify the hashes of all
dependencies and plugins used in the build. That way I can lock
dependencies in the source not only by version, but also by checksum.
I have currently the following
@Mojo(requiresDependencyCollection=TEST)
Am Thu, 13 Feb 2014 02:19:17 +0100
schrieb Bernd Eckenfels e...@zusammenkunft.net:
@Mojo(requiresDependencyCollection=TEST)
project.getArtifacts()
project.getPluginArtifacts()
Actual test source is here:
https://github.com/ecki/lockdep-maven-plugin
Gruss
Bernd
Can we start the process of converting everything to Git. I don't really see
any benefit in using Subversion any longer.
If so then we should just get together for a day and convert them and then get
infra to use what we converted to do the flip.
Jason (who would be happy to never execute svn
I like you more and more! :-)
On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl ja...@tesla.io wrote:
Can we start the process of converting everything to Git. I don't really
see any benefit in using Subversion any longer.
If so then we should just get together for a day and convert them and
Do you envisage one master git repo, or multiple repositories for each
moveable piece?
Full history retainment?
On 13 Feb 2014, at 16:37, Jason van Zyl wrote:
Can we start the process of converting everything to Git. I don't
really see any benefit in using Subversion any longer.
If so then
That's only because you haven't met me in person.
On Feb 12, 2014, at 10:38 PM, Fred Cooke fred.co...@gmail.com wrote:
I like you more and more! :-)
On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl ja...@tesla.io wrote:
Can we start the process of converting everything to Git. I don't
Probably a little more decompose like a repository for each plugin and shared
component. No reason all history can't be retained.
On Feb 12, 2014, at 11:03 PM, Mark Derricutt m...@talios.com wrote:
Do you envisage one master git repo, or multiple repositories for each
moveable piece?
Full
The SVN repo should probably be retained anyway, just in RO format, and
with a new URL that indicates it shouldn't be used. You can try to retain
all history, but it's never quite in the same form, really. Perhaps no one
cares, though?
+1 for decompose into individual repos.
Fred.
PS, perhaps
you mean you want to enter the committer school?
because Jira karma happens when going committer :)
Regards,
Hervé
Le mercredi 12 février 2014 13:14:16 Paul Benedict a écrit :
I'll gladly do some low-hanging JIRA maintenance like create the 3.2.1
version if someone can grant me that karma.
Hi,
See model builder algorithm [1]
If someone codes a version in build/plugin, that mean he wants to override
value injected from build/pluginManagement
consequence is that once overridden, pluginManagement doesn't apply any more
so: defining a version in build/plugin in a global parent pom
the only show stopper I know is for svn trunk which contains a lot of
components
so -1 for plugins, shared, skins, resources
but no problem for me for other release roots containing only one component
[1]
notice I don't see much gain: did we get much patches for components already
in git?
I already have privs to edit issues. But regarding your question, I don't
think commiter privilege is a procedural necessity to getting more karma,
is it? Furthermore, it's not even a JIRA instance under Apache's control so
I don't think it makes a difference in this case.
On Thu, Feb 13, 2014
I reported this Codehaus parent issue a long time ago (HAUS-2245 [1]).
Unfortunately the codehaus-parent seems to be in a unmaintained state.
/Anders
[1] http://jira.codehaus.org/i#browse/HAUS-2245
On Wed, Feb 12, 2014 at 9:07 PM, Karl Heinz Marbaise khmarba...@gmx.dewrote:
Hi,
i have a
It would be great if you could file a JIRA ticket so that the docs can be
fixed, see [1]!
Use the website JIRA project.
/Anders
[1] http://maven.apache.org/issue-tracking.html
On Thu, Feb 13, 2014 at 12:05 AM, Barnett, Ian ian.barn...@lmco.com wrote:
I develop behind a proxy. Some of our
Stuart,
We're seeing java.lang.LinkageError: loader constraint violation: loader
(instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
initiated loading for a different type with name
javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I
can't really see
true, this is not a technical issue: technically, it is controlled from
Xircles
http://xircles.codehaus.org/projects/maven/members
Le jeudi 13 février 2014 00:45:04 Paul Benedict a écrit :
I already have privs to edit issues. But regarding your question, I don't
think commiter privilege is a
Btw (apart from the fact that kind of question should better be asked on
users ML), it seems a bit weird to me at first sight you're actually having
to configure both a nexus server, and a proxy.
For instance, we exclusively use a nexus server to do the actual
proxying(+hosting) of anything that
32 matches
Mail list logo
