Use the multiproject with a directory structure like
/root
/common-prj1
/common-prj2
...
/common-all
common-prj* are maven.multiproject.type=jar
common-all is maven.multiproject.type=uberjar and have all the
common-prj* in his dependancies
On the root dir using
this is definitely the right approach, but be aware uberjar is a JAR
of JARs, not jar of all classes. if you want a JAR of all classes,
that's something you will need to aggregate yourself at this point.
Cheers,
Brett
On Thu, 18 Nov 2004 09:50:07 +0100,
[EMAIL PROTECTED]
[EMAIL PROTECTED]
I have filed a bug and found a workaround for the issue:
- Create the file build.properties in ${user.home} and set the property
maven.home.local to the desired directory. This should work for now.
Keep up the great work
Ralf
Brett Porter wrote:
please file a bug. It seems related to a
Excellent, thanks Dan, that works. Still making the mental step from ant
to maven when it comes to writing goals.
dan tran wrote:
try this, j:set var=maven.tomcat.precompile value=false/
-D
On Wed, 17 Nov 2004 10:43:30 +, Andrew Watters
[EMAIL PROTECTED] wrote:
Is it possible to set
Eric,
Any news regarding this? I have taken a look at the web, but I still
cannot find the 1.2.2 version of the plugin.
Best regards
Jose
Eric Pugh wrote:
I am in the process of updating the XDoclet repository at
http://xdoclet.sf.net/repository. I have everything bug the newest
I came across the same problem and ended up writing a custom goal (actually a
simple plugin because it's used in more then 1 project) which I run as preGoal
to the standard java:jar-resources. It simply unjars the dependencies having
the jar.bundle property set to true and then the jar goal
Hi,
I want to cvs commit with maven..
is there a goal for this job?
Thank you very much..
Erdem
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
What you want is the ant:cvs task. Example for checkout in the scm plugin
it is done with :
ant:cvs command=checkout ${maven.scm.cvs.checkout.flags}
quiet=${maven.scm.cvs.quiet}
cvsRsh=${maven.scm.cvs.rsh}
cvsRoot=${maven.scm.cvs.root}
dest=${maven.scm.checkout.dir}
Jose,
as you can see at
http://xdoclet.sourceforge.net/repository/xdoclet/plugins/, the plugin
is still not available in xdoclet repository. I guess Eric still has
some write access problems.
So you can't use for now the plugin:download goal (see a previous mail
for the exact command).
Anyway,
Hi,
I'm using Maven 1.0 and I want to switch to release 1.0.1 but I have some
problems with some dependencies.
We have a local repository, mirrored after ibiblio/maven and I get an error
when it tries to download some jars added by me in the repository manually.
All the jars that came from
you can put a list of remote repositories in the project.properties.
then every developer doesn't need to specify this. in my
project.properties I always set it to include maven-plugins.sf.net and
ibiblio since my project depends on plugins/jars from both of these
places.
-Original
Well, you still may have maven.repo.remote defined in your
project.properties shared among all your developers (we do so), and as
soon as you can specify a plugin as a dependency (maven 1.1?) there will
be no problem to keep all the developers' plugins updated.
Best regards
Jose
That looks like my first experience with the properties not being
inherited. Check if you have a sub project that rely on the
maven.repo.remote property being inherited from the parent
project.properties . In wich cases, ibilio repository will be used
instead of your repository, jars originnally
Hi,
Yes, it is a multi project and I checked the settings for the repository.
The settings are only in the multiproject project.xml(You can see it bellow)
and the sub-projects doesn't override this properties. As I told you with Maven
1.0 everything works, but with 1.0.1 is not working.
From my point of view, this is a configuration management issue that
should be addressed with a SCM tool.
On Thu, 18 Nov 2004 17:24:19 +0100, Jose Gonzalez Gomez
[EMAIL PROTECTED] wrote:
Well, you still may have maven.repo.remote defined in your
project.properties shared among all your
Thanks your help Brett. After switching to maven
1.0.1. The problem can be solved.
--- Brett Porter [EMAIL PROTECTED] wrote:
I'm not certain if multiproject:artifact existed in
Maven 1.0 RC2. You
should upgrade to the latest Maven release: releases
prior to 1.0 are
no longer supported.
I am working on getting the plugin up on XDoclet's repo (file system
permission problems).
If you could contribute a patch on the xdoclet-dev list with better
documentation, that would be great.
Also, what would help is if you can submit some fileupload requests for the
various XDoclet jars [1].
Property inheritance in 1.0.1 is partly broken, there have been some post on it
already and a Jira filed on this issue. The value does not get inherited, so
you use ibiblio repository without knowing it, and of course it does not
contain your custom jars.
On my work projects, we will wait
Thanks, I thought was something broken in this release. I think I will wait for
the next release(version 1.0 works ok).
-Original Message-
From: Jean-Marc Lavoie [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 18, 2004 12:27 PM
To: Maven Users List
Subject: RE: Problems downloading
You can find more in the archives, but essentially two dependencies
where only the types differ are not recognised as distinct. Fixed in
CVS HEAD for 1.1.
- Brett
On Thu, 18 Nov 2004 10:57:01 -0500, Alex Rodriguez
[EMAIL PROTECTED] wrote:
Hi,
I have a problem with the WAR Plugin. I'm
Hi,
I'd like to set a property based on some other command line property.
For instance if:
maven -Denv=qa java:compile
I'd like this:
build.properties
---
some.arbitrary.property=qaValue
but if
maven -Denv=prod java:compile
I'd like this:
build.properties
1) Can I embed jelly in my build.properties files?
The answer to the question you were trying to ask is yes, but to this
specific one, no. Jelly is the XML scripting, JEXL is the expression
language used in Jelly. You can use an expression in build.properties,
but not embed Jelly - just in case
Our project has several different types of tests: unit, functional,
performance, etc. Is there any concept of this in maven?
We have in the past kept them all in the same directory, and at other
times split them each into their own directory. We also prefix the class
name with an indicator
I think it'd be great for maven to have the concept of multiple test
directories like:
src/test for unit tests
src/int-test for integration tests
etc
but as it stands now, the most straightforward approach (ie: the least
hacking required) is to create a seperate sub-project for each group of
If I did in maven.xml:
ant:property file=version-info.properties/
And then in project.xml:
dependency
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
version${commons_logging_version}/version
/dependency
Should this work? The dependency
you will need to put it into project.properties for that to work.
However, there is a built in mechanism for that: jar overrides.
in project.properties:
maven.jar.override=on
maven.jar.commons-logging=1.0.4
Cheers,
Brett
On Thu, 18 Nov 2004 18:27:55 -0500, Barry Kaplan [EMAIL PROTECTED] wrote:
Brett Porter wrote:
you will need to put it into project.properties for that to work.
Seems that project.properties is not inherited to multiprojects (no?).
So this approach will not work for sharing version numbers across all
the subprojects.
--
barry kaplan
[EMAIL PROTECTED]
Brett Porter wrote:
It is inherited wherever project.xml is.
I copied the project.properties (container the version numbers) down to
the subproject. The ${..} were still not used in downloading the jar.
The attempt to download looked something like:
Attempting to download commons-logging-.jar.
I'd highly recommend using the JAR override mechanism I mentioned as
it is properly supported by more plugins.
Regards,
Brett
On Thu, 18 Nov 2004 22:37:57 -0500, Barry Kaplan [EMAIL PROTECTED] wrote:
Brett Porter wrote:
It is inherited wherever project.xml is.
I copied the
Brett Porter wrote:
It is inherited wherever project.xml is.
Yes, of course you are correct. What is not inherited is
'project.propeties' :-)
Thanks Brett! All works great now.
--
barry kaplan
[EMAIL PROTECTED]
-
To unsubscribe,
I'm not sure what you mean: project.properties IS inherited as long as
project.xml is.
What version of Maven are you using?
- Brett
On Thu, 18 Nov 2004 22:49:20 -0500, Barry Kaplan [EMAIL PROTECTED] wrote:
Brett Porter wrote:
It is inherited wherever project.xml is.
Yes, of course you are
Brett Porter wrote:
I'm not sure what you mean: project.properties IS inherited as long as
project.xml is.
'project.propeties' :-)
project.properties
I had a typo.
I just switched to the jar overrides, and its perfect. I'll let the
activemq and geronimo guys know. They were using entities for
32 matches
Mail list logo