Isn't the point here that compile scope would turn into runtime scope *when
transitive*?
So this is not the same as the current trick of putting
true on a dependency.
In general I am in favour if demoting dependencies to runtime when
transitive (we always warned this was the long term plan)... Bu
On Apr 13, 2014, at 8:11 AM, Lennart Jörelid wrote:
> Hello all,
>
> Let’s see if we can focus on the issue at hand here.
>
> 12 apr 2014 kl. 16:59 skrev Jason van Zyl :
>
>>
>> On Apr 12, 2014, at 7:24 AM, Lennart Jörelid
>> wrote:
>>
>>> Oh I know it is the recommended practise, but I b
Hello all,
Let’s see if we can focus on the issue at hand here.
12 apr 2014 kl. 16:59 skrev Jason van Zyl :
>
> On Apr 12, 2014, at 7:24 AM, Lennart Jörelid
> wrote:
>
>> Oh I know it is the recommended practise, but I believe that particular
>> recommendation is flawed since it does not con
I think allowing plugins to resolve things with annotations is not a good idea
as we already have project dependencies resolution that happens on the fly per
project. This means it's impossible to fully reason about the requirements of a
project being built up front. This, in practice, leads to
On Apr 12, 2014, at 8:02 AM, Hervé BOUTEMY wrote:
>>
>> In short, if I've followed and understood this correctly, and I may not have
>> (holiday time for me), it sounds a very bad idea Igon.
> IMHO, each choice is debatable: this should be an option in compiler plugin.
> Something like "disable
On Apr 12, 2014, at 7:24 AM, Lennart Jörelid wrote:
> Oh I know it is the recommended practise, but I believe that particular
> recommendation is flawed since it does not consider the needs of *big*
> systems with reactors containing lots of projects.
This simply is not the case. It is precisel
What about (ab-)using the runtime scope for this? The core could inspect
the pom and inject runtime dependencies into the class path.
Regards
Mirko
--
Sent from my mobile
On Apr 12, 2014 2:08 PM, "Hervé BOUTEMY" wrote:
> after thinking more at it, it seems the "scope" for such artifacts is the
after thinking more at it, it seems the "scope" for such artifacts is the
plugin parameter name
so why not resolve artifacts (or collections of artifacts) when injecting
parameters?
I'm not sure we really need a need elemen in pom.
Regards,
Hervé
Le samedi 12 avril 2014 10:14:51 Robert Schol
Le vendredi 11 avril 2014 15:10:01 Chris Graham a écrit :
> Sent from my iPhone
>
> On 11/04/2014, at 9:23 AM, Barrie Treloar wrote:
> > On 10 April 2014 23:37, Lennart Jörelid wrote:
> >> So ... the consequence of your approach would be that POMs throughout a
> >> maven reactor would have to re
Oh I know it is the recommended practise, but I believe that particular
recommendation is flawed since it does not consider the needs of *big*
systems with reactors containing lots of projects.
Basically the recommendation is to repeat some information (i.e. dependency
specs) which is already impli
Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies
:
On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
wrote:
On 11 April 2014 22:10, Benson Margulies wrote:
>
> Fwiw, I don't recall the dependency plugin actually injecting stuff
into
> the project class path but equally wish t
The decision was we couldn't add scopes until the modelVersion gets a
bump... Which is on the cards for maven 4.0.
On Saturday, 12 April 2014, Benson Margulies wrote:
> On Fri, Apr 11, 2014 at 5:57 PM, Stephen Connolly
> > wrote:
> > That's a sign that we need a new scope...
>
> The person who d
On Fri, Apr 11, 2014 at 5:50 PM, Benson Margulies wrote:
> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> wrote:
> > On 11 April 2014 22:10, Benson Margulies wrote:
> >
> >> >
> >> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> into
> >> > the project class path but
On Fri, Apr 11, 2014 at 5:57 PM, Stephen Connolly
wrote:
> That's a sign that we need a new scope...
The person who decided that we couldn't just use an arbitrary custom
value as a scope (thus breaking the tomcat plugin of the time) might
want to reconsider that decision.
>
>
> On 11 April 2014
That's a sign that we need a new scope...
On 11 April 2014 22:50, Benson Margulies wrote:
> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> wrote:
> > On 11 April 2014 22:10, Benson Margulies wrote:
> >
> >> >
> >> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> in
On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
wrote:
> On 11 April 2014 22:10, Benson Margulies wrote:
>
>> >
>> > Fwiw, I don't recall the dependency plugin actually injecting stuff into
>> > the project class path but equally wish that the copy/unpack goals could
>> > simply go away regardl
On 11 April 2014 22:10, Benson Margulies wrote:
> >
> > Fwiw, I don't recall the dependency plugin actually injecting stuff into
> > the project class path but equally wish that the copy/unpack goals could
> > simply go away regardless. (in leu of the more normal xxx-dependencies
> > versions)
>
>
> Fwiw, I don't recall the dependency plugin actually injecting stuff into
> the project class path but equally wish that the copy/unpack goals could
> simply go away regardless. (in leu of the more normal xxx-dependencies
> versions)
If you make them go away, please find them a new home. I use
Op Fri, 11 Apr 2014 22:57:01 +0200 schreef Brian Fox :
My proposal is strictly to prohibit a plugin from modifying a project's
classpath implicitly. That this become fully explicit such that I can
remove some of the convoluted logic in the core to account for this.
Not allowing plugins to rand
> My proposal is strictly to prohibit a plugin from modifying a project's
> classpath implicitly. That this become fully explicit such that I can
> remove some of the convoluted logic in the core to account for this.
>
>
Not allowing plugins to randomly inject new dependencies makes sense. I see
so
On 11 April 2014 14:40, Chris Graham wrote:
>
>
> Sent from my iPhone
>
> On 11/04/2014, at 9:23 AM, Barrie Treloar wrote:
>
> > On 10 April 2014 23:37, Lennart Jörelid
> wrote:
> >
> >> So ... the consequence of your approach would be that POMs throughout a
> >> maven reactor would have to rep
Sent from my iPhone
On 11/04/2014, at 9:23 AM, Barrie Treloar wrote:
> On 10 April 2014 23:37, Lennart Jörelid wrote:
>
>> So ... the consequence of your approach would be that POMs throughout a
>> maven reactor would have to repeat a dependency declaration if the classes
>> in your maven pr
On Apr 10, 2014, at 10:07 AM, Lennart Jörelid wrote:
> So ... the consequence of your approach would be that POMs throughout a
> maven reactor would have to repeat a dependency declaration if the classes
> in your maven project "directly" import a type. This - to me - seems not
> only complex to
On 10 April 2014 23:37, Lennart Jörelid wrote:
> So ... the consequence of your approach would be that POMs throughout a
> maven reactor would have to repeat a dependency declaration if the classes
> in your maven project "directly" import a type. This - to me - seems not
> only complex to resolv
So ... the consequence of your approach would be that POMs throughout a
maven reactor would have to repeat a dependency declaration if the classes
in your maven project "directly" import a type. This - to me - seems not
only complex to resolve in a big reactor, but quite user-unfriendly as
well. An
I realize folks are busy, I'll just run with this given I think we all agree
immutable classpaths are better and fiddly magic in the core is bad. I'm going
to remove the capability to dynamically fiddle with the project classpath and
the IT for MNG-4363 will be omitted from the run for Maven 4.0
On 7 Apr 2014, at 19:37, Lennart Jörelid wrote:
I don't understand the difference between what you suggest here, Mark,
and
simply disabling transitive dependencies.
Could you elaborate somewhat?
Well, the basics are:
* When compiling code, all I need to do is satisfy the contracts my
depend
On Apr 7, 2014, at 1:35 PM, Jörg Schaible wrote:
> Jason van Zyl wrote:
>
>>
>> I'm not exactly sure what your question is. Do you mean how would you
>> accomplish these types of tasks without using the resolver directly and do
>> this declaratively?
>
> No, the plugin should use the resolver
Jason van Zyl wrote:
> On Apr 7, 2014, at 3:19 AM, Jörg Schaible
> wrote:
>
>> Hi Jason,
>>
>> Jason van Zyl wrote:
>>
>>>
>>> If everyone agrees we can start systematically documenting what has been
>>> removed, as we have lost track of this accurately in the past. I'd like
>>> to make a 4.x
On Apr 7, 2014, at 3:19 AM, Jörg Schaible wrote:
> Hi Jason,
>
> Jason van Zyl wrote:
>
>>
>> If everyone agrees we can start systematically documenting what has been
>> removed, as we have lost track of this accurately in the past. I'd like to
>> make a 4.x branch in 4 weeks or so and this wi
This is really about providing access restrictions to the compiler. JDT has
done this forever as OSGi requires it and it's possible with modern Javac
compiler as well. It's more about what you tell the compiler to consider than
our notions of scope.
On Apr 6, 2014, at 9:41 PM, Mark Derricutt w
On Apr 6, 2014, at 8:32 PM, Benson Margulies wrote:
> It seems to me we have several concepts that might benefit from some combing.
>
> We have 'path-like' structures. When building Java programs, we have
> the compile and test classpaths. _Within_ these classpaths, we have
> scopes. In other w
Yes, I realize what Mark was referring to - but I still cannot see the
point in having to repeat oneself WRT importing an already imported
compile-scope dependency in all projects where it would be used. This would
imply loads of redundant imports in all dependent poms in a multi-module
reactor alo
Just wanted to through 2c in.
Jason, you mentioned supporting other uses cases such an Android builds. I
thought I'd explain what's required from that perspective.
The Android team have defined an Android archive (AAR) that holds a JAR and
various Android resources. When the AAR is declared as a
I believe he's talking about what's mentioned here (see the asterix):
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
/Anders
On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
wrote:
> I don't understand the difference between what you sugges
I don't understand the difference between what you suggest here, Mark, and
simply disabling transitive dependencies.
Could you elaborate somewhat?
2014-04-07 3:41 GMT+02:00 Mark Derricutt :
> On 7 Apr 2014, at 12:32, Benson Margulies wrote:
>
> We then have other logical classpaths. . Something
Hi Jason,
Jason van Zyl wrote:
> Hi,
>
> I started making of list of things I'd like to remove in Maven 4.0.0, but
> I would like to start getting some agreement on what we can yank and this
> is the first concrete request. I would like to remove the ability for
> plugins to magically inject dep
Hi Mark,
Mark Derricutt wrote:
> On 7 Apr 2014, at 12:32, Benson Margulies wrote:
>
>> We then have other logical classpaths. . Something like javadoc should
>> be able to define another named classpath structure; combining the
>> dependencies of the plugin's implementation with dynamic code
>>
https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+plugins
On Apr 6, 2014, at 4:47 PM, Robert Scholte wrote:
> Op Sun, 06 Apr 2014 20:54:24 +0200 schreef Jason van Zyl :
>
>>
>> On Apr 6, 2014, at 2:24 PM, Robert Scholte wrote:
>>
>>> Hi,
>>>
>>> if we are talking ab
I like Robert's idea of getting all the variants in a wiki page. But I'd still
like you guys to answer the initial query which was to agree on removing the
magic of plugins adding things to the classpath and requiring it be specific.
On Apr 6, 2014, at 8:32 PM, Benson Margulies wrote:
> It see
On 7 Apr 2014, at 12:32, Benson Margulies wrote:
We then have other logical classpaths. . Something like javadoc should
be able to define another named classpath structure; combining the
dependencies of the plugin's implementation with dynamic code
(doclets, whatever) seems like a category confu
It seems to me we have several concepts that might benefit from some combing.
We have 'path-like' structures. When building Java programs, we have
the compile and test classpaths. _Within_ these classpaths, we have
scopes. In other words, I think that the concept of a path and the
concept of a sco
On 7 Apr 2014, at 6:24, Robert Scholte wrote:
You must be able to specify doclettags artifact. There are
dependencies, but they are not added to the classpath. These jars are
added to a different argument of the javadoc executable.
Would this be possible via plugin-level custom dependency ty
Op Sun, 06 Apr 2014 20:54:24 +0200 schreef Jason van Zyl :
On Apr 6, 2014, at 2:24 PM, Robert Scholte wrote:
Hi,
if we are talking about immutable classpath I agree. But there's
something else which needs to be improved.
Let me describe it with the maven-javadoc-plugin, but there are more
On Apr 6, 2014, at 2:24 PM, Robert Scholte wrote:
> Hi,
>
> if we are talking about immutable classpath I agree. But there's something
> else which needs to be improved.
> Let me describe it with the maven-javadoc-plugin, but there are more plugins
> suffering the same problem.
> You must be
Hi,
if we are talking about immutable classpath I agree. But there's something
else which needs to be improved.
Let me describe it with the maven-javadoc-plugin, but there are more
plugins suffering the same problem.
You must be able to specify doclettags artifact. There are dependencies,
b
On Apr 6, 2014, at 10:38 AM, Lennart Jörelid wrote:
> Hm.
>
> Removing the possibility for plugins to manipulate the classpath is - in my
> opinion - a rather poor idea.
I believe the opposite in that magically manipulating the classpath is a poor
idea. As evidenced in the convoluted logic in
Hm.
Removing the possibility for plugins to manipulate the classpath is - in my
opinion - a rather poor idea.
If we have a problem with plugins contaminating downstream classpath, then
we should provide a simple means for plugins to define Dependencies which
would be added to the classpath of the
Hi,
I started making of list of things I'd like to remove in Maven 4.0.0, but I
would like to start getting some agreement on what we can yank and this is the
first concrete request. I would like to remove the ability for plugins to
magically inject dependencies. Plugins can either declare thei
49 matches
Mail list logo
