Use clojure as test parameter, pass it to the test project with
-Dclojure-version=... from the test. You'll need to use junit4 and
Verifier, but I don't like invoker-plugin, so it's not an issue for me :-)
--
Regards,
Igor
On 2/9/2014, 23:29, Mark Derricutt wrote:
Yep,
My use-case should proba
It's extremely unhelpful to change existing tests.
You're quite a naive person if you think this is acceptable in any way
to change an existing, passing, IT in this way.
You may not like my language, but quite frankly, you're a fool to
change an existing, passing test. It's really dumb.
But, alas
Yep,
My use-case should probably be moved to user@ tho, but in this instance,
my IT tests pom.xml has a dependency on a clojure version, and I want to
assert the same test runs against 1.3, 1.4, 1.5, 1.6 etc. As I add more
and more IT tests, I don't really want to make 6 duplicates of every
One of us must have misread the question :-)
I thought Mark asked if it was possible to run the same
clojure-maven-plugin IT with multiple versions of clojure compiler.
Assuming the point of the IT is to test clojure-maven-plugin, I don't
see anything wrong with this request and believe junit4 pa
On 10 February 2014 14:50, jieryn wrote:
> Don't mess with existing tests. It's always wrong to do it. You're
> lazy and stupid if you do it.
Can you chill with the attitude.
Its not helpful, or appreciated.
-
To unsubscribe, e-
This is totally different than changing the version of xx-maven-plugin
used by the ITs. I appreciate testing with a new version of JUnit, or
whatever. That is totally different than changing the version of a
maven plugin used by an IT.
Don't mess with existing tests. It's always wrong to do it. Yo
I successfully used junit4 parametrized tests with Invoker to run plugin
ITs against multiple versions of Maven. Didn't really need to do
anything special, everything just worked. The only minor inconvenience
was, IIRC, I had to use system properties to tell Invoker maven home.
Should be trivial t
Just create a new IT. I can not stress how EASY this is for the
developer, and how much WIN is for the end user. Just create a new IT.
You want a new version of xx-m-p? Just create a new IP. SVN COPY is so
cheap and easy to type, just do it. What is stopping you??? Seriously.
Just create a new IT f
Is it feasible to somehow change the IT test infrastructure to run
against multiple versions? So that the best of both worlds is available
( at the expense of longer build times ).
Thats one thing I'd love to have with the invoker plugin ( not sure if
these IT tests use that ) for things like
+9000
Please don't change existing ITs. Create new ITs with the new versions.
This is relatively easy for you to do, and it means a huge amount for
downstream users.
Please. Once an IT is created and is passing, LEAVE IT ALONE.
If you want to update versions used in an IT, create a new IT.
PLE
On Feb 9, 2014, at 2:45 PM, Hervé BOUTEMY wrote:
> I ran the ITs before comitting, it was ok
> I'm running them once again on my machine, to check if something is now
> failing
>
> ITs need maintenance like every piece of code, old "expression" field of
> plugin-tools is now part of past and
Hi,
i would like to suggest to remove some branches in the following area:
https://svn.apache.org/repos/asf/maven/plugins/branches
I would like to delete the following branches, cause they are really old:
MASSEMBLY-128/
MASSEMBLY-14/
maven-assembly-plugin-2.0.x/
maven-assembly-plugin-2.2-beta
Hi Igor,
one other thing to mention is that the Java resources contained in
classes.jar need to be extracted into a folder and made available to aapt
when it is constructing an APK.
So ideas on how we should properly deal with this requirement using an
ArtrifactHandler or other mechanism?
Willia
I can now reproduce the failure: strange that it worked once...
I'm working on fixing this IT
Regards,
Hervé
Le dimanche 9 février 2014 20:45:29 Hervé BOUTEMY a écrit :
> I ran the ITs before comitting, it was ok
> I'm running them once again on my machine, to check if something is now
> failin
I ran the ITs before comitting, it was ok
I'm running them once again on my machine, to check if something is now
failing
ITs need maintenance like every piece of code, old "expression" field of
plugin-tools is now part of past and is every day harder to understand
Regards,
Hervé
Le dimanche
Hervé,
The following IT fails after your changes:
Tests run: 732, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 450.697 sec
<<< FAILURE!
testit0064(org.apache.maven.it.MavenIT0064MojoConfigViaSettersTest) Time
elapsed: 0.547 sec <<< FAILURE!
junit.framework.AssertionFailedError: Expected
Awesome. Thanks!
On Feb 9, 2014, at 8:29 AM, krosenv...@apache.org wrote:
> Updated Branches:
> refs/heads/master be19ddb6d -> 276c7636d
>
>
> Removed the remaining weave mode code
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/a
See http://markmail.org/message/3c26mocdioz35uvj for the reasons.
thanks,
Robert
Op Sun, 09 Feb 2014 03:25:16 +0100 schreef sebb :
On 6 February 2014 22:01, Hervé BOUTEMY wrote:
yes, the change was intentional, to fix
http://jira.codehaus.org/browse/MSCMPUB-10 you issued :)
Thanks for the
18 matches
Mail list logo
