I like this suggestion.
using -P !profile to disable a profile is consistent with negation in
properties activation, but the "-" symbol is also fine, if the feature works
;-)
using -P +profile is a comprehensible way to *add* a profile to the default
active profile list. But some may prefer to us
Hello,
here's a suggestion Re. point 2
> 2. Should default profiles be automatically deactivated if another
profile is
> activated? I don't think the current behaviour should be changed in
2.0.x, but
> for 2.1 I think it's worth considering leaving default profiles active
unless
> explicitly
On Wed, May 14, 2008 at 5:19 PM, sudheshna iyer <[EMAIL PROTECTED]> wrote:
> I have downloaded apache-maven-2.0.9-bin.tar.gz and
> extracted to dir: C:\apache-maven-2.0.9
Please ask questions on the users list instead of dev. You can find
info here: http://maven.apache.org/mail-lists.html
(A Ma
On 15/05/2008, at 12:22 AM, Benjamin Bentmann wrote:
If I don't misunderstand things, the same problems could arise some
day for
the AbstractMojo from the maven-plugin-api.
Yeah, though in that case there's a more direct tie between the
version of Maven and the plugin API than in this c
+1
I think the section below in combination with "requires Maven 2.0.6 or
greater" works.
- Brett
On 15/05/2008, at 10:20 AM, Dan Fabulich wrote:
The release announcement template is here:
http://maven.apache.org/developers/release/releasing.html
It currently says:
You can run mvn -up t
The release announcement template is here:
http://maven.apache.org/developers/release/releasing.html
It currently says:
You can run mvn -up to get the latest version of the plugin, or specify
the version in your project's plugin configuration:
org.apache.maven.plugins
maven-XXX-plugin
Y.
I have downloaded apache-maven-2.0.9-bin.tar.gz and
extracted to dir: C:\apache-maven-2.0.9
I have added C:\apache-maven-2.0.9 to the path. When I
run "mvn --version" at cmd prompt, I got the
following results:
C:\GettingStartedWithHibernate3>mvn --version
Maven version: 2.0.9
Java version: 1.5.
fixed
Raphaël
2008/5/14 Dan Fabulich <[EMAIL PROTECTED]>:
>
> My stage:copy is failing with "override rw-r--r-- rafale/apcvs" prompts.
> Please remember to run fix-permissions.sh when you do a Maven release.
>
> -Dan
>
> -
>
>Should I remove both "-" and "+" since they would both be redundant if
we add "!"?
I would.
>So some examples would be:
>mvn -P !profile1,profile2,profile3
Yep.
>And in maven 2.1 currently this can also be expressed with:
>mvn -P D:profile1,E:profile2,E:profile3
I would make it the same as
I think the ! is probably better then D: E: E:
jesse
On Wed, May 14, 2008 at 4:51 PM, Paul Gier <[EMAIL PROTECTED]> wrote:
> Brian E. Fox wrote:
>
> >
> > Need to think about 1& 2 some more but:
> >
> >
> > > 3. There was a suggestion to allow the use of "!" to disable a profile.
> > >
> > So th
Brian E. Fox wrote:
Need to think about 1& 2 some more but:
3. There was a suggestion to allow the use of "!" to disable a profile.
So the
command line would look like: mvn -P!myProfile
This seems more intuitive than the current syntax using a dash, and I
created
MNG-3571 for it. But I
Need to think about 1& 2 some more but:
>3. There was a suggestion to allow the use of "!" to disable a profile.
So the
>command line would look like: mvn -P!myProfile
>This seems more intuitive than the current syntax using a dash, and I
created
>MNG-3571 for it. But I'm hesitant to add it s
Paul Gier wrote:
3. There was a suggestion to allow the use of "!" to disable a profile.
So the command line would look like: mvn -P!myProfile
Unless some severe drawback is reported, +1 on this because "!" is quite
natural among programmers for negation and also matches the existing syntax
I would like to bring up a couple of issues related to profile activation and
deactivation. While working on MNG-3545 I noticed some cases where the current
behaviour might be improved.
1. What is the correct behaviour when there is more than one activeByDefault
profile and I manually acti
this point was raised several times before, and it was opposed by
infra, so you'd need to ask them. Here I'm sure everybody is +1 ;)
On Tue, May 13, 2008 at 6:31 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> I've rewritten fix-permissions.sh to use absolute paths for find and chmod,
> and remove
On 14-May-08, at 5:29 AM, Brett Porter wrote:
Hi,
I'm running through the issues in Wagon to get towards another
release. On trunk there are already a couple of changes to the
AbstractWagon. In doxia-like fashion, this prevents being able to
use a new wagon with existing versions of Mave
Raphaël Piéroni wrote:
+1 (obviously)
Dan, i will use the script after work.
where is fix-permission.sh located?
/www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh
It was originally just for fixing permissions in the
m2-snapshot-repository, but now you can run it there an
I thought he said it was AbstractWagon that had changed, which may
provide protected methods, etc. that aren't in the interfaces...
At any rate, I think I agree with Benjamin, that we should try to
limit (or reduce) the number of AbstractThing super-classes that are
forced into the system b
+1 from me, if it's safe (I'm not qualified to say, personally).
-john
On May 13, 2008, at 9:31 PM, Dan Fabulich wrote:
I've rewritten fix-permissions.sh to use absolute paths for find
and chmod, and removed the "-user ${USER}" check. I believe this
modified script should be safe to be c
+1
On May 13, 2008, at 1:08 PM, Olivier Lamy wrote:
Hi,
In the preparation of the Maven Invoker Plugin release, I would like
to release maven-invoker:2.0.8.
One issue has been fixed. As there isn't a dedicated jira project a
changes report is available here [1].
Staging repo : http://people.a
If we are filtering the interface from classloading...and the interface
has changed, how does that enable the wagons to work with old Mavens?
Are you saying that the changes are backwards compatible already?
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
Brett Porter wrote:
In doxia-like fashion, this prevents being able to use a new wagon with
existing versions of Maven, because they use code in AbstractWagon (which
is hidden by Maven via provider-api).
If I don't misunderstand things, the same problems could arise some day for
the Abstract
Hi,
I'm running through the issues in Wagon to get towards another
release. On trunk there are already a couple of changes to the
AbstractWagon. In doxia-like fashion, this prevents being able to use
a new wagon with existing versions of Maven, because they use code in
AbstractWagon (whic
+1 (obviously)
Dan, i will use the script after work.
where is fix-permission.sh located?
Raphaël
2008/5/14 Arnaud HERITIER <[EMAIL PROTECTED]>:
> +1 to have this very useful script to unblock us with these annoying
> problems of permissions.
>
> Arnuad
>
>
>
> On Wed, May 14, 2008 at 3:31 AM
I am trying out hibernate examples and these examples
need maven-ant-tasks-2.0.8.jar.
Examples indicate that I need to get
maven-ant-tasks-2.0.8.jar file and place it in
ant_home/lib.
I am not finding maven-ant-tasks-2.0.8.jar, but I am
finding maven-ant-tasks-2.0.8.zip. How do extract
maven-an
+1 to have this very useful script to unblock us with these annoying
problems of permissions.
Arnuad
On Wed, May 14, 2008 at 3:31 AM, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> I've rewritten fix-permissions.sh to use absolute paths for find and
> chmod, and removed the "-user ${USER}" check.
Hi Dan,
I didn't know that we had this script.
Can we document it in our release process :
http://maven.apache.org/developers/release/releasing.html ?
Arnaud
On Wed, May 14, 2008 at 3:06 AM, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> My stage:copy is failing with "override rw-r--r-- rafal
27 matches
Mail list logo
