Nope!
What you could do is use a second module to run your integration tests and
have it depend on your packaged .ear
On Wed, Apr 2, 2008 at 10:45 AM, kristoffer [EMAIL PROTECTED]
wrote:
Ok, that makes sense i guess. Is there any way to modify which phases are
executed for specific projects?
I would add the dependencies with their scopes in the profiles.
You do know you can add dependencies in a profile?
AFAIK the scope tag does not support property expansion
On Thu, Apr 3, 2008 at 5:26 AM, Neimoidia [EMAIL PROTECTED] wrote:
Hi,
depending on which plateform i build my projects,
, because it cause me a lot of rewriting and
management works (around 170 projects under maven control).
What a pity scope does not support property expansion...
Regards.
2008/4/3, Stephen Connolly [EMAIL PROTECTED]:
I would add the dependencies with their scopes in the profiles.
You do
Hudson originally had this parallelisation for module builds but hit too
many problems (as the local repo is not designed to be accessed by multiple
threads concurrently) to leave it on by default. The option is still there
in the Advanced tab for the m2 project type.
It can give significantly
You need to install a local repository manager (e.g. nexus, archivia, etc)
and use it to mirror the repo without the pom.
You can then install the pom into your mirror.
AFAIK, opnce an artifact has been deployed without a pom, a pom cannot be
deployed for it without breaking builds, so if the
in Hudson you can use a freestyle project and specify the goals as
either
install -DskipTests | site
or
install | site -DskipTests
to do what your after
Sent from my iPod
On 16 Apr 2008, at 10:41, DCVer [EMAIL PROTECTED] wrote:
Hi,
I use CruiseControl for continous integration. There
The following is _not_ recommended.
Once you get more used to Maven you will realize that storing your binary
artifacts in SVN is a bad thing.
Fundamentally, they are a different creature from the source code.
What you should do is use a Maven repository manager (e.g. Nexus,
Artifactory, etc)
Maven repositories are designed to be write once, delete never... so you'd
have to script that yourself.
On Sat, Apr 19, 2008 at 11:31 AM, Lachlan Deck [EMAIL PROTECTED]
wrote:
Hi Stephen,
On 19/04/2008, at 6:10 PM, Stephen Connolly wrote:
The following is _not_ recommended.
Once you
Okay I think my next question would be: is there an easy maven command for
culling jars prior to a certain version from a repository?
e.g., say I've added versions 1, 2, 3 and 4 to the repository (such as
nightly builds or something)... is there a command that would easily remove
versions
On Tue, Apr 22, 2008 at 11:29 PM, I am Who i am [EMAIL PROTECTED] wrote:
Hi All,
How to remove maven related files like maven folder / pom.xml /
pom.properties files from the jar file being created, i have the following
in my pom, but still seeing the maven directory with pom /
One reason is that the pom.xml you develop with is no the one you want being
published.
For example, the pom.xml's we develop with contains a lot of internal
information that should not go outside the company (developer email
addresses, etc)
On Wed, Apr 23, 2008 at 8:44 PM, Wayne Fay [EMAIL
targetPath../config/targetPath
?
(Screaming hack of the month)
-Stephen
On Fri, Apr 25, 2008 at 2:56 PM, Borut Bolčina [EMAIL PROTECTED]
wrote:
Thanks, but this is not a solution. I want to filter some files in
src/main/config and put them in target/config (and NOT in
or use hudson as it's easier to setup and maintain
On Sat, May 24, 2008 at 1:32 PM, Arun Kumar [EMAIL PROTECTED] wrote:
why don't you automate the build process by cruise control and let the team
test that out?
On Thu, May 22, 2008 at 10:19 PM, Richard Chamberlain
[EMAIL PROTECTED] wrote:
You could have a second (dummy) module that depends on persistence, has all
it's dependencies, and then just add that as either scope provided or test
to the modules that you need
On Sat, May 24, 2008 at 4:11 PM, Fabien Coppens [EMAIL PROTECTED]
wrote:
Yes, but doesn't that mean adding the list
On Sun, May 25, 2008 at 5:28 PM, Giovanni Azua [EMAIL PROTECTED]
wrote:
Hi Simon,
Many thanks to you all for the replies!
The issue here is reliability and reproducibility of the builds.
1) Locking down versions is needed for reproducibility of the builds. If
maven decides silently for
One solution (the hack way) is to have antrun call the required build steps
for you, or even just fork the native code build tool
Another solution is to refactor your maven projects, take the unit tests out
of that module and put them into a third module.
A = java
B = jni
C = unit tests of java
We have a four uber project set of releases.
We use scripts to check out the latest released pom.xml for each from svn,
pull out the version number, step back if it's a -SNAPSHOT, update our
module's dependencies to this version, run maven with the integration tests
and check in the updated
There are default group Ids that are searched for plugins that are named
with the correct artifact Ids.
if the groupId is org.apache.maven.plugin and the artifactId is
maven-xyz-plugin and then xyz:goal will work
otherwise if the groupId is in the list of plugin group ids specified in
your
To my mind what you want to do is write an enforcer custom rule that
checks all the compile and runtime scoped dependencies against a
whitelist server...
I'd have a webserver that can e.g. take a query of the form
http://someurl/.../check?groupId=artifactId=_version=_classifier=
and the documentation
on the maven site does not give me the level of detail I am looking for in
order to be able to answer these question easily myself.
Ishaaq
2008/7/1 Stephen Connolly [EMAIL PROTECTED]:
To my mind what you want to do is write an enforcer custom rule that
checks all the compile
Option 1.
a shell script/batch file that just does
mvn plugin1:goalA plugin2:goalB plugin3:gaolC
This is especially handy if some of the goals should only be run on
the local directory while others need to run throughout the tree, the
script can invoke maven multiple times with and without
On Tue, Jul 1, 2008 at 9:07 AM, Andrei Ivanov [EMAIL PROTECTED] wrote:
On 7/1/08, Stephen Connolly [EMAIL PROTECTED] wrote:
Option 1.
a shell script/batch file that just does
mvn plugin1:goalA plugin2:goalB plugin3:gaolC
This is especially handy if some of the goals should only
Don't filter the sources... have a resource file and just get the
source code to read from the resource file.
On Wed, Jul 2, 2008 at 3:58 PM, Henri Gomez [EMAIL PROTECTED] wrote:
Hi to all,
I'm trying to filter some of my java source file before compile phase.
public interface DefaultProps {
FYI, You are not allowed to use ${blah} in the project/parent/version
or project/version tags.
There are bugs in Maven that mean it won't blow up in obvious ways if
you do use ${blah} in those two tags... but it will blow up when you
least expect it
You can use ${blah} in
What is wrong with having a static method that returns the string from
a parallel properties file...
something like
public class MyFoo {
private static String getProp(String name) {
Properties props = new Properties();
final String resourceName = MyFoo.class.getSimpleName() +
I would do a simple trickery...
disable the jar plugin and then use the build-helper plugin to attach
the jar file.
That way you can keep the jar packaging and have your jar!
On Wed, Jul 16, 2008 at 7:13 AM, Kristian Rink [EMAIL PROTECTED] wrote:
Folks;
I am searching for a smart way to deal
, Stephen Connolly
[EMAIL PROTECTED] wrote:
I would do a simple trickery...
disable the jar plugin and then use the build-helper plugin to attach
the jar file.
That way you can keep the jar packaging and have your jar!
On Wed, Jul 16, 2008 at 7:13 AM, Kristian Rink [EMAIL PROTECTED] wrote:
Folks
):
Stephen Connolly schrieb:
[...]
plugins
!-- fake out maven and install the binary artifact --
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
goals
goalrun/goal
) and attach the jar with build-helper.
On Wed, Jul 16, 2008 at 11:14 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
Yeah, I wish I knew how to disable the jar plugin... that's why I
posted the antrun solution!
On Wed, Jul 16, 2008 at 7:54 AM, Kristian Rink [EMAIL PROTECTED] wrote:
Stephen
why not use mvn scm:branch to move to a branch and then make the
release from the branch and finally remove the branch
On Thu, Jul 17, 2008 at 1:46 PM, Stephen Duncan Jr
[EMAIL PROTECTED] wrote:
I want to use the release plugin to make testing releases, without
interrupting ongoing development.
The structure your propose is not wrong... depending on your lifecycle, it
may not be optimal.
Remember that the remote maven repository that you deploy your binary
artifacts to will always have commons-1.0
The structure you're suggesting may be easier to work with when you
regularly need to go
Property expansion in ./project/version and /project/parent/version is not
supported by Maven 2 (and AFAIK will never be supported as it makes builds
irreproducible)
Yes, I know that it currently kinda works if you remember to define the
property in the command line or settings.xml... but it is
-download/
but I don't if it works for project/version ...
On Thu, Jul 24, 2008 at 10:47 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
Property expansion in ./project/version and /project/parent/version is
not
supported by Maven 2 (and AFAIK will never be supported as it makes
builds
You could use the resource plugin bound the the generate-sources phase and
then use the buildhelper plugin to add the generated sources to the list of
sources
On Fri, Jul 25, 2008 at 8:46 AM, Mark Derricutt [EMAIL PROTECTED] wrote:
Is there anyway to filter .java code to replace variable
Alternatively, you could use pom packaging if you do not intend for your
module to ever produce a jar
On Fri, Jul 25, 2008 at 8:48 AM, Manuel EVENO [EMAIL PROTECTED]
wrote:
Do you want to use an external program to create the jar ?
On this point, I'm joining Jeff
Otherwise, you can
However version ranges are borken with more than three digits!
i.e. Maven thinks 1.0.0.22 1.0.0.3
Which is no good...
I'd like to get a patch to the DefaultArtifactVersion.compareTo method so
that if not in the Maven version number format it compares . separated
portions as numbers if they are
The problem is version ranges
AFAIK, 3.4.3-SNAPSHOT is newer than 3.4.3-1... but check
http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#132
for the parsing and
If you use the release plugin it can generate the pom with fully locked down
versions from the time of release. Just use that pom from your SCM tag for
the release
On Wed, Jul 30, 2008 at 8:52 AM, Victor Tsoukanov [EMAIL PROTECTED] wrote:
We decided to use version ranges in module dependecies.
You might move the forth digit to the qualifier. But this is getting a bit
error-prone..I was thinging about 1.2.3-beta-1.1.
-Kuno
-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 29. Juli 2008 16:38
An: Maven Users List
Betreff: Re
When we need to use a newer version we just run mvn
versions:update-properties
On Wed, Jul 30, 2008 at 10:14 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2008 at 9:52 AM, Baeriswyl Kuno - Extern (IT-BA-MV)
[EMAIL PROTECTED] wrote:
Hello!
I vote for 4 digit versioning
The pluginManagement is a section where you define the default configuration
for any child projects if they decide to use the plugin, or if you invoke
the plugin directly (i.e. outside of the lifecycle)
The plugins section in the build defines the plugin configuration for that
project and can
Have you tried using maven's default project layout?
On Thu, Jul 31, 2008 at 7:47 AM, Jeff Mutonho [EMAIL PROTECTED] wrote:
I've also tried this :
webResources
resource
directorysrc/directory
excludes
exclude**/*.java/exclude
If it is not broken, don't fix it!
What you have sounds like it works for you and solves the problems you
have encountered.
If you have a working dependency management system that does not have any
problems... leave it working.
If, however, you have problems, then Maven could well have the
we've had tests that pass when run with cobertura and fail without. so
I always recommend running twice. additionally we've had tests that
pass normally, but fail with cobertura. in both cases the root cause
analysis was a bug in our code. run them twice and if either run fails
you likely
Wrap it up in a plugin and just use your plugin
On Mon, Aug 4, 2008 at 7:55 PM, vicki [EMAIL PROTECTED] wrote:
Hi,
is there an analog of ant's macrodef in maven? I have a lot of redundant
functionality in my maven's pom dedicated to different integration testing
setups. Now I keep different
All,
after the entirely underwhelming response to the versions-maven-plugin
(MOJO-1178) I have had some ideas for making it even better...
The ideas may result in completely refactoring the thing apart... bits to go
in the enforcer plugin... bits to go in the release plugin... bits to maybe
stay
to be included in 2.1
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2008 4:26 PM
To: [EMAIL PROTECTED]; Maven Users List; Maven Developers List
Subject: Idea for a maven plugin / request for input
All,
after the entirely underwhelming
have a look at http://mojo.codehaus.org/versions-maven-plugin. It does just
what you describe
On Mon, Aug 11, 2008 at 11:00 PM, sverhagen [EMAIL PROTECTED] wrote:
Hi, I'm trying to make a little plugin. I know how to get the reactor's
MavenProject's in there, and now I want to query these
-maven-plugin/src/main/java/org/codehaus/mojo/versions/UpdateParentMojo.java
On Tue, Aug 12, 2008 at 6:32 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
have a look at http://mojo.codehaus.org/versions-maven-plugin. It does
just what you describe
On Mon, Aug 11, 2008 at 11:00 PM, sverhagen
.
Stephen Connolly-2 wrote:
have a look at http://mojo.codehaus.org/versions-maven-plugin. It does
just
what you describe
--
View this message in context:
http://www.nabble.com/Available-versions-of-MavenProject%27s-parent-tp18934631p18941502.html
Sent from the Maven - Users mailing
More than just cool..
This makes the version-maven-plugin even more awesome (once I get the xml
rewriting implemented correctly)...
So with the -r option, all I do is:
1. check out all the modules I want into one directory
2. in that directory do
mvn -r versions:update-parent
unfortunately it does not seem to work for me in 2.0.9
Sent from my iPod
On 14 Aug 2008, at 21:04, Dan Fabulich [EMAIL PROTECTED] wrote:
Stephen Connolly wrote:
Frickin' cool
I agree. It would be nice if the invoker supported it, too:
DefaultInvocationRequest.java:87
public
add the child modules in profiles, that way you need only activate the
profile(s) you want to build
Sent from my iPod
On 14 Aug 2008, at 22:38, David Jencks [EMAIL PROTECTED] wrote:
On Aug 14, 2008, at 12:52 PM, Kathryn Huxtable wrote:
Sounds like a case for a parent pom and associated
Have all your projects with a common parent.
In the common parent add a pluginManagement section that defines the
defaults for the compiler plugin.
On Fri, Aug 15, 2008 at 1:51 PM, monika7 [EMAIL PROTECTED] wrote:
I know that current default for maven-compiler-plugin is java 1.3 and that
I
the development
profile and then configure the source and target elements as normal.
This profile could then be placed in the .m2/settings.xml file and would
cover all projects.
Trent
On 15/08/2008, Stephen Connolly [EMAIL PROTECTED] wrote:
Have all your projects with a common parent
for a development team that may work on
unrelated projects.
As far as I know, it is impossible to configure a plugin in
settings.xml.
Wouldn't be nice if the plugin were capable to pickup the compiler
version
based on e.g. JAVA_HOME variable?
Stephen Connolly-2 wrote:
Have all your projects
ok, here is one solution
the current behaviour is that if you have the parent in the reactor
(possibly only if it is also the parent folder) then maven ignores the
version.
what I would do is separate the parent from aggregation
so the project you use as parent does not have any child
iPod
On 24 Aug 2008, at 16:05, Stephen Connolly [EMAIL PROTECTED]
wrote:
ok, here is one solution
the current behaviour is that if you have the parent in the reactor
(possibly only if it is also the parent folder) then maven ignores
the version.
what I would do is separate the parent
you should be able to use the exec-maven-plugin attached to the
generate-test-sources phase in order to generate the junit tests from
your grammar. then use build-helper to attach the generated test
sources so they will be compiled in the test-compile phase and then
surefire will pick them
add src/main/java/ as a resource folder with an includes of **.java
Sent from my iPod
On 28 Aug 2008, at 17:47, raja72 [EMAIL PROTECTED] wrote:
-DperformRelease=true option creating source and javadoc as seperate
jar
files in the target directory.
I'm trying to compile an utility jar
there is an update-subprojects goal that does what you want
Sent from my iPod
On 28 Aug 2008, at 19:20, W. Dave Rathnow [EMAIL PROTECTED]
wrote:
We have a number of projects that are built from a single POM file
that
contains a much of modules. To build the project I just enter
mvn
must
change the scope of them?
Thank you in advance,
Simone
2008/8/28 Simone Tripodi [EMAIL PROTECTED]:
Hi Stephen,
thank you very much for your hints!
Best regards,
Simone
2008/8/28 Stephen Connolly [EMAIL PROTECTED]:
you should be able to use the exec-maven-plugin attached to the
generate-test
because the system scope is scheduled for removal post 2.0.x (or is
that post 2.1 now ;-) )
Sent from my iPod
On 29 Aug 2008, at 14:21, Martin Gainty [EMAIL PROTECTED] wrote:
Good Morning Asif
why sparingly?
thanks
Martin
__
Disclaimer and
URL is the web URL of a web based repository browser (if you have
one... if not, given you are using svn I recommend giving sventon a try)
connection is the maven scm URL for anonymous read only access and
might need to have the guest or anon username embedded in the URL
depending on the
Also the other thing is that if you use the release plugin it will handle
updating the scm urls for releases or branches
On Fri, Aug 29, 2008 at 4:36 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
URL is the web URL of a web based repository browser (if you have one... if
not, given you
, as Stephen Connolly suggested me, you
should be able adding generated sources using build-helper plugin in
generate-sources phase.
Hope this helps, best regards,
Simone
2008/8/29 Jan van Mansum [EMAIL PROTECTED]:
Hello group,
I am using the antlr3 maven plugin to generate a parser. I would
also like
separate your inheritance from your aggregation
On 9/2/08, Andrew Hughes [EMAIL PROTECTED] wrote:
Indeed this is the case.
I need to change the site so that it runs AFTER the deploy of the released
artifacts. Perhaps this should be 'normal' behaviour for maven... do you
want to fail a
that's because $${blah} is an escape for ${blah}
On Thu, Sep 4, 2008 at 9:41 AM, Henric Larsson [EMAIL PROTECTED]
wrote:
Hi,
I've just noticed that filtering doesn't work if the character prefixing
the property reference is a $ (dollar sign).
Example:
pom.xml:
properties
I should correct that. there are some escapes, and AFAIK the behaviour you
are seeing is by design.
not sure what the exact escapes are... but they should be detailed somewhere
On Thu, Sep 4, 2008 at 9:55 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
that's because $${blah} is an escape
On Thu, Sep 4, 2008 at 8:52 PM, Benjamin Smith-Mannschott
[EMAIL PROTECTED] wrote:
On Sep 4, 2008, at 18:47, Beyer,Nathan wrote:
Have you read this document -
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
It may help answer some of the questions.
The Mojo team is pleased to announce the release of the Versions Maven
Plugin, version 1.0-alpha-1.
This plugin allows:
* the querying for newer versions of plugins used in a project.
* the querying for newer versions of dependencies used in a project.
* updating a project's parent to the latest
versions, even if they are not in archiva yet?
regards,
Wim
2008/9/5 Stephen Connolly [EMAIL PROTECTED]
The Mojo team is pleased to announce the release of the Versions Maven
Plugin, version 1.0-alpha-1.
This plugin allows:
* the querying for newer versions of plugins used
On Fri, Sep 5, 2008 at 9:23 AM, [EMAIL PROTECTED] wrote:
On Friday 05 September 2008 [EMAIL PROTECTED] wrote:
I looked into the source code of the plugin. It uses
project.getActiveProfiles() and this method returns an empty list. But
I
have a profile defined in settings which is set
Look at the version rules
1.0.0-anything 1.0.0
if you set the version range as [1.0.0-,2.0.0) you should be OK
On Fri, Sep 5, 2008 at 9:39 AM, Caraivan Constantin [EMAIL PROTECTED]wrote:
Hello,
I'm new to this list, so here it goes :)
I'm using repo1.maven.org and I need
On Fri, Sep 5, 2008 at 9:45 AM, [EMAIL PROTECTED] wrote:
By the way, the settings.xml contains this:
profile
idjboss/id
activation
activeByDefault/
You need to change this to
activeByDefaulttrue/activeByDefault
as
assert true.equalsIgnoreCase() == false;
org.eclipse.core? Or can I send a modified pom.xml containing
this fix, and someone can upload it after a review? :)
Thank you,
___
Costin Caraivan
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: 5 septembrie 2008 13:24
To: Maven Users List
Subject: Re
Yep, basically 4 digit version numbers are not in the maven format!
On Fri, Sep 5, 2008 at 2:37 PM, Stephen Duncan Jr
[EMAIL PROTECTED]wrote:
On Fri, Sep 5, 2008 at 9:24 AM, Stephen Duncan Jr
[EMAIL PROTECTED]wrote:
My first attempt to run it gave this output that seems...incorrect:
, Stephen Connolly wrote:
On Thu, Sep 4, 2008 at 8:52 PM, Benjamin Smith-Mannschott:
Yes. That helped, as did
http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
Which actually comes out and says that qualifier and build nr are
mutually
exclusive. The syntax given
the difference is that version has to be evaluated prior to any
lifecycle phase or plugin execution
if you define a property in your pom it is available when constructing
the model
the buildnumber plugin is attached to the first phase and the property
is defined at that point, but by
have a look at build-helper-maven-plugin and the attach artifact goal
Sent from my iPod
On 5 Sep 2008, at 20:38, Scott Carter [EMAIL PROTECTED]
wrote:
We have an exec in one of our builds that produces an .exe file. Of
course
this is not the main packaging for the pom and is not
you're best bet is to use one of the repository search engines (e.g.
mvnrepository.com)
On Sat, Sep 6, 2008 at 9:00 AM, thomas2004 [EMAIL PROTECTED] wrote:
1) com.sun.jdmk:jmxtools:jar:1.2.1
2) com.sun.jmx:jmxri:jar:1.2.1
--
View this message in context:
Oh but sun jars typically have to be installed by hand due tolicensing
restrictions
On Sat, Sep 6, 2008 at 9:18 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
you're best bet is to use one of the repository search engines (e.g.
mvnrepository.com)
On Sat, Sep 6, 2008 at 9:00 AM, thomas2004
make up whatever you like
On Mon, Sep 8, 2008 at 2:27 PM, Saket Lakshminarayan Chiluveru
[EMAIL PROTECTED] wrote:
Hi,
I wish to temporarily build a maven project, with dependencies which are on
the FileSystem.
For which I can use the scope as 'system',
but what should be the group Id,
On Tue, Sep 9, 2008 at 11:25 PM, EJ Ciramella [EMAIL PROTECTED]wrote:
We're still battling away with how best to set up a shared set of libs
such that we can specify their version in a singular location and
stumbled across the typepom/type scopeimport/scope bit.
This would be great as we
I use properties to define the version and then use mvn
versions:update-properties to sync
Sent from my iPod
On 9 Sep 2008, at 23:25, EJ Ciramella [EMAIL PROTECTED]
wrote:
We're still battling away with how best to set up a shared set of libs
such that we can specify their version in a
The only way I know of at the moment is to use the dependency plugin to
unpack the test jar into the test-classes folder.
crappy I know!
-Stephen
On Wed, Sep 10, 2008 at 7:00 PM, Vogelsang, Jeff [EMAIL PROTECTED]wrote:
Hello,
We have a multi-module maven project where we want to run tests
cool
On Wed, Sep 10, 2008 at 9:04 PM, Dan Tran [EMAIL PROTECTED] wrote:
http://maven.apache.org/plugins/maven-surefire-plugin/faq.html#reuse-test-code
On Wed, Sep 10, 2008 at 12:58 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
The only way I know of at the moment is to use
Seems fine here too
On Thu, Sep 11, 2008 at 12:29 PM, Peter Horlock
[EMAIL PROTECTED] wrote:
RC17 runs smooth and nicely here too...
Thanks,
Peter
BTW, I think we're still getting the
project.getOriginalModel().getBuild().getPluginManagement() containing the
super-pom (but as that is 2.0.9 behaviour it's not a regression form
2.0.9... perhaps from previous versions but not from 2.0.9)
On Thu, Sep 11, 2008 at 12:50 PM, Stephen Connolly
On Thu, Sep 11, 2008 at 11:33 PM, EJ Ciramella [EMAIL PROTECTED]wrote:
So what's happening is, I'm activating a few profiles, yet the
properties that are missing are set in an activeByDefault profile. It
appears that the activeByDefault profile is either not activated or
ignored.
If I turn
another one? Maven shows it's active (see my snippet
above), but it's truly NOT putting the properties stored in it into
play.
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2008 6:39 PM
To: Maven Users List
Subject: Re: Property
You need to do
-P+base,+override
I think
On Fri, Sep 12, 2008 at 1:01 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
activation on the comandline will disable any defaults.
there is (added at some stage not sure what maven version) the ability to
add and remove with -P+otherProfile or -P
, it ignores the
activeByDefaults profiles.
If I do -P+profile1 -P+profile2, then it doesn't take profile2 at all
(so my plugin isn't activated).
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2008 8:02 PM
To: Maven Users List
Chirstian,
the problem is that the pom for the dependency that he wants to use declares
repositories to use for resolving its transitive dependencies.
He does not want to have that repository dragged in to his build.
Other than re-releasing the jar with a different version (e.g. releasing
On Fri, Sep 12, 2008 at 8:46 AM, Martin Höller [EMAIL PROTECTED] wrote:
On Friday 12 September 2008 Stephen Connolly wrote:
Chirstian,
the problem is that the pom for the dependency that he wants to use
declares repositories to use for resolving its transitive dependencies.
He does
You might want to either have a look at the versions-maven-plugin or
consider version ranges.
With the versions-maven-plugin you can update a property that locks down the
version you use automatically, which can be helpful in controlling when you
get an update in your dependency.
If you just
Each project can list _only the dependencies that it has_ while using the
import to ensure that only a single suite of dependency versions are used, I
would guess.
It's to separate inheritance from dependency management
On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan [EMAIL PROTECTED] wrote:
Noo!
try
testResources
testResource
directorysrc/test/resources/META-INF/directory
filteringtrue/filtering
/testResource
...
/testResources
On Tue, Sep 16, 2008 at 4:58 PM, Ryan de Laplante [EMAIL PROTECTED] wrote:
I found the solution:
resource
The update ppolicy for a remote repo will control how often maven looks for
updates versions being available also...
but the thing is this is only is Maven thinks it could use a newer
version...
so if your dependency is like
version1.0/version
then that's a no fixed version, but I'd suggest to
.
On Tue, Sep 16, 2008 at 7:21 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
The update ppolicy for a remote repo will control how often maven looks for
updates versions being available also...
but the thing is this is only is Maven thinks it could use a newer
version...
so if your
101 - 200 of 2415 matches
Mail list logo
