It seems like we would need an ASM based post processor to analyze it before
generating the pom that gets deployed.
-Original Message-
From: William Ferguson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 29, 2008 7:01 PM
To: Maven Developers List; [EMAIL PROTECTED]
Subject: Re: Plugin d
Because it's pulling from the pom and any other sourceRoots injected by plugins
(or build-helper-plugin).
-Original Message-
From: walid joseph Gedeon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 29, 2008 2:40 PM
To: Maven Developers List
Subject: Re: Can plugins be extended?
Ah, I wa
As Benjamin points out at the end of that Jira, the current behaviour is there
to deal with use of libraries containing classes that extend classes in other
libraries.
Seems to me that we need a way to differentiate in our projects which
dependencies need to get *exported* as compile dependenci
Benjamin Bentmann wrote:
>> Solved, the dependency was inherited transitively by
>> maven-artifact-2.0.9.
>
> You should never rely on transitive dependencies if you directly use its
> classes/methods in your code but always declare them directly. The goal
> dependency:analyze
> can help you a
Ah, I wasn't aware of that... thanks for the heads up Jörg...
I'm wondering why the parameter compileSourceRoots is defined as @readonly
in CompilerMojo... is there a reason?
On Tue, Apr 29, 2008 at 8:05 PM, Jörg Schaible <
[EMAIL PROTECTED]> wrote:
>
> But you have to be aware of the downside:
But you have to be aware of the downside: You cannot upgrade the
compiler-plugin anymore without creating a new version of your plugin. Any
plugin is loaded once and the first one wins. Nice effects in reactor builds ;-)
walid joseph Gedeon wrote:
> Indeed! Thanks :-)
>
> So, for the summary,
Please ignore my last question :-) I should have read the "How to
contribute" ;-)
On Tue, Apr 29, 2008 at 7:02 PM, walid joseph Gedeon <[EMAIL PROTECTED]>
wrote:
> Indeed! Thanks :-)
>
> So, for the summary, here are the steps that provided my solution:
>
> 1) in the pom, added maven-inherit-pl
Indeed! Thanks :-)
So, for the summary, here are the steps that provided my solution:
1) in the pom, added maven-inherit-plugin, as described in the plugin
documentation.
2) in the mojo, in my case I needed to extend a goal with a different
name:
/**
* @extendsPlugin maven-compiler-plugin
Try add type to dependency:
maven-plugin
VELO
On Tue, Apr 29, 2008 at 1:46 PM, walid joseph Gedeon <[EMAIL PROTECTED]>
wrote:
> It seems to want to do what I need... but I can't seem to get rid of this
> error:
>
> [ERROR] BUILD ERROR
> [INFO]
> -
It seems to want to do what I need... but I can't seem to get rid of this
error:
[ERROR] BUILD ERROR
[INFO]
[INFO] maven-compiler-plugin plugin is not a dependency
eventhough I do have it in my pom...
org.apache.
I use it, works!
VELO
On Tue, Apr 29, 2008 at 11:45 AM, Benoit Decherf <[EMAIL PROTECTED]>
wrote:
> Here is the plugin:
> http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin/
>
> Benoit
>
>
> Brian E. Fox wrote:
>
> > Plugins can't really be extended. What is most likely happening i
Here is the plugin:
http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin/
Benoit
Brian E. Fox wrote:
Plugins can't really be extended. What is most likely happening is that the
metadata that tells plexus what to inject is not included in your plugin. There
is a plugin/tool out th
Thanks! I'll give it a try.
On Tue, Apr 29, 2008 at 4:40 PM, <[EMAIL PROTECTED]> wrote:
> This is a known issue [1]. Short answer: no, it is not possible. Long
> answer: maven-inherit-plugin [2] I don't have any experience with it, but
> you could give it a try.
>
> Hth,
>
> Nick S.
>
> [1] http:
This is a known issue [1]. Short answer: no, it is not possible. Long answer:
maven-inherit-plugin [2] I don't have any experience with it, but you could
give it a try.
Hth,
Nick S.
[1] http://jira.codehaus.org/browse/MNG-3042
[2] http://www.ops4j.org/projects/pax/construct/maven-inherit-plugi
Plugins can't really be extended. What is most likely happening is that the
metadata that tells plexus what to inject is not included in your plugin. There
is a plugin/tool out there that supposedly allows you to extend plugins by
merging the metadata, but I forget the name.
-Original Messa
Hello all,
After failing to customize the compiler pluging (by passing
in the maven-compiler-plugin ); I've
went onto trying to extend the maven-compiler-plugin CompileMojo to just set
that variable.
It looks like I've missed something: the injected parameters of the super
classes are not bein
Solved, the dependency was inherited transitively by maven-artifact-2.0.9.
You should never rely on transitive dependencies if you directly use its
classes/methods in your code but always declare them directly. The goal
dependency:analyze
can help you a big deal in ensuring all your dependenc
Jörg Schaible wrote:
> Hi folks,
>
> developing a new plugin I made usage of plexus-utils 1.5.1.
> Unfortunately this fails when I try to run the plugin in a
> real project, because some classes seem outdated (missing method in
> FileUtils):
>
> = %<
> [FATAL ERROR]
> com.el
Hi folks,
developing a new plugin I made usage of plexus-utils 1.5.1. Unfortunately this
fails when I try to run the plugin in a real project, because some classes seem
outdated (missing method in FileUtils):
= %<
[FATAL ERROR]
com.elsagsolutions.buildsystem.maven2.plugin.
>> Is there an issue with a huge number of votes attached to it?
>To my knowledge, no. We have MNG-2216 that is quite similar to our proposal
>but has (excluding myself) only three other votes which is not that much.
>Let my point out that the encoding issue is subtle and I expect a fair
>amount
Hi guys,
Do we have a rule about the list of plugins on our website regarding if
they are free or not ?
Jalopy is no more free and we have a link to the company who sells it
(triemax).
Should we keep it ?
Arnaud
http://maven.apache.org/plugins/index.html
http://www.triemax.com/products/jal
Brian E. Fox wrote:
Who exactly is asking for this change?
Basically only me, in an attempt to guarantee reproducible builds by
eliminating a dependency on an environmental property.
Is there an issue with a huge number of votes attached to it?
To my knowledge, no. We have MNG-2216 that is
2008/4/29 Brian E. Fox <[EMAIL PROTECTED]>:
> I browsed the repo earlier and everything seemed in order, I have no
> idea what this does or how to test it, but given that it's a shared
> component that won't harm anyone, +1.
Thanks. I tried to give a brief synopsis of maven-runtime at the
start
2008/4/29 Wendy Smoak <[EMAIL PROTECTED]>:
> On Mon, Apr 28, 2008 at 5:40 PM, Mark Hobson <[EMAIL PROTECTED]> wrote:
>
> > 4hrs to go.. anyone?
>
> Does it have docs? How would I test it?
It has Javadoc but no site doc. I figured that since only a handful
of shared components have site doc and
24 matches
Mail list logo
