+1
--
Olivier
2009/5/8 Brian Fox bri...@infinity.nu:
There seems to be hardly any traffic on these lists and it tends to cause
questions to be unanswered. I think we should ditch these lists and just use
maven-dev for these areas. Any objections?
Brian Fox wrote:
I think we should ditch these lists and just use maven-dev for these areas.
+1
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Oki, once again, now on maven-dev ;)
After talking to a few people on IRC, it seems that the error handling in
maven-scm could be made
a bit more easier.
Currently there are 2 ways for a scm provider to 'report' that there has been
something wrong in
executing a SCM command (e..g. 'svn up')
Hi!
In maven-scm, I saw a lot of
if (blablubParameter == null
{
throw new NullPointerException(blablubParameter must not be null!)
}
Shouldn't we use commons.lang.Validate
Validate.notNull(blablubParameter, blablubParameter must not be null!);
or at least throw InvalidArgumentExceptions
Mark Struberg wrote:
Shouldn't we use commons.lang.Validate
Validate.notNull(blablubParameter, blablubParameter must not be null!);
or at least throw InvalidArgumentExceptions instead of NPE?
+1, to throw IAE instead of NPEs. The former one gives a clearer
indication which party (client vs
-0, to pull in another dependency just for something that is trivial to
code by hand.
We could also add the small validation class I already wrote for JGit [1].
We could easily put them into plexus-utils which we already use excessively.
Licensed under ASL for sure.
LieGrue,
strub
[1]
doxia ml too ?
--
Olivier
2009/5/9 Olivier Lamy ol...@apache.org:
+1
--
Olivier
2009/5/8 Brian Fox bri...@infinity.nu:
There seems to be hardly any traffic on these lists and it tends to cause
questions to be unanswered. I think we should ditch these lists and just use
maven-dev for
On 9-May-09, at 6:10 AM, Mark Struberg wrote:
Hi!
In maven-scm, I saw a lot of
if (blablubParameter == null
{
throw new NullPointerException(blablubParameter must not be null!)
}
Shouldn't we use commons.lang.Validate
-1
Validate.notNull(blablubParameter, blablubParameter must not be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I found that there is a little list of incompatibilities form m2.1 at:
http://maven.apache.org/release-notes.html
However there are a lot more.
E.g. with maven 2.0.x you could have a module included in your
toplevel pom that you also add
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.
Additionally the complete solution is quite simple
and seems to be quite common sense:
1. Allow to omitt versions in parent as well
These sound more like bugs to me
- Original Message -
From: Joerg Hohwiller jo...@j-hohwiller.de
To: Maven Developers List dev@maven.apache.org
Sent: Saturday, May 9, 2009 4:48:40 PM GMT -05:00 US/Canada Eastern
Subject: maven 2.1 incompatibility list
-BEGIN PGP SIGNED
On Sat, May 9, 2009 at 4:48 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I found that there is a little list of incompatibilities form m2.1 at:
http://maven.apache.org/release-notes.html
However there are a lot more.
E.g. with
On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.
Are you using the release plugin?
Additionally
13 matches
Mail list logo
