Re: Maven extensions

2016-01-12 Thread Tamás Cservenák
+0 in general, but I think we should first check how multiple extensions will/may work, and see, what actually, was the original intention of extensions. We might miss some important reasons to NOT do this (maybe due to some technical reason?) For example, I use Takari smart builder, Takari

Re: Maven extensions

2016-01-12 Thread Stephen Connolly
+1 On Tuesday 12 January 2016, Hervé BOUTEMY wrote: > installation level need to point to user space, in a per-user location (~, > or > ${user.home} if you prefer this syntax): then the user space is filled or > not, > user per user > > multi-user installation is exactly

Re: Maven extensions

2016-01-12 Thread Jason van Zyl
User extensions could be used for something like logging maybe and that would be fine. User extensions that may knock out project extensions that are required to build are is an issue. A user installs a extension to colour the log output, so what. But the first binding discovered is what works,

Maven extensions

2016-01-11 Thread Hervé BOUTEMY
there are discussions lately on extensions, with 2 different meanings on this: - either *project* extensions, with the .mvn feature added in Maven 3.3.0 - or more generic extension, like classical *installation* extensions jars in ${maven.home}/lib/ext/ as configured in

Re: Maven extensions

2016-01-11 Thread Hervé BOUTEMY
installation level need to point to user space, in a per-user location (~, or ${user.home} if you prefer this syntax): then the user space is filled or not, user per user multi-user installation is exactly the target use: with this user extensions feature, each user can customize its own

Re: Maven extensions

2016-01-11 Thread Arnaud Héritier
+1 Le mardi 12 janvier 2016, Hervé BOUTEMY a écrit : > there are discussions lately on extensions, with 2 different meanings on > this: > > - either *project* extensions, with the .mvn feature added in Maven 3.3.0 > > - or more generic extension, like classical

Re: Maven extensions

2016-01-11 Thread Anders Hammar
> > Then I think we are missing *user* extensions, that would be added in > ${maven.home}/bin/m2.conf the same way as installation extensions, but > pointing to ~/.m2/ext/*.jar > What would the benefit be of configuring this on installation level but keep the jar in user space? How would that

RE: Maven extensions (was RE: [Q] Setting a property so that it's visible from another plugin)

2004-04-23 Thread dion_gillard
Brett Porter [EMAIL PROTECTED] wrote on 22/04/2004 05:23:25 PM: Dion was going to do this last year (actually make a tags JAR), but nothing came of it. From memory was that the consensus was to leave it alone until 1.0 was out. It makes a ton of sense, though. The only plugin that

RE: Maven extensions (was RE: [Q] Setting a property so that it's visible from another plugin)

2004-04-22 Thread Brett Porter
rather get 1.0 out with what works now and forget about changing things. I've got enough to do already :) - Brett -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Thursday, 22 April 2004 5:12 PM To: 'Maven Developers List' Subject: Maven extensions (was RE: [Q

Maven extensions (was RE: [Q] Setting a property so that it's visible from another plugin)

2004-04-22 Thread Vincent Massol
I think we already have a mechanism to provide extensions to Maven: it's called a plugin! Thus an even better solution for adding the setter tag is to move all the existing Maven Jelly tags to a plugin of its own. That will allow maven b10, rc1, etc users to automatically get the new features

RE: Maven extensions (was RE: [Q] Setting a property so that it's visible from another plugin)

2004-04-22 Thread Vincent Massol
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 22 April 2004 09:23 To: 'Maven Developers List' Subject: RE: Maven extensions (was RE: [Q] Setting a property so that it's visible from another plugin) Dion was going to do this last year (actually make a tags