Excellent to hear that it will be materialising soon. It can make the
initial setup of a project a little tedious without it...
At any rate, Maven is an awesome step forward.
Cheers,
Dan
Ps. Apologies, that sensis footer is bloody annoying!
-Original Message-
From: Brett Porter [mailt
Dan,
What you are talking about is transitive dependencies and its been on the
TODO list for quite a while. I think it will start to materialise reasonably
soon.
I believe you can inspect the JAR manfiest Class-Path for a list of
dependant JARs?
- Brett
--
Brett Porter
Team Leader, Core Systems
Thanks for the responses guys...
I wouldn't say that I want to hide the dependencies, I just want an easy way
of figuring out what a library depends on. It would be nice if the
project.xml for a dependency was published along side the jar file (I notice
there are poms directories on ibiblio but
Alrighty, I found an existing issue on Jira regarding the use of
maven.compile.src.set with Javadoc:
http://jira.codehaus.org/browse/MPJAVADOC-5
So I've attached my 1.3 patch to that issue, and added a comment.
For what it's worth, I'd be happy to generate a patch against 1.4 or
1.5 (the r
Works for me... Might be environmental?
Is this on windows or unix?
IS CC running as the user you expect?
- Brett
> -Original Message-
> From: Nigel Magnay [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 19 May 2004 9:15 PM
> To: [EMAIL PROTECTED]
> Subject: Maven with CruiseControl
>
>
Yes I think that you can have some problems.
The stable branch is MAVEN-1_0-BRANCH.
Brett regularly merges changes from 1.0 branch to HEAD but depending when
you retrieved your 1.1 snapshot you can face up to problems with maven core.
I recommend to you to get maven 1.0 RC2 or a more recent snap
Hi Mark,
I've set up a project called "doc" which holds the site wide documentation
and use multiproject:site to include the documentation of every project.
I added these properties:
maven.multiproject.basedir=..
maven.multiproject.includes=*/*/project.xml
This is my directory layout:
/doc/
/co
I can't reproduce this error. Which version of maven and plugin do you have?
Do you have particular dependencies in your project.xml?
Emmanuel
- Original Message -
From: "Morris, Jason [IT]" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 19, 2004 6:40 PM
Subject: Missin
Hi Mark,
These slides are more than 1 year old. At that time, the multiproject
was still very new and I was not using it. If I had to do it today, I
would replace the reactor call by the multiproject call. However it does
not change anything. Simply replace:
For the second question, use the mu
> The other question is, how do I get the sub-projects, if they
> are built in this way, to share a generated site? I have only
> one project site, for the main project, but I'd like all the
> sub-projects to be listed in the main one, and have links to
> them as well.
I use beta 10, since it
I'm seeing a lot of that PDF, seems to be a popular presentation. Slide
21 seems to indicate that a custom goal in the project's maven.xml file
can use the reactor plugin to build all the sub-projects. However, I've
read that the reactor plugin is old, and multiproject is new (hence
preferred);
Sorry I think I saw this thread before but do not have a copy of the message.
I am running jcoverage plugin 1.0.5. It has a dependency on xpp3 1.1.2a. When I run I
get the exception:
jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/
jcoverage is licensed under the GNU Genera
Hi Arnaud
In the MAVEN-1_0-BRANCH... is there some code that was merged from the
main trunk?
Explanations. We're running here a maven 1.1 snapshot that was taken out
of CVS about a month ago. Do you think there may be issues with the
plugins if we take the latests running with this snapshot?
Er
> -Original Message-
> From: Ryan Sonnek [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 19, 2004 4:46 PM
> To: Maven Users List
> Subject: RE: Maven and Integration Test
>
>
> I was REALLY hoping to hear another solution to this problem.
> I'm running into the same thing, and would
Hi,
+) I have a couple of projects to build and run the JUNIT tests and in my EAR project
I automatically deploy to BEA WebLogic to run my webtest.
+) I currently reintegrate CLOVER to get the test coverage for the web regression tests
Cheers,
Siegfried Goeschl
-Original Message-
From:
I was REALLY hoping to hear another solution to this problem. I'm running into the
same thing, and would like to contain my project code (tests and all). I remember the
cactus plugin introducing the concept of src/test-cactus for it's integration test
code.
Two options would be to reuse the
> -Original Message-
> From: Amato Massimiliano (TLAB)
> [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 19, 2004 4:17 PM
> To: Maven Users List
> Subject: Maven and Integration Test
>
>
> Hello,
>
> I've a problem with my integration tests.
>
> In my system we have both unit and int
Hello,
I've a problem with my integration tests.
In my system we have both unit and integration test, the first type is perfectly
handled by maven that execute them, and generates a report and a clover coverage too.
Now I also have integration that are test to cover not the single class but a p
Yes, that's it, but I dont want to maintain 2
project.xml files. The version 1.0 would be tagged in
CVS as VERSION_1_0 and the second one as VERSION_2_0.
Now, if I have the 2.0 version locally and I want to
build the version 1.0. I think I can use the
scm:perform-release goal to perform this
autom
Ok That works ! Thanks to all - Great experience in this maven user list.
Christophe
-Original Message-
From: Kristopher Brown [mailto:[EMAIL PROTECTED]
Sent: Wed 5/19/2004 2:44 PM
To: Maven Users List
Cc:
Subject:RE: Xdoclet & Eclipse
Also, the maven.eclipse.classp
Also, the maven.eclipse.classpath.include is only used if there is a
test directory.
> -Original Message-
> From: Martin van den Bemt [mailto:[EMAIL PROTECTED]
> Sent: 19 May 2004 13:40
> To: Maven Users List
> Subject: RE: Xdoclet & Eclipse
>
> Ignore the warning, it is just a leftover
Ignore the warning, it is just a leftover from cactus integration in the
eclipse plugin (if you want the cactus plugin you need to download it
through the cactus project, but if you don't use cactus, you don't have
to do that).
Btw I assumed the target directory you described are actually java
sour
Hi Martin,
In the project.properties, I set
maven.eclipse.classpath.include=target/xdoclet/ejbdoclet
I'm using the rc2, I check the jelly script and it seems this variable is used. Maybe
it is something wrong in my maven config because it doesn't work.
I had some strange warnings. Do you have
Everything what can be done with ant can be done with maven.
In this case you have to by pass the maven plugin which generates jar and
write your own script in maven.xml file.
But this is something we discourage.
"Subprojects" option is much simpler and cleaner and recommended.
> -Original Me
Is there a way to set up a project that produces 2 jars without having to setup
sub projects?
Thanks,
David Robison
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Sorry for spamming. I've just seen that this issue has been posted
already.
I should research better before posting.
Dominik
On Wed, 2004-05-19 at 12:37, Dominik Dahlem wrote:
> Hi all,
>
> I'm generating some .java files form a .wsdl definition. These .java
> files are not kept in the src fold
Hi all,
I'm generating some .java files form a .wsdl definition. These .java
files are not kept in the src folder but rather in target/wsdl/src/.
As a result, the javadoc report complains about some files not being
present. I had a look at the plugin.jelly file from the
maven-javadoc-plugin and it
I'm getting some very odd behaviour running Maven from CC.
It seems that every other build, my ${user.home}/build.properties file
is not being
read, so my build fails, thus 50% of them seem to fail all the time.
Is there any reason this file would not get read?
--
I am not sure if I understad you
you will have (for version 1.0)
ABC
ABC
1.0
XXX
XXX
1.0
and (for version 2.0)
ABC
ABC
2.0
XXX
XXX
1.5
Just add
maven.eclipse.classpath.include=path to source, so in your case
target/xdoclet/ejbdoclet
To have it mapped within eclipse (you need to use rc2 for this btw)
Mvgr,
Martin
On Wed, 2004-05-19 at 11:34, LOMBART Christophe wrote:
> Hi All,
>
> I'm using Maven + eclipse + xdoclet.
>
> When
--- Maczka Michal <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Peter Bright
> [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, May 19, 2004 12:14 PM
> > To: 'Maven Users List'
> > Subject: RE: Xdoclet & Eclipse
> >
> >
> > Without some kind of defined (and widely used!
I don't really see how it is a solution. Perhaps I'm misunderstanding, but
if I have to edit _my_ maven.xml to call the src.set-affecting goal then it
seems to me that I'm doing the Eclipse plugin's work for it. If the Eclipse
plugin depends on the src.set containing any generated source then sur
> -Original Message-
> From: Peter Bright [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 19, 2004 12:14 PM
> To: 'Maven Users List'
> Subject: RE: Xdoclet & Eclipse
>
>
> Without some kind of defined (and widely used!) mechanism for
> source-modifying plugins to do their thing, it's n
The last paragraph of my email suggested just that (a pragmatic
solution):
So for the eclipse plugin to work in the short term:
1. it needs to utilise the maven.compile.src.set rather than
pom.build.sourceDirectory - this is a similar issue to what people have
been discussing re the javadoc plugin
I'd tend to agree - looks like this needs sorting throughout the plugin
code base then :) there are quite a few occurances of it. Its usually
the easiest way to get something working though, and is in keeping with
the way that this has been achieved to date (not that this justifies
it). I'd rathe
I'm working on a release 1.5.1 for the javadoc which will be supplied in
RC3.
If you have a patch, post it on Jira and it will be applied.
Arnaud
> -Message d'origine-
> De : Martin Skopp [mailto:[EMAIL PROTECTED]
> Envoyé : mercredi 19 mai 2004 09:18
> À : Maven Users List
> Objet : R
Without some kind of defined (and widely used!) mechanism for
source-modifying plugins to do their thing, it's not clear how they have any
real choice in the matter. Does there exist a better way that works right
now?
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
>
My view is that it's a bad practice (anti-pattern) for a plugin to use
preGoal/postGoal. Plugins should provide their own goals, possibly
wrapping existing goals.
-Vincent
> -Original Message-
> From: Kristopher Brown
[mailto:[EMAIL PROTECTED]
> Sent: 19 May 2004 12:06
> To: Maven User
You can't easily. It's a general problem with plugins that "affect" the
compile set, i.e. generation plugins such as antlr, castor etc, and
plugins that should "utilise" the compile set, e.g. java:compile,
javadoc, and ide plugins.
Personally I think it should all be addressed in the same way acr
--- LOMBART Christophe
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm using Maven + eclipse + xdoclet.
>
> When I run "maven eclipse", I want to add in the
> eclipse project source folder list the location of
> xdoclet generated files (/target/xdoclet/ejbdoclet).
>
> How I can do that ?
define p
Hi All,
I'm using Maven + eclipse + xdoclet.
When I run "maven eclipse", I want to add in the eclipse project source folder list
the location of xdoclet generated files (/target/xdoclet/ejbdoclet).
How I can do that ?
Kind regards,
Christophe
-
take a look at this architecture which could solve your problems :
http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf
Nicolas,
Mark Slater <[EMAIL PROTECTED]>
19/05/2004 11:23
Veuillez répondre à "Maven Users List"
Pour : [EMAIL PROTECTED]
cc :
Objet : Multip
I'm setting up my first Maven project, and trying to plan for the
future. The main project will be a collection of web applications
(separate ones), so I want to configure the project so that the main
project will build all the web apps (sub-projects), which in turn build
all of their EJBs, WAR
It appears to me that only the property ${basedir} can be resolved at
runtime. I don't know, whether that is a limitation to the ant
checkstyle ant target.
Because some of my projects have a different depth in the project layout
I can't rely on a one-for-all setting of the maven.checkstyle.properti
On Tue, 2004-05-18 at 07:33, Denis McLaughlin wrote:
> I had sent the email below asking for some information about modifying
> the maven javadoc plugin to properly support the maven.compile.src.set.
> I've generated a patch that seems to do the right thing: it's attached
> below. Comments quite
Hi Manuel,
maven has the notion of a or many repositories which house 3rd party
library jars and additionally jars for your project. Whenever you have a
new version of a component you would deploy the new version of the jar
into the repository and make it available to projects which depend on
them
46 matches
Mail list logo
