Hi,
In the documentation of the release plugin it is written that you can specify
the versions via command line properties a la
-Dproject.rel.groupId:artifactId=1.2.3 and so on
(http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html )
According to
An: Maven Users List users@maven.apache.org
Betreff: Re: Command line versions for release:branch doesn\'t work as
described
On Fri, Sep 24, 2010 at 11:35 AM, Christoph Kutzinski ku...@gmx.de
wrote:
Should I reopen MRELEASE-387 or create a new bug?
Since it's partially working
Anyone?
Am 20.09.2010 14:40, schrieb Christoph Kutzinski:
Hi,
I've used a release.properties file with the release:prepare/perform goals
successfully. Now I want to know if I can use a similar file with the
release:branch goal, too.
The documentation only mentions passing the new versions
Hi,
I've used a release.properties file with the release:prepare/perform goals
successfully. Now I want to know if I can use a similar file with the
release:branch goal, too.
The documentation only mentions passing the new versions via command line
arguments, but I fear that the number of
If I remember correctly there has been a bug in the Javadoc plugin which caused
this behaviour (I experienced it during building releases).
Please try to increase the versions of all related plugins (e.g. site-plugin
and javadoc-plugin in your case) to the latest versions and try it again.
Please check that you've specified version 2.7 in the 'reporting' section of
your POM, too!
The versions specified in 'plugins' and 'pluginManagment' are not used for the
reporting plugins! (Yes, that's a very nasty behaviour of Maven and AFAIK
something is done against it in Maven 3)
Hi,
is not working is not very descriptive. What's the concrete error message?
Have you tried to specify the full path to the executable?
Have you looked at the exec-maven-plugin's project page for examples?
BTW: any reason why you're using version 1.1.1? Looks like 1.2 is the current
version.
Have you tried to specify the full path to the executable?
Have you looked at the exec-maven-plugin's project page for examples?
So, when it doesn't print any error, how do you determine that it 'doesn't
work'?
Doesn't it print any output?
Can you give the maven output?
You're giving pretty
So when is Maven 3 beta-2 now being released?
In the podcast you say, it's maybe released when the podcast is live.
Now it's live and where is beta-2? ;-)
Original-Nachricht
Datum: Thu, 5 Aug 2010 10:22:23 +1200
Von: Mark Derricutt m...@talios.com
An: Maven Users List
I second the advice about getting an own repository manager.
For completeness: Nexus isn't the only repo manager out there :-)
I know at least of Artifactory and Apache Archiva.
I've made good experience with both Nexus and Artifactory. Cannot say
anything about Archiva.
Am 31.07.2010 15:03,
Hi,
I thought this would be a no brainer, but suprisingly I found no answer to this
so far:
How can I find out the dependencies of an arbitrary artifact (say
org.sonatype.tycho:tycho-compiler-jdt)?
BTW:
yes, I know there's a workaround: Add it as a dependency to a POM and run mvn
.
08.07.2010 11:20, Christoph Kutzinski пишет:
Hi,
I thought this would be a no brainer, but suprisingly I found no answer
to this so far:
How can I find out the dependencies of an arbitrary artifact (say
org.sonatype.tycho:tycho-compiler-jdt)?
BTW:
yes, I know there's a workaround
I guess that Maven uses OpenSSH to open secure connections.
Putty Keys are not compatible with OpenSSH.
You have to export your Putty key in OpenSSH format and use that file
for Maven.
AFAIR you can do it in pageant or in puttygen.
Christoph
Am 29.05.2010 14:46, schrieb kelvin goodson:
In
Sounds like the Maven Assembly Plugin is exactly what you're looking for:
http://maven.apache.org/plugins/maven-assembly-plugin/
C. Benson Manica schrieb:
I have a code base, packaged as a jar, which is an interface to a Derby
database. Naturally the unit tests require firing up Derby and
Do you have classes with 'Test' in the name, but without any @Test
annotations - e.g..test helper classes
Surefire has the (stupid) habit of treating all classes with 'Test' in
the name as test classes.
See
http://jira.codehaus.org/browse/SUREFIRE-482
Christoph
Am 12.05.2010 20:23, schrieb
On a related note:
if it only takes compile-time dependencies into account, how does it come that
it warns about unused runtime dependencies in my project:
[WARNING] Unused declared dependencies found:
[WARNING]org.hibernate:hibernate-commons-annotations:jar:3.3.0.ga:runtime
Christoph
used at compile time.
To get rid of this warning, set ignoreNonCompile to true. I'm unclear
why this isn't the default.
Justin
On 5/4/10 12:41 PM, Christoph Kutzinski wrote:
On a related note:
if it only takes compile-time dependencies into account, how does it come that
it warns about unused
Am 04.05.2010 19:20, schrieb Justin Edelson:
Sorry, that wasn't clear... I should have written these goals only look
at the classes used at compile time.
To get rid of this warning, set ignoreNonCompile to true. I'm unclear
why this isn't the default.
Justin
On 5/4/10 12:41 PM, Christoph
Seems to be related to MECLIPSE-632
(http://www.mail-archive.com/users@maven.apache.org/msg106944.html)
I was rather surprised myself that is was removed without an explicit notice.
Seems like the m2eclipse guys will discontinue support for mvn
eclipse:m2eclipse in m2eclipse 1.0:
Hi,
I'm currently trying to use MavenEmbedder to parse a project configuration:
Configuration configuration = new DefaultConfiguration()
.setUserSettingsFile( MavenEmbedder.DEFAULT_USER_SETTINGS_FILE )
.setGlobalSettingsFile(
The obvious counter question is:
Why do you want to do this? Why not just fix the compile errors?
Eduardo M KALINOWSKI schrieb:
Is there a way to configure Maven to ignore source files that present
errors during compilation, and compile everything that is possible (that
is, has no error)?
of my head.
The alternative you mentioned - try to compile everything and just hope
at runtime that all currently needed functionality is working - sounds
inherently dangerous to me.
Eduardo M KALINOWSKI schrieb:
On Sex, 29 Jan 2010, Christoph Kutzinski wrote:
The obvious counter question
If your 2nd build (after deleting the corrupted jar) worked, then
obviously the jar on maven central is correct - where would the 2nd
build get otherwise the correct jar from?
Did you check directly on Maven central that the jar in question is the
'correct' one?
Which leaves us with 4
Hi,
I tried to enable the eclipse compiler plugin as described here:
http://maven.apache.org/plugins/maven-compiler-plugin/non-javac-compilers.html
I've got the problem that it won't compile my Java 6 sources. It says:
[INFO] [compiler:compile {execution: default-compile}]
[WARNING] Unknown
To answer my own question:
Unfortunately, it doesn't seem to be possible.
There's already an issue filed for this:
http://jira.codehaus.org/browse/PLXCOMP-148
Christoph Kutzinski schrieb:
Hi,
I tried to enable the eclipse compiler plugin as described here:
http://maven.apache.org/plugins/maven
25 matches
Mail list logo
