Hi,
Reply is below.
Brett Porter wrote:
Hi Kenney,
On 14/09/2007, at 9:15 PM, Kenney Westerhof wrote:
Hi,
I sent a mail a few days ago but it didn't make it to the list.
One very important feature would be the separation of build artifacts
(maven plugins and their dependencies)
. But a per reactor-build local workspace
as a default, when there are multiple projects in the reactor, as a default,
seems useful to me.
-- Kenney
Christian.
On 18-Sep-07, at 8:22 AM, Kenney Westerhof wrote:
Btw, we don't necessarily require the workspace repo to be present
in the ~/
Hi,
2. Workspaces should be something you have to set consciously, not
automatically created. This allows an integration-testing run (for
example) to run in isolation by using a different workspace id, and
clean up after itself when finished.
Agreed.
I think they should always be created,
Hi,
I sent a mail a few days ago but it didn't make it to the list.
One very important feature would be the separation of build artifacts
(maven plugins and their dependencies), and project artifacts.
The separation isn't clear in maven itself - repo's get mixed up,
wrong repo's consulted; build
Hi,
FYI I reported this as a Jira issue almost a year ago:
http://jira.codehaus.org/browse/MNG-2576
oh. I just saw your comment on the issue referring to this.
Yes, this is exactly the same issue ;)
-- Kenney
Brian E. Fox wrote:
http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode
en one again, that's asking for problems ;)
-- Kenney
Kenney Westerhof wrote:
I just committed a fix in the mojo sandbox for the shade plugin:
instead of removing the dependencies, it marks them provided.
That should make sure all versions line up if a transitive
dep brings in a 're
e|Test)(ClasspathElements|Dependencies), not in the artifact
resolver.
-- Kenney
Kenney Westerhof wrote:
Hi,
I added a sleep to the test and quickly copied /tmp/surefire*tmp
to examine them.
The following 2 entries in the surefire tmp file are the cause:
surefire45886tmp:classPathUrl.30=/home
Brian E. Fox wrote:
Sure. I've been thinking that the standard rules should come out of the
plugin into a separate module too. The thing I'd ultimately like to do
is be able to release the rules separate from the plugin since the
majority of changes occur to the rules.
The problem is that I'
7, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
there's a script to fix your own files in
/www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh
On 8/10/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Hi,
Since the scp wagon doesn't honor the server sett
Hi,
I added a sleep to the test and quickly copied /tmp/surefire*tmp
to examine them.
The following 2 entries in the surefire tmp file are the cause:
surefire45886tmp:classPathUrl.30=/home/forge/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-20/plexus-component-api-1.0-alpha-
Jason van Zyl wrote:
On 12 Aug 07, at 8:15 PM 12 Aug 07, Shane Isbell wrote:
Okay, I have updated the proposal with more info concerning the issues
with
.NET support. Currently, NMaven handles its own resolver and installation
based on information from its net-dependencies.xml file. This i
In Maven-project, there's org.apache.maven.project.ModelUtils, which has some
methods to merge plugin definitions.
Just curious, what do you need this for?
-- Kenney
Jason Dillon wrote:
Is there an _easy_ way to merge 2 plugin.xml's into one? Basically
taking the and bits from one plugin.xm
hi,
All mojo parameters are evaluated, nothing you can do about that.
But as with all 'templating' or evaluation solutions, you can escape characters
with special meanings in mojo parameters. Just replace $ with $$.
So use this, and you'll get 'println "${basedir}"' injected
as a mojo parameter
Hi,
Since the scp wagon doesn't honor the server settings,
could everybody please make sure they have their umask
set to 002 on minotaur (people.apache.org)?
I tried to deploy the invoker but the metadata file wasn't
group writable.
Here's a listing:
[/www/people.apache.org/repo/m2-snapshot-re
Hi committers,
Didn't we have a sandbox where ASF committers not on the maven team
can commit for this purpose?
Or is the XCode not something we want to support 'natively'?
I remember a discussion about moving non-vital plugins to mojo..
-- Kenney
Curt Arnold wrote:
On Aug 6, 2007, at 9:48 A
Hi,
You can use this project [1] to get the proper relationships.
Also you could take a look at the maven-project-info-reports-plugin [2],
which has a report that creates a dependency tree page.
Note however that using this code might result in different results
than are used by maven internally
Hi,
*Phew*, boy, did I open a can of worms when fixing this..
Short: it's fixed.
Long:
I broke it... Though I only broke an obscure hack.. This code shouldn't
have been committed though I understand why it's done.
(below jdcasey's comments, there's a long piece I wrote explaining what goes
o
at 12:55 PM, Kenney Westerhof wrote:
Daniel Kulp wrote:
Personally, I was thinking of just doing $$ -> $.
Yah, that's already in place for plugin parameters.
Thus, if you want ${pom.version} outputted, it would be $${pom.version}.
I think @@ also needs to be done.
Yup.
My origina
Max Bowsher wrote:
Kenney Westerhof wrote:
Patrick Schneider wrote:
For now, I'm a fan of disallowing snapshots when they are not
explicitly in
the boundary, as per the patch.
In my mind, the problem with a profile flag is that it's an
all-or-nothing
proposition. Any released
Patrick Schneider wrote:
For now, I'm a fan of disallowing snapshots when they are not explicitly in
the boundary, as per the patch.
In my mind, the problem with a profile flag is that it's an all-or-nothing
proposition. Any released artifacts with version ranges will also start to
pull in sn
in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2
Brian E. Fox wrote:
So I propose:
- if -DdownloadSources is specified, download sources and fallback to javadoc,
just as it is now
- if -DdownloadJavaDoc is specified, download javadoc (possibly fallback to
sources)
- if both are specified, download both.
And:
- don't make this a def
Jochen Kuhnle wrote:
Hi,
currently, Maven does not require declaration of properties used in
the pom, you just use them anywhere you like. Usually, if a property
is missing, bad things tend to happen because it is replaced with the
string "null". On a good day, resources from "translations-
Ok, if you really need both sources and javadoc then that should
be possible. I never heard of the shift-f2 but indeed it doesn't work here.
I either use the tooltip when I hover over an element and possibly f2 for focus,
or open the javadoc view which displays the javadoc as soon as I select any
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on trying to
get the string "${pom.version}" out
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
After battling with the braindead resource filtering once again for
the ump-teenth time, I've decided I need to do something about
it
You dissin' my code huh? :)
The main thing I&#x
Daniel Kulp wrote:
After battling with the braindead resource filtering once again for the
ump-teenth time, I've decided I need to do something about it
You dissin' my code huh? :)
The main thing I'd like to do is allow use of a better filter engine
(like velocity) that would provid
Hi,
I recently fixed 2 bugs in wagon-webdav rc1-snapshot
that make it possible to use it with maven 2.1 and 2.0.6/2.0.7.
One bug was the addition of the omitted and required plexus-utils
dependency - the code directly uses it. Since 2.0.6, plexus-utils
is shaded and plugins and extensions are re
Brian E. Fox wrote:
I recently had some trouble with the invoker getting a good maven.home
value from the mvn script. I came across this code in the eclipse tests
that seems to work pretty well. Is there any objection to moving this
code into the invoker in a fall back scenario? (ie if the exec
Final update: I checked out the tag cleanly, ran another build
and it passed fine.
The build took 9 mins 37 seconds. Ridiculous, but:
+1
Kenney Westerhof wrote:
Update:
It seems i was impatient, it took almost 3 minutes to run that single test.
After that it continued (on 2.0.7), but I got a
gin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562)
... 18 more
[INFO]
[INFO] Total time: 9 seconds
btw, tests take about 7 minutes whereas bootstrapping maven itself takes only 3
minutes.
my -1 stands, unless I'm the only one where this fails.
-- Kenney
Kenney W
I assume this is a vote to _release_ maven-eclipse-plugin 2.4.
-1 until the tests are fixed:
[INFO] [surefire:test]
[INFO] Surefire report directory:
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/surefire-reports
--
Try again, I just committed a fix.
-- Kenney
Brian E. Fox wrote:
I'm getting an error building the 2.0.7-snapshot invoker:
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.861
sec <<< FAILURE!
testBuildShouldFail(org.apache.maven.shared.invoker.DefaultInvokerTest)
Time elapse
Cabasson Denis wrote:
About this link, why couldn't we have a consistent behaviour for javadoc and
sources jar?
Why not adding a downloadJavadoc property, which, when set to true, would
download and attach the javadoc to the dependency.
I don't really see why javadoc should be a fallback if
Hi,
Just some thoughts here.
Maven can be customized with plugins. That is, the build currently is,
but what is the build? It seems dependency resolution is not part of it.
What about we extend the a bit, like this:
this way you can customize whatever components
That must be it then, though I don't know how you get a mojo
to be run, declared as an extension..
Btw, i hoped for the output to name the realm, but this apparently is
maven 2.0.x. if you could typecast the classloader to ClassRealm
and then call 'getId()' on it, I think you'll find it prints
Hi,
Timothy Reilly wrote:
I just read: http://docs.codehaus.org/display/MAVEN/Versioning Nice
document btw, well thought out.
Thanks ;)
I have a curiosity question...Under: Make version handling pluggable
Is this saying I would have to define version schemas using a
xsd/schema, or is it sa
Jochen Wiedmann wrote:
On 6/26/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
It must be being pulled in by a dep in the mojo. Is this something
that I can see?
Unfortunately not yet. Shall I file a Jira issue with some sample code?
Can you add
static { System.out.println( "XXX " + Contex
Mark Hobson wrote:
On 22/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 22 Jun 07, at 3:15 AM 22 Jun 07, Mark Hobson wrote:
> As mentioned above, this requires a change in the Maven installation
> rather than the POM. Obviously far from ideal, but I'm happy to live
> with this for the hug
lem because we discourage the usage of xml
entities in
our xml documents, but we have to continue to say it !!!
Arnaud
On 22/06/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:
Le vendredi 22 juin 2007, Kenney Westerhof a écrit :
Hi,
Hi,
indeed, it's a case of doing new XXXInputstream(
It seems to run the 2.0 version of the report plugin, which is quite old.
Try setting the version for surefire and the report plugin to 2.3 or later
snapshots.
The surefire artifacts on central haven't been updated since feb 28 2007,
so there haven't been any deployments lately.
Did you mean the
Hervé BOUTEMY wrote:
Le mercredi 20 juin 2007, Kenney Westerhof a écrit :
Also see
https://svn.apache.org/repos/asf/maven/surefire/trunk/maven-surefire-plugin
/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
line 494.
I tried to fix this a while back but it's a big
Jason van Zyl wrote:
[snip]
I will coalesce these three pages to mesh:
http://docs.codehaus.org/display/MAVEN/Taxonomy
http://docs.codehaus.org/display/MAVEN/Maven+Taxonomy
http://docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven+2.1
I you mean 'merging' by 'coalesce', please
Hi,
indeed, it's a case of doing new XXXInputstream( something, "encoding" ),
or a reader. Some work has been done on this, IIRC.
The problem is that you need to prescan the xml declaration, so you start
parsing until you get the first xml language element that is not a comment,
(an xml element
Mark Hobson wrote:
On 22/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
It's never been an alternative, but it was implemented as "newest
wins" in an early alpha.
Curse the person who switched to nearest! ;)
:)
It should be nearest though, with a fallback to newest if there are 2
nodes a
Also see
https://svn.apache.org/repos/asf/maven/surefire/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
line 494.
I tried to fix this a while back but it's a big mess and has a lot of unwanted
side effects.
Accessors shouldn't change a property,
John Casey wrote:
Sorry, I just realized that in my recent email shuffling, I lost one
of the
mailing lists. Which one does JIRA send notifications on? Is there a
list of
the maven MLs somewhere?
-j
[EMAIL PROTECTED]
-- Kenney
---
Jason van Zyl wrote:
On 18 Jun 07, at 10:43 PM 18 Jun 07, Ralph Goers wrote:
Jason van Zyl wrote:
And I'm still trying to get all the "getting prepared for 2.1"
before I start fleshing out any specs. But the artifact resolution
in 2.0.x is fundamentally wrong in not making a graph of the
Jason van Zyl wrote:
On 16 Jun 07, at 9:57 AM 16 Jun 07, Kenney Westerhof wrote:
So before I write something down that's more to the point than an
enumeration of
the flaws in the current implementation and the problems it gives us,
I'd like to
get concensus about the proper wa
Jason van Zyl wrote:
On 16 Jun 07, at 1:18 AM 16 Jun 07, Kenney Westerhof wrote:
Hi,
where's the spec for this?
I'm working on MNG-2651 and similar, and I'm a bit at a loss as how to
proceed.
What does the 'env.' prefix do? System props, env props, or project
Ralph Goers wrote:
Kenney Westerhof wrote:
This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct
dependencies of artifact X,
and for overrides of transitive dependencies on X,
unless there's also a direct dependency on X in which cas
Jörg Schaible wrote:
Kenney Westerhof wrote:
Hi,
Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is
what I found:
P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep
(I modified the attached
we need a new element, like 'transitiveDependencyManagement'.
This is something I hope we won't support in 2.1...
-- Kenney
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 16, 2007 7:06 AM
To: Maven Developers List
Subject: depM
Hi,
Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what
I found:
P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep
(I modified the attached project locally; rename my-app to my-dep and add
my-ap
Hi,
where's the spec for this?
I'm working on MNG-2651 and similar, and I'm a bit at a loss as how to proceed.
What does the 'env.' prefix do? System props, env props, or project props?
Should 'pom.' be the same as 'project.' or should one use the Model
and the other MavenProject?
If someone
Hi,
Just a quick question as to what this is for?
Is it used in 'help:dependencies'?
Is it/will it be used in maven-core?
I see the dependency plugin uses both dependency-tree and dependency-analyzer,
what's the relation?
If maven core eventually uses this, shouldn't it be moved into maven-co
Hi,
haven't tested this myself with 2.0.6, but take a look at
some other plugins that attach artifacts (javadoc, source,
assembly:attached etc) to see what the differences are.
Those plugins use the ProjectHelper to attach an artifact:
/**
* Used for attaching the artifact in the project
Mark Hobson wrote:
Hi,
I need an ArtifactFilter that supports wildcards and have patched
IncludesArtifactFilter accordingly, but then saw MNG-2621. I
implemented wildcards slightly stricter than allowing arbitrary
regular expressions - from the Javadoc:
The artifact pattern syntax is of the
Yup, I did the same change locally to test something.
Normally we don't want to depend on plexus snapshots since it imposes a
restriction
on the ability to release.
I think we should add the repo in the pom where we need a plexus snapshot, and
remove it
as soon as the dependency is released. P
Hi,
I'd like to ask that issues reported by PMC members and core developers
get less strict reviews.
When I find an issue that's rather complex I usually describe
how to reproduce it, but I lack the time to write sample projects, at
least when reporting. When i get around to it I reproduce the is
out, why is it
downloaded...
Anyway, I'm revoking my -1 and changing it to +1, though not being able to
deploy
p-c-d or p-u is a serious drawback. But i guess it doesn't matter as 2.0.6 has
the
same problems so it's not worse ;)
-- Kenney
- Brett
On 14/06/2007, at 2:32 AM, Kenney We
Brett Porter wrote:
I don't really grok why this set of problems have come up now, but I
don't agree with requiring a surefire plugin upgrade to upgrade to
2.0.7. We've been advocating pinning the version of plugins - that
would be nastiness to have to go and change them.
If 2.1.3 or 2.2 or 2
Jason van Zyl wrote:
tentative -1 for releasing as is:
I found a serious bug in maven 2.0.6 and 2.0.7 (2.0.5 works fine):
mvn clean deploy on plexus-utils fails (stacktrace and output below) due
to a NoClassDefFound
on IOUtil in plexus-utils.
I'm using released versions of wagon and the depl
that's due to maven-2.0.7.
It seems the test phase always requires the junit dependency (I don't call it
explicitly in the POM).
Cheers,
Frank
-Ursprüngliche Nachricht-
Von: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 13. Juni 2007 17:13
An: Maven Deve
gin
2.3
pertest
**/*TestSuite.java
**/TestSuite.java
Could not test SNAPSHOTs yet.
Regards
Mark Donszelmann
On Jun 13, 2007, at 6:18 AM, Kenney Westerhof wrote:
Hi,
can you find the surefire
Hi,
can you find the surefire plugin version you're using? I've fixed this
problem in the latest snapshots. Only the snapshots were faulty,
latest release should be fine.
If that one is broken too, can you try one of the latest snapshots (2.4-snapshot
or 2.3.1-snapshot), so we can determine whet
Mark Hobson wrote:
Hi Brett,
On 06/06/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
On 06/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> My recollection would be that some artifacts are filtered out but
> their transitive dependencies still needed to be taken into
> consideration for version c
Graham Leggett wrote:
On Fri, June 8, 2007 12:16 pm, David Moss wrote:
[INFO] Executing: svn --username username --password *
--non-interactive
copy --file C:\DOCUME~1\DAVID~1.MOS\LOCALS~1\T
emp\maven-scm-403689689.commit . svn://SERVER001/tags/product-4.0
The svn tag command failed.
C
I'm basically against this idea.
It can result in polluted jars very easily. Even if you
have 2 poms in the same dir, both specifying different source directories,
the files in target/ will overlap. the second executed pom will also contain
the files from the first executed pom.
Unless the tar
Arnaud HERITIER wrote:
Instead of writing specifications couldn't we write tests ? There's no/few
doubts with tests ;-)
(But we'll also write a complete documentation about that ...)
1) First we write the specification - what the software is supposed to do.
2) Then we write the design of the
oposal' simply means the stuff I wrote down - it's probably already
implemented,
or somebody else already thought of this solution - I don't mean to offend
anybody by calling it that).
Thanks,
Kenney
Jason van Zyl wrote:
On 7 Jun 07, at 8:01 AM 7 Jun 07, Kenney Wester
Zyl wrote:
For the love of god put this in the wiki. Use it as the start of the spec.
On 6 Jun 07, at 9:46 PM 6 Jun 07, Kenney Westerhof wrote:
I think it's a matter of scope and ordering.
Some brainstorming on specifying this out to the letter:
> > > | A -> B -> C ->
Ok, retested and it does work with 2.3. Guess it was me..
Anyway, you didn't set the version back, you set it to something specific -
before
it didn't specify any version so whatever was installed was used. I think it
used
2.2 here here or something, which is awful.
Anyway thanks, 2.3 is fi
I deployed all of it way before I committed this.
Continuum shouldn't complain ;)
Maybe we need to add some pluginrepo somewhere?
It'd be temporarily, i've got a feeling 2.3.1 will be released asap
as it contains major bugfixes. I just couldn't build it with 2.2.
-- Kenney
Vincent Siveton wrot
I think it's a matter of scope and ordering.
Some brainstorming on specifying this out to the letter:
> > > | A -> B -> C -> D
> > > |
> > > | C depends on D 1.0
> > > | B has D 2.0 in dependencyManagement, no D in dependencies
> > > |
B uses depMgt to say D has to be 2.0. What for?
1) for p
As stated in maven-dev, I think both 2.3.1 and 2.4 are pretty stable now.
The plugins and surefire booter should be up to date for 2.4,
and everything should be up to date for 2.3.1, in the snapshot repo.
I also changed the parent pom in 2.4 as it used ${project.version}, which
doesn't
work we
Hi,
I just found and fixed the bug after doing some testing of all possible config
values
for 2.3.1-snap and 2.4-snap.
fix is in svn, i redeployed surefirebooter for 2.4 and 2.3.1, so everything
should
be peachy now.
Turns out the '!' character was missing somewhere ;)
-- Kenney
Jason van
I'm on top of it, thanks for the pointer.
I think someone deployed the booter and not the plugin or vice versa.
just redeployed 2.3.1-snappy
-- Kenney
Jason van Zyl wrote:
Just making sure Kenney and Brett see this as I'm currently trying to
find a problem with surefire and 2.0.7 which is a sh
Hi,
Timothy Reilly wrote:
I'm not sure how to tell what happened, or if this is intended behavior /
keywords in plugin parameters?
Within my FoobarMojo I declare:
/**
* @parameter expression="${ws.config.root" default-value="${was.home}/config"
I agree, this is definitely an issue.
If you specify the same dep (a:a) twice in the same pom,
maven doesn't say anything, but takes the last one.
Brett Porter wrote:
Is this still an issue though? Maybe it should be left open for a
simpler fix.
- Brett
On 01/06/2007, at 2:19 PM, Jason van Zy
Hi,
That kind of metadata is not handled by packaging, but by the artifact manager.
What do you need this for?
If it's to automatically list all available archetypes, that would be great.
We should generalize that by having a special kind of metadata in special
groups,
like org/apache/mave
use
svn co https://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.4
and fix your smtp server ;)
Peter Anning wrote:
Spam detection software, running on the system "fire.homenet.neonics.com", has
identified this incoming email as possible spam. The original message
has been attach
I know that legacy repositories keep getting pinged on each
build, even if they're just updated. Is there also no
network traffic when legacy repo's are in the repo list?
-- Kenney
Brett Porter wrote:
On 19/03/2007, at 11:36 AM, Jason van Zyl wrote:
Yah, I saw the logging which is why I used
Hi,
well, this is indeed a problem..
I don't understand the second option: if you stop relocating
(not done by maven, but by the pom deployers, right?) when a version exists,
that means you can never relocate. It's no use to
relocate unreleased poms since they won't be present in the repository
Fabrizio Giustina wrote:
A big +1 for making it a default
I am also +1 on adding this to 2.0.6: for me this would just mean
removing tons of unneeded/workaround dependency from tons of poms. I
agree that, although consistent for some time, this behavior
introduces so much problems that should
Carlos Sanchez wrote:
On 3/16/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Carlos Sanchez wrote:
> now poms in the repo that have dependencyManagement sections will
> start to change the behavior of current builds and people with 2.0.5
> will get very different results t
Carlos Sanchez wrote:
it's not unpredictable at all, it is pretty clear that to force a
version in a project you need to add it in your pom and
dependencyManagement doesn't affect transitive dependencies, it's in
the documentation,
Where?
and even in the jira issue Brett says that it was
do
I think it won't break builds at all.
I think that people have lots of workarounds in their poms right now
to overcome this problem - specifying transitive dependencies directly,
which they don't directly use, but just to enforce that version being used. I've
done so myself quite a few times. Tho
plugin) is of use; it
temporarily
installs the plugin in the local repository, backing up what's there;
after the integration test, it restores the local repository.
Jason Dillon wrote:
On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:
Jason Dillon wrote:
How does a test repository help?
It's only available in snapshot version directories and contains a list of all
the snapshot versions there and names the latest version. So it's useful for
snapshots.
Ole Ersoy wrote:
Hi,
Just wondering if there is a purpose to having maven-metadata.xml in the
version directories (The direct
t doing this breaks other unit tests.
I'll make an IT test and see what happens just patching the contains
method.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 9:18 AM
To: Maven Developers List
Subject: Re: version range quest
do much to solve the real problem.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 8:46 AM
To: Maven Developers List
Subject: Re: version range question
Brian E. Fox wrote:
The problem is that I assumed "2.0.5" == "
to work on the WAR plugin but
I want more tests before changing anything.
MNG-2677
-- Kenney
Stéphane
On 3/14/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 3/14/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
> The problem is that it uses the Verifier to test.
> The Verif
VersionSpecificationException
{
VersionRange vr = null;
vr = VersionRange.createFromVersionSpec( requiredVersionRange );
return vr.containsVersion( actualVersion );
}
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent:
Wendy Smoak wrote:
On 3/14/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
The problem is that it uses the Verifier to test.
The Verifier uses the plugin from the local repo, not the current
project.
First, mvn clean install -Dmaven.test.skip=true, then mvn test and
it'll work
I'm sorry, what is the problem exactly?
createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).
createFromVersion: treats version as a single pinned version, so 2.0.5 is
treated
as [2.0.5].
So, createFromVersionSpec("2.0.5").containsVersion( new
DefaultArtif
Jason Dillon wrote:
How does a test repository help? I still need to configure in my
src/it/*/pom.xml the version of the plugin I'm testing.
The latest plugin will be used, which is usually what you're testing.
If the test repository does not contain other versions of the plugin,
the one you
rsion
so you'll know what to patch.
-- Kenney
-D
On 3/13/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Dan Tran wrote:
> http://maven.apache.org/developers/maven-eclipse-codestyle.xml
>
> seems to be out of date ( the throws, extend, etc do not split )
>
>
The problem is that it uses the Verifier to test.
The Verifier uses the plugin from the local repo, not the current project.
First, mvn clean install -Dmaven.test.skip=true, then mvn test and it'll work.
I noticed this today.. there's about 4 plugins that won't install cleanly
because of this.
-
I'l be there - it's in my country so how can I not go? :)
I'm looking forward to meeting you in person (and others ofcourse).
-- Kenney
Brett Porter wrote:
Hi,
Who here will be at ApacheCon in May? I know Jason is as he is speaking.
Anyone want to get together there?
I'm currently working o
1 - 100 of 535 matches
Mail list logo
