PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
Answer is no. You don't have worry about B and C because once you have
Project A depends on B C. Once A got compiled it has all the compilation
files (B C) inside Project A jar. For project D you don't require Project
B and C.
just to address this advice directly: if project A's api
idea to do this?
Thanx for your help.
Cheers
Rolf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
:) sorry.
Catch-22 is when no possible action can have a good result...sort of
damned if you do, damned if you don't to use another cliche.
HTH,
john
On Thu, 2004-07-01 at 08:36, Martin Skopp wrote:
On Tue, 2004-06-29 at 23:27, John Casey wrote:
Catch-22 alleviated.
Could please someone
PROTECTED]
-Mensagem original-
De: John Casey [mailto:[EMAIL PROTECTED]
Enviada em: tera-feira, 29 de junho de 2004 19:46
Para: Maven Users List
Assunto: Re: RES: UnattainableGoalException: Unable to obtain goal
One last thing: multiproject:install should imply
-Forwarded Message-
From: John Casey [EMAIL PROTECTED]
To: MantissaHotmail [EMAIL PROTECTED]
Subject: Re: erro in junit plugin
Date: Thu, 01 Jul 2004 09:58:53 -0400
Add a section similar to this within your build/ tag in the
project.xml:
unitTest
excludes
exclude**/SomeClass.java
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
be
able to handle this gracefully.
On Mon, 28 Jun 2004 19:03:55 -0400, John Casey [EMAIL PROTECTED]
wrote:
On Mon, 2004-06-28 at 17:00, Roberto Castro wrote:
snip/
?xml version=1.0 encoding=iso-8859-1?
project xmlns:j=jelly:core xmlns:d=deploy
attainGoal name=jar:install
, John Casey [EMAIL PROTECTED]
wrote:
On Mon, 2004-06-28 at 17:00, Roberto Castro wrote:
snip/
?xml version=1.0 encoding=iso-8859-1?
project xmlns:j=jelly:core xmlns:d=deploy
attainGoal name=jar:install/
/project
try this:
?xml version=1.0 encoding=iso-8859
]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
[EMAIL PROTECTED]
OpenPGP key available from:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7977F79C
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL
: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
goal name=myGoal
attainGoal name=jar:install/
/goal
/project
You need to wrap the attainGoal/ tag in a goal/ tag...use the
default attribute of the project tag to indicate which is the default
goal to attain (as in the command line maven).
HTH,
-john
--
John Casey
[EMAIL PROTECTED
commands, e-mail: [EMAIL PROTECTED]
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL
while the build process is utilizing Maven.
Randy Bielby
x32258
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 8:58 PM
To: Maven Users List
Subject: Re: Jar help
First of all, sorry for the long email.
The right way
, log4j.jar instead of log4j-1.2.6.jar. I have tried
eliminating the version from the dependency but I get, log4j-.jar
instead.
Randy Bielby
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
! Photos: High-quality 4x6 digital prints for 25
http://photos.yahoo.com/ph/print_splash
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED
anyone still really
need to use entities like this. Ultimately I suppose it doesn't matter
how the POM comes together but I would like support to come from Maven
itself and not the use of entities which I would consider a workaround.
-Original Message-
From: John Casey [mailto
PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
- Diretoria de Solues em Billing
CPqD Telecom IT Solutions
Tel.: +55 19 3705-6957
www.cpqd.com.br
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John
: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e
Line.. 53
Column 72
C:\brown_dev\srcroot\bcs\ear\src\java not found.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open
will run through the
turbine-standard
checkstyle plugin...
Has anybody else use the two successfully?
regards
Rob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John
is a preGoal
for scm:parse-connection.
Sigh...
Sri
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I want builds to occur for
convenience.
Thanks,
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
like 'maven-ejb-goals.xml' via something akin to
core:import file=../../maven-ejb-goals.xml inherit=true/
in the top of the EJB-project maven.xml file.
Hope it helps...
-john
On Thu, 2004-03-18 at 15:16, Alex Karasulu wrote:
-Original Message-
From: John Casey [mailto:[EMAIL
only over one level (at
least in RC1)? I.e. if project B inherits from project A and a project C
inherits from project B (A - B - C) project C doesn't inherit groupID,
dependencies etc. from project A?
Best regards,
Joern
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
..
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, March 01, 2004 10:29 AM
To: [EMAIL PROTECTED]
Subject: RE: Depenceny version..
Hi,
-Original Message-
From: ext John Casey [mailto:[EMAIL PROTECTED
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
a dependency
without the version/ or jar/
tags?
Maybe I'm stupid, but I'd expect Maven to look for a jar
${dep.groupId}/jars/${dep.artifactId}.jar - but instead
it attempts to locate ${dep.groupId}/jars/${dep.artifactId}-.jar :-/
This is RC-1.0 by the way.
--
John Casey
[EMAIL PROTECTED
]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
Frederico Silva Guimares
Tel: (21) 9952-1717
ICQ: 127277403
Email: [EMAIL PROTECTED]
- Original Message -
From: John Casey [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED
, with bundling of properly marked dependencies...
Anyway, if this doesn't exist, I will probably write it. I just want to
check first.
-john
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
repo and maven runs like a champion now.
Thanks,
Alex
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
Off the top of your head, is there any issue I should associate this
with?
-j
On Mon, 2004-02-16 at 00:46, Brett Porter wrote:
That's a reasonable idea. Whack it in JIRA :)
Cheers,
Brett
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Monday, 16 February
Second one works where the first one didn't, because the maven tag
(maven:maven.../) doesn't inherit the environment/context setup in the
parent maven's execution.
-john
On Thu, 2004-02-12 at 08:31, Jol Wijngaarde [Us Media] wrote:
Hi,
Well, found out it works when I use the attainGoal
I know, this is getting farther and farther afield, but...
How does JBoss' javassist factor in wrt quality, syntax, etc? I'm just
getting started too, and was attracted to javassist because of its
integration into that platform...is it trash, the Holy Grail, or what?
-john
On Thu, 2004-02-12
Maven is a perfectly suited package management tool for its native
language: Java. If you find some project which _happens_to_be_ built in
a non-portable way, why not just throw up your own maven repository, and
add a piece to the default build.properties, placing your repository
first in the list
Just my 2-cents, but...
I can definitely say that if maven went to an OS-specific repository
with packages (rpm, etc.) I'd stop using it so fast it would make your
head spin.
The current state of packaging software on most projects today seems to
range from non-existent (Windows) to poor
snip
dependencies
-
dependency
groupId/
artifactId/
version/
url/
/dependency
/dependencies
/snip
This would do the trick...this is actually a section in which you're
supposed to list the dependencies upon which your
project...well...depends. As such, it should be a set of
and the /conf folder, but each are on CVS, where would I download
that from? I'm really confused now.
David
John Casey wrote:
snip
dependencies
-
dependency
groupId/
artifactId/
version/
url/
/dependency
/dependencies
/snip
This would do the trick
I was messing with this very problem the other day, and I _think_ the
varAttribute attribute allows the redefinition of the variable
attribute used to name the binding of the _tag_ in the jelly context. I
don't know if this tag would allow one to gain access to the underlying
bean (I suspect not),
As a matter of fact, I use the maven eclipse thing extensively. I
develop on a couple of different machines, and so before I check in
anything, I run that command and refresh the project in Eclipse. This
way, I know that I haven't changed anything in the .project or
.classpath inadvertently. I
On Sun, 2004-01-11 at 14:30, Brian Topping wrote:
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Subject: RE: Mutliple source directories in project.xml
It seems to me that the POM is the wrong place to put anything related
to artifacts created during maven
On Sun, 2004-01-11 at 20:41, John Casey wrote:
My only contention here is that maven and it's associated plugins and
whatnots be as encapsulated as possible. Now that I think of it, the
generated source directory wouldn't really belong to any one single
generation plugin, and therefore should
It seems to me that the POM is the wrong place to put anything related
to artifacts created during maven execution. I'd even go so far as to
say that the list of reports to be generated doesn't belong in here. To
me, it makes sense to have the POM describe the project itself, in pure
terms,
I don't know if this is conformant with what's correct but you might
check out the plugin.properties file in the artifact plugin (CVS:
maven-plugins/artifact/plugin.properties). It uses:
${plugin.dir}/plugin-resources/...
Cheers,
John
On Thu, 2004-01-08 at 11:31, Jason Horne wrote:
I need a
2cents
One easy way to get around this duality between single-source and
multiple source directories would be to stage out the java sources to
some temporary location under ${basedir}/target for subsequent
generation (back into that same directory) prior to java:compile
execution. Then, these
...
/contradiction
-john
On Thu, 2004-01-08 at 16:38, Jason van Zyl wrote:
On Thu, 2004-01-08 at 16:25, John Casey wrote:
2cents
One easy way to get around this duality between single-source and
multiple source directories would be to stage out the java sources to
some temporary location
I believe it would only compile sourceDirectory if
generatedSourceDirectory didn't exist...
As for the serial generator execution, the only real problem I see is
_what_ a particular generator would attach to as a preGoal. I mean, it
might depend upon whether xDoclet, javaCC, antlr, etc. was
Sorry, wrong list!!!
I'm cross-posting to the correct list...
-john
On Sun, 2003-12-14 at 14:59, John Casey wrote:
Here is my scenario: I'm trying to run multiproject:site on a collection
of mavenized projects in which some projects depend upon others. The
multiproject plugin sorts them
2cents
I'd emphatically agree with this sentiment. It seems like restricting
the build directory, or more insanely, the src directory is both
unnecessary and more importantly would be making inferior code quality
permissable.
I understand that maven strives for greatness in its build
I think properly placed touchstone builds in each plugin to check
assumptions would be a great idea...it's a mountain of work in its own
right, but it would also help to enumerate the different configuration
points that a plugin uses, and what they are used for...
On Fri, 2003-12-12 at 20:00,
fanning the flames
Also, while we're talking about ibiblio, wouldn't it be nice if we as
project managers could retain control over our own release cycles by
deploying to a public webserver controlled by us? Then, this dependency
analyzer-on-steriods could perform some kind of lookup to
Actually, the id/id syntax is deprecated. It was the old way of
doing things, and ultimately didn't provide the grouping mechanisms
desired by some of the more popular framework projects (read Jelly,
etc.). I think it will still work, but I don't know for how long, since
I've heard rumblings
Dunno if you've already gotten a response from this, but here goes:
For controlling which classes get compiled, try the sourceModification
section under the build specification in the project.xml. It allows
you to put in excludesexclude.../exclude/excludes and the same
thing for includes...I
501 - 565 of 565 matches
Mail list logo
