what is the current state of trunk?
Hi, Can someone clear up what the current state of trunk, particularly in regard to the MNG-2766 branch where all the work is happening at the moment? Is everything from trunk in there now, or are there two streams of dev? I thought I had seen that it was about to be merged but activity has picked up again. Where does plans for 3.0-beta-3 fit into all this? Thanks, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller wrote: > -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 the complete solution is quite simple > and seems to be quite common sense: > > 1. Allow to omitt versions in as well > as in that is available in the reactor. > Omitting the parent is complicated. Ralph started an implementation but we found some issues with it at ApacheCon. I don't think it's gotten beyond that yet. You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. > > 2. Ensure that omitted version as well as variables > in and are replaced > when a pom is installed in the repository. > Agree with this. > > However I totally lost where we are and what is going on. > > http://jira.codehaus.org/browse/MNG-624 > http://jira.codehaus.org/browse/MNG-2971 > http://jira.codehaus.org/browse/MNG-3267 > http://jira.codehaus.org/browse/MNG-2971 > > I could not find the one to omitt version in . > Can anybody remember. Or do I have to open a new one. > > I can not really tell how hard it is to make this > work, but be sure that we can make millions of users > happy with this! > > Thanks > Jörg > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoF+UIACgkQmPuec2Dcv//gDACfRvtIJ+CrTatgMZiynQ/2/f7+ > 7DQAni6uH3UkGSU0WNFKuUCz5OsyrGy3 > =Jn88 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: maven 2.1 incompatibility list
On Sat, May 9, 2009 at 4:48 PM, Joerg Hohwiller wrote: > -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 as dependency to some plugin such > as checkstyle or findbugs. In maven 2.1 you have to remove the > module declaration or you will get a cyclic dependency error > (that is hard to unserstand since it says that some module depends > on itself - which is right but you can not see this in its pom > directly because it is inherited). > I think that's a bug. Having a plugin in the same reactor is bad, but building something and then passing it to a plugin is valid imo. I've had to do that to work around not being able to build and use a plugin in the same build. > > Additionally with maven 2.0.x you could have the same build > plugin twice, such as a javadoc-plugin configured to aggregate > and a javadoc-plugin configuered per module. Maven 2.1 accepts > the pom but seems to ignore the second, duplicate plugin. > Duplicate entries are bad, you should instead configure multiple executions. Something should notify you though that it's skipping the second plugin declaration. > > Regards > Jörg > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoF7CgACgkQmPuec2Dcv/95EgCePZW6Cd/dC8R9adyPtK6o89Xf > FRUAnj9Q6GgeeIi1LVBe1kq1Kx8BrE6w > =WgUV > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: maven 2.1 incompatibility list
These sound more like bugs to me - Original Message - From: "Joerg Hohwiller" To: "Maven Developers List" Sent: Saturday, May 9, 2009 4:48:40 PM GMT -05:00 US/Canada Eastern Subject: maven 2.1 incompatibility list -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 as dependency to some plugin such as checkstyle or findbugs. In maven 2.1 you have to remove the module declaration or you will get a cyclic dependency error (that is hard to unserstand since it says that some module depends on itself - which is right but you can not see this in its pom directly because it is inherited). Additionally with maven 2.0.x you could have the same build plugin twice, such as a javadoc-plugin configured to aggregate and a javadoc-plugin configuered per module. Maven 2.1 accepts the pom but seems to ignore the second, duplicate plugin. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoF7CgACgkQmPuec2Dcv/95EgCePZW6Cd/dC8R9adyPtK6o89Xf FRUAnj9Q6GgeeIi1LVBe1kq1Kx8BrE6w =WgUV -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Progress on support for large projects
-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 as well as in that is available in the reactor. 2. Ensure that omitted version as well as variables in and are replaced when a pom is installed in the repository. However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in . Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoF+UIACgkQmPuec2Dcv//gDACfRvtIJ+CrTatgMZiynQ/2/f7+ 7DQAni6uH3UkGSU0WNFKuUCz5OsyrGy3 =Jn88 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven 2.1 incompatibility list
-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 as dependency to some plugin such as checkstyle or findbugs. In maven 2.1 you have to remove the module declaration or you will get a cyclic dependency error (that is hard to unserstand since it says that some module depends on itself - which is right but you can not see this in its pom directly because it is inherited). Additionally with maven 2.0.x you could have the same build plugin twice, such as a javadoc-plugin configured to aggregate and a javadoc-plugin configuered per module. Maven 2.1 accepts the pom but seems to ignore the second, duplicate plugin. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoF7CgACgkQmPuec2Dcv/95EgCePZW6Cd/dC8R9adyPtK6o89Xf FRUAnj9Q6GgeeIi1LVBe1kq1Kx8BrE6w =WgUV -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-scm] Argument validation in maven-scm
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
null!");
or at least throw InvalidArgumentExceptions instead of NPE?
LieGrue,
strub
“Multiple exclamation marks are a sure sign of a diseased mind!”
(Sir Terry Pratchett)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
--
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: get rid of scm and wagon sublists
doxia ml too ? -- Olivier 2009/5/9 Olivier Lamy : > +1 > -- > Olivier > > 2009/5/8 Brian Fox : >> 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? >> > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-scm] Argument validation in maven-scm
> -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] http://github.com/sonatype/JGit/blob/ab251fae2b9f22806eecf58656db357275e1a8b2/org.spearce.jgit/src/org/spearce/jgit/util/Validate.java --- Benjamin Bentmann schrieb: > 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 provider) misbehaved. > > -0, to pull in another dependency just for something that is trivial to > code by hand. > > > Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-scm] Argument validation in maven-scm
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 provider) misbehaved. -0, to pull in another dependency just for something that is trivial to code by hand. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[maven-scm] Argument validation in maven-scm
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 instead of NPE?
LieGrue,
strub
Multiple exclamation marks are a sure sign of a diseased mind!
(Sir Terry Pratchett)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
FWD: how to treat Exceptions in ScmResults?
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')
1.) scm-providers may trow a ScmException
2.) scm-providers may return ScmResult(..., success=false)
After looking over the sources it seems to me that in a higher layer if
succeed==false an
ScmException is thrown anyway.
So why do we still need the success flag in the ScmResult?
Is there a need to distinct between 'technical' or 'hard' errors which should
result in a
ScmException on the one hand and 'processing failures' which should result in a
ScmResult on the
other hand?
Imho we could safely drop the success flag in ScmResult and handle all failures
via ScmExceptions.
We could maybe introduce a CliScmException or add a CLI specific constructor to
ScmException for
easier integration into CLI based scm providers like maven-scm-provider-svnexe.
LieGrue,
strub
--- Mark Struberg schrieb:
> Datum: Wed, 6 May 2009 21:01:26 + (GMT)
> Von: Mark Struberg
> Betreff: how to treat Exceptions in ScmResults?
> An: scm-...@maven.apache.org
>
>
> Hi!
>
> I'm currently implementing the maven-scm-providers-jgit and like to know how
> others did handle
> e.g. CheckOutScmResult for Java implemented SCM connectors. Especially what
> to do if an
> Exception occurred? How do you transport this nested Exception? fill only
> e.getMessage() or is
> there a trick I miss?
>
> Currently I'm doing
> > return new CheckOutScmResult("", "JGit clone failed.", e.getMessage(),
> > false );
> but this doesn't feel ok somehow.
>
> txs and LieGrue,
> strub
>
>
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: get rid of scm and wagon sublists
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
Re: get rid of scm and wagon sublists
+1 -- Olivier 2009/5/8 Brian Fox : > 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? > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
