Hi,
I get the error message in the title when I try to build my plugin.
According to my understanding the version 6.5-m92322-115 is included in the
version range [6.5,).
So what is the problem?
Thanks,
Shai
--
View this message in context:
You have to use the form
maven.xdoc.jsl=file:/${basedir}/xdocs/site.jsl
in project.properties, this will find the style sheet. However, I'm
still getting a build error after that, so before I dig into it: do you
really need the custom style sheet? The site builds fine with the
default jsl.
No, its not included. 6.5-something is regarded as before 6.5
Henry
On 3/30/08, carioca [EMAIL PROTECTED] wrote:
Hi,
I get the error message in the title when I try to build my plugin.
According to my understanding the version 6.5-m92322-115 is included in the
version range [6.5,).
So
I've started using and reading docs on Maven. While using and also while
referring docs, realized that, when maven is being used for the first time,
it downloads a lot of artifacts (jars, poms, etc).
I wanted to find out whether it is a must to have internet connection while
using maven?
For
;On Sun, Mar 30, 2008 at 02:46:11AM -0700, SKService wrote:
I've started using and reading docs on Maven. While using and also while
referring docs, realized that, when maven is being used for the first time,
it downloads a lot of artifacts (jars, poms, etc).
I wanted to find out whether
I want to do the exact same,
but it seems that the assembly plugin only accepts
manifest
addDefaultImplementationEntriestrue/addDefaultImplementationEntries
addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries
/manifest
which does not include the
Graham Leggett wrote:
Richard Chamberlain wrote:
I agree it's not ideal, but I'm open to suggestions as to how to
guarantee code from a particular project works in a java 1.4
environment?
Use Continuous Integration and a test suite.
That's what we do here, too. We use profiles that are
Hi all,
If some people were still interested in this subject, I found the codecommit
Brian was speaking about.
I also commented the bug I logged:
http://jira.codehaus.org/browse/MDEPLOY-74?focusedCommentId=129147#action_129147
The related improvement request (logged by Jason):
Hi all,
I've got some small questions about plugin development. More particularly about
passing parameters.
If you think this question should better be asked on the mvn-dev ML, please let
me know.
I saw how to do it for a mojo: according to a declaration like this:
/**
* @parameter
Dirk Olmes a écrit :
Graham Leggett wrote:
Richard Chamberlain wrote:
I agree it's not ideal, but I'm open to suggestions as to how to
guarantee code from a particular project works in a java 1.4
environment?
Use Continuous Integration and a test suite.
That's what we do here, too. We use
delbd wrote:
Dirk Olmes a écrit :
Graham Leggett wrote:
Richard Chamberlain wrote:
I agree it's not ideal, but I'm open to suggestions as to how to
guarantee code from a particular project works in a java 1.4
environment?
Use Continuous Integration and a test suite.
That's what we do
That appeared to resolve the problem.
From: Kedar Mhaswade [mailto:[EMAIL PROTECTED]
Sent: Sat 03/29/2008 3:35 PM
To: Maven Users List
Subject: Re: Fixing not finding maven-resources-plugin
Karr, David wrote:
I know very little about maven2. I'm trying to
Dirk Olmes a écrit :
delbd wrote:
Dirk Olmes a écrit :
Graham Leggett wrote:
Richard Chamberlain wrote:
I agree it's not ideal, but I'm open to suggestions as to how to
guarantee code from a particular project works in a java 1.4
environment?
Use Continuous Integration and a test suite.
On 3/30/08, delbd [EMAIL PROTECTED] wrote:
Yeah, that's what i thought. So we can consider that maven is missing
one important thing in dependency management: the jvm dependency. I
Check JIRA, and if its not already posted, file it. Perhaps it can be
incorporated in 2.1. Or, perhaps there's
check the toolchains proposal that is supposed to address this issue.
http://docs.codehaus.org/display/MAVEN/Toolchains
Milos Kleint
On Sun, Mar 30, 2008 at 7:58 PM, Wayne Fay [EMAIL PROTECTED] wrote:
On 3/30/08, delbd [EMAIL PROTECTED] wrote:
Yeah, that's what i thought. So we can consider
delbd wrote:
So, can we consider that a successfull build using a 1.4 JDK + source
and target in build are enough to guarantee that none of the
transitive dependencies require jre 5 or higher?
No, but a test suite can.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic
I am running Tomcat via Cargo for integration tests in Maven.
I keep getting 400 errors running an XFire test and says to refer to the
logs:
*![CDATA[org.codehaus.xfire.XFireRuntimeException: Could not
invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault:
Server
I had a closer look at this (bugged me because I remember working on a
fix for custom style sheets before m1.1... ;) )
One issue you might experience concerns the number of slashes in the
file url prefix. Depending on your OS, especially on different Windows
versions, you might need
On Sun, Mar 30, 2008 at 11:54 AM, Mick Knutson [EMAIL PROTECTED] wrote:
I am running Tomcat via Cargo for integration tests in Maven.
The Cargo project has its own mailing lists, you can find subscription
info here: http://cargo.codehaus.org/Mailing+Lists
--
Wendy
I think using a maven proxy like artifactory is a better option.
On Sun, Mar 30, 2008 at 11:59 AM, Eugeny N Dzhurinsky [EMAIL PROTECTED]
wrote:
;On Sun, Mar 30, 2008 at 02:46:11AM -0700, SKService wrote:
I've started using and reading docs on Maven. While using and also while
referring
I bet the dependency plugin and/or the enforcer could use ASM to inspect
all transitive dependencies to check the class version. (I'm just
guessing that ASM can do this).
-Original Message-
From: Graham Leggett [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 30, 2008 2:47 PM
To: Maven
Hi guys,
I'm attempting to build an RMI client/server JAR. It doesn't appear to
be making the client JAR correctly, because it doesn't include the
interfaces of my RMI objects. The server JAR turns out just fine, and
has all classes, which is exactly what I want.
I also want to know how
On Sun, Mar 30, 2008 at 9:24 PM, Eugeny N Dzhurinsky [EMAIL PROTECTED]
wrote:
On Sun, Mar 30, 2008 at 09:05:01PM +0200, Siarhei Dudzin wrote:
I think using a maven proxy like artifactory is a better option.
Artifactory is a pain, give a try to Apache Archiva
--
Eugene N Dzhurinsky
I'm on the Cargo Users list too, and the amount of traffic there vs
here is just nothing, a couple posts a week and many don't get
responded to. So I can understand why people post Cargo (in Maven)
questions here.
BUT I think it is a better idea long-term to push those questions to
the proper
What's the best way to remove, say, 10 or so old builds out of the
repository (a locally run/managed one)?
is there a mvn undeploy command?
On Sun, Mar 30, 2008 at 1:41 PM, EJ Ciramella [EMAIL PROTECTED] wrote:
What's the best way to remove, say, 10 or so old builds out of the
repository (a locally run/managed one)?
is there a mvn undeploy command?
Can you explain more about what you're looking for? Are these
snapshots or
We develop RCP applications and it is handy that the Eclipse jars are
now on central, can we get some of the RCP archives up as well?
As per the downloads at
http://archive.eclipse.org/eclipse/downloads/drops/R-3.2.2-200702121330/index.php
We need the eclipse-RCP-3.2.2 for our environment
you would need to run eclipse:to-maven with the 2.5 plugin and put
them somewhere to be synced
On Sun, Mar 30, 2008 at 4:13 PM, Barrie Treloar [EMAIL PROTECTED] wrote:
We develop RCP applications and it is handy that the Eclipse jars are
now on central, can we get some of the RCP archives up
I've been busy but before anyone publishes anything I'll try to
summarize the meeting we had at EclipseCon. In a nutshell the OSGi
experts around the table like Peter Krien's, and Jeff McAffer agreed
aligning the artifact id in Maven with the symbolic id is the way to
go in the future.
Milos Kleint wrote:
check the toolchains proposal that is supposed to address this issue.
http://docs.codehaus.org/display/MAVEN/Toolchains
The way the toolchain proposal chooses is somewhat doable with Maven
right now: define a set of VM specific properties in each developers'
settings.xml
On Mon, Mar 31, 2008 at 10:21 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
I've been busy but before anyone publishes anything I'll try to
summarize the meeting we had at EclipseCon. In a nutshell the OSGi
experts around the table like Peter Krien's, and Jeff McAffer agreed
aligning the
On Mon, 31 Mar 2008 14:57:43 Dirk Olmes wrote:
Still, I don't like the way how I have to manually distribute the path
to the current JDK into various config files.
you have to anyway it just happens you set an environment variable which is a
bit average at the best of times.
Packaged OS's do
Given this scm entry from a pom:
scm
connection
scm:cvs:ext:${cvs.user)@
freehost3270.org:/home/jstrayer/cvsroot:freehost3270
/connection
/scm
when I execute
mvn scm:update
It just hangs as if it's waiting for a password somewhere.
But when I execute
ssh
Michael McCallum wrote:
On Mon, 31 Mar 2008 14:57:43 Dirk Olmes wrote:
Still, I don't like the way how I have to manually distribute the path
to the current JDK into various config files.
you have to anyway it just happens you set an environment variable which is a
bit average at the best of
On Mon, Mar 31, 2008 at 12:31 PM, Jon Strayer [EMAIL PROTECTED] wrote:
Given this scm entry from a pom:
scm
connection
scm:cvs:ext:${cvs.user)@
freehost3270.org:/home/jstrayer/cvsroot:freehost3270
/connection
/scm
when I execute
mvn scm:update
It
On Mon, Mar 31, 2008 at 2:57 AM, Dirk Olmes [EMAIL PROTECTED] wrote:
Milos Kleint wrote:
check the toolchains proposal that is supposed to address this issue.
http://docs.codehaus.org/display/MAVEN/Toolchains
The way the toolchain proposal chooses is somewhat doable with Maven
right
36 matches
Mail list logo
