Re: maven download broken on all mirrors

[Vincent Latombe]

Thanks to whoever restored it!

Vincent


Le mer. 4 sept. 2019 à 17:50, Robert Scholte  a
écrit :

> Is there still a page with a reference to 3.6.0?
>
> I would expect that 3.6.0 should be downloaded via archives[1]
>
> Robert
>
> [1] https://archive.apache.org/dist/maven/maven-3/
>
>
> On Wed, 04 Sep 2019 14:38:09 +0200, Vincent Latombe
>  wrote:
>
> > Hello,
> >
> > it looks like 3.6.0 has also been removed in the process and hasn't been
> > restored yet.
> >
> > Vincent
> >
> >
> > Le mar. 3 sept. 2019 à 19:22, Enrico Olivelli  a
> > écrit :
> >
> >> I am sorry
> >> We are fixing it.
> >> We had accidentally removed 3.6.1, before publishing 3.6.2.
> >>
> >> Enrico
> >>
> >>
> >> Il giorno mar 3 set 2019 alle ore 19:16 Tamás Cservenák <
> >> ta...@cservenak.net>
> >> ha scritto:
> >>
> >> > FYI,
> >> > And just to confirm, HU mirror lost 3.6.1 as well.
> >> >
> >> > T
> >> >
> >> > -- Forwarded message -
> >> > From: 'Jörg Hohwiller' via mojohaus-dev
> >> 
> >> > Date: Tue, Sep 3, 2019 at 7:13 PM
> >> > Subject: maven download broken on all mirrors
> >> > To: mojohaus-dev 
> >> >
> >> >
> >> > Hi there,
> >> >
> >> > may be wrong here but I unsubsribed from maven-dev and subscribing
> >> just
> >> for
> >> > this notice is too much burden.
> >> > So in case anyone from maven core team is reading this:
> >> >
> >> > It is currently impossible to download the latest version of maven
> >> (3.6.1).
> >> > It is gone from all the mirrors.
> >> > Someting was really entierely messed up here:
> >> > https://maven.apache.org/download.cgi
> >> >
> >> > I noticed this because it broke my travis-ci build so it is not just a
> >> > local CDN or proxy issue, but seems to be globally effective.
> >> > Hope this gets fixed asap as this is real pain if users already fail
> >> at
> >> > downloading.
> >> >
> >> > Cheers
> >> >   Jörg
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups
> >> > "mojohaus-dev" group.
> >> > To unsubscribe from this group and stop receiving emails from it,
> >> send an
> >> > email to mojohaus-dev+unsubscr...@googlegroups.com.
> >> > To view this discussion on the web visit
> >> >
> >> >
> >>
> https://groups.google.com/d/msgid/mojohaus-dev/6b5ade3c-a607-4999-a0ae-af6332d0bacd%40googlegroups.com
> >> > <
> >> >
> >>
> https://groups.google.com/d/msgid/mojohaus-dev/6b5ade3c-a607-4999-a0ae-af6332d0bacd%40googlegroups.com?utm_medium=email&utm_source=footer
> >> > >
> >> > .
> >> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: maven download broken on all mirrors

[Vincent Latombe]

Hello,

it looks like 3.6.0 has also been removed in the process and hasn't been
restored yet.

Vincent


Le mar. 3 sept. 2019 à 19:22, Enrico Olivelli  a
écrit :

> I am sorry
> We are fixing it.
> We had accidentally removed 3.6.1, before publishing 3.6.2.
>
> Enrico
>
>
> Il giorno mar 3 set 2019 alle ore 19:16 Tamás Cservenák <
> ta...@cservenak.net>
> ha scritto:
>
> > FYI,
> > And just to confirm, HU mirror lost 3.6.1 as well.
> >
> > T
> >
> > -- Forwarded message -
> > From: 'Jörg Hohwiller' via mojohaus-dev 
> > Date: Tue, Sep 3, 2019 at 7:13 PM
> > Subject: maven download broken on all mirrors
> > To: mojohaus-dev 
> >
> >
> > Hi there,
> >
> > may be wrong here but I unsubsribed from maven-dev and subscribing just
> for
> > this notice is too much burden.
> > So in case anyone from maven core team is reading this:
> >
> > It is currently impossible to download the latest version of maven
> (3.6.1).
> > It is gone from all the mirrors.
> > Someting was really entierely messed up here:
> > https://maven.apache.org/download.cgi
> >
> > I noticed this because it broke my travis-ci build so it is not just a
> > local CDN or proxy issue, but seems to be globally effective.
> > Hope this gets fixed asap as this is real pain if users already fail at
> > downloading.
> >
> > Cheers
> >   Jörg
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "mojohaus-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to mojohaus-dev+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> >
> >
> https://groups.google.com/d/msgid/mojohaus-dev/6b5ade3c-a607-4999-a0ae-af6332d0bacd%40googlegroups.com
> > <
> >
> https://groups.google.com/d/msgid/mojohaus-dev/6b5ade3c-a607-4999-a0ae-af6332d0bacd%40googlegroups.com?utm_medium=email&utm_source=footer
> > >
> > .
> >
>

Re: Mojo API to add target/generated-sources/DIR to eclipse's source folder

[Vincent Latombe]

This annotation just allows you to skip the  declaration when you
add the execution to your pom.

If you want to skip the  block, you'll need to create a custom
packaging [1]. Then you'd specify my-packaging in
your pom, instead of jar (or any other value you
currently use)

Cheers,

Vincent

[1]
http://blog.sonatype.com/2009/08/create-a-customized-build-process-in-maven/#.VXXWhUZ5zaU

Vincent

2015-06-08 19:21 GMT+02:00 Behrooz Nobakht :

> Let me continue with another question. Currently, my Mojo implementation
> has
>
> @Mojo(name = "my-goal-name", defaultPhase =
> LifecyclePhase.GENERATE_SOURCES)
>
> However, I still need to add `` when I'm using the plugin;
> otherwise it's just ignored.
> I was expecting that the Mojo annotation would remove this requirement.
> What am I missing?
>
> Thanks,
> Behrooz
>
>
> On Mon, Jun 8, 2015 at 6:36 PM, Behrooz Nobakht  wrote:
>
> > Hi Andreas,
> >
> > Thank you for the pointer. It helped and it worked.
> > I was using an improper life cycle phase as the default.
> >
> > Cheers,
> > Behrooz
> >
> >
> >
> > On Mon, Jun 8, 2015 at 6:13 PM, Andreas Gudian  >
> > wrote:
> >
> >> Hi,
> >>
> >> You can check the build-helper-maven-plugin, which has a tiny goal to
> add
> >> a
> >> source directory to the project:
> >>
> >>
> https://github.com/mojohaus/build-helper-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/buildhelper/AddSourceMojo.java
> >>
> >> The maven-eclipse-plugin picks up all source directories listed in the
> >> model of the build.
> >>
> >> Hope that helps,
> >> Andreas
> >>
> >> Am Montag, 8. Juni 2015 schrieb Behrooz Nobakht :
> >>
> >> > Hi,
> >> >
> >> > I am trying to follow what `maven-plugin-plugin` Mojo does when
> >> generating
> >> > HelpMojo.java.
> >> > It also updates eclipse's .classpath some way (?) that I can see the
> >> > `target/generated-sources/plugin`
> >> > as a source folder in my IDE.
> >> >
> >> > Similarly, this is also what maven-jaxb2-plugin does when generating
> >> > sources files from a schema.
> >> >
> >> > I'm a bit clueless at this moment how to achieve the same for a custom
> >> > plugin I'm developing.
> >> > Any specific documentation, hints, or example sources I can look into
> >> for
> >> > this?
> >> >
> >> > Thanks in advance,
> >> > Behrooz
> >> >
> >>
> >
> >
> >
> > --
> > -- Behrooz Nobakht
> >
>
>
>
> --
> -- Behrooz Nobakht
>

Re: Maven Web Site

[Vincent Latombe]

On my mobile the left sidebar doesn't render well, so I cannot really
tell...

Le dim. 5 avr. 2015 09:22, Petar Tahchiev  a écrit :

> Hmm..
>
> not that my opinion matters, but I'm more inclined towards: -0. Yes that's
> right minus zero. And I'll tell you why. It's a good theme, the look is
> slightly better than the existing one (hence +1), but I feel that if we go
> for it we will never get the time to create a better site-plugin (using
> asciidoctor or any other modern, extensible technology) (hence the -1). The
> existing website I believe is written in plain markdown (I'm not sure the
> site plugin supports even Markdown Extra, or Github Flavored Markdown)
> which gives not many options when it comes to formatting.
>
> So in the end I believe my vote would be -0.
>
>
> 2015-04-05 8:37 GMT+03:00 Hervé BOUTEMY :
>
> > +1
> >
> > the only real problem I see is the left column that is too big: I don't
> > know
> > if it can be tweaked through CSS
> > But even with that, this version is really better
> >
> > one minor issue: icon is missing in
> > http://khmarbaise.github.io/maven-site/download.html
> >
> > really great enhancement!
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 5 avril 2015 01:20:22 Karl Heinz Marbaise a écrit :
> > > Hi,
> > >
> > > what do you think about the following:
> > >
> > > http://khmarbaise.github.io/maven-site/
> > >
> > > Just did some very simple things...but in my opinion it looks better
> > > than the current site? WDYT ?
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > -
> > > 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
> >
> >
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

Re: Problem managing multiple versions of the same dependency via patient - child poms

[Vincent Latombe]

Hi,

Please use the Maven Users list instead. This list is meant for actual
development of Maven itself.

Vincent


2013/9/22 Suranga Kasthurirathne 

> Hi,
>
> I apologize in advance if this email contains sketchy / incomplete details.
> I'm not really a maven expert, and would love any advice that would be
> helpful.
>
> I'm  a volunteer for a open source product which uses a modular
> architecture. We have a core project (supported by maven). Users can write
> their own modules (also supported by maven) to add the custom features that
> they require, and load them onto the OpenMRS core.
>
> Now in maven, if we declare multiple versions of the same dependency in the
> pom, maven automatically uses the very latest version of the given
> dependency.
>
> However, I am having trouble trying to replicate this by overriding a core
> dependency via a module.
> Assuming that the project trunk uses version 1.0 of jar A, and I want to
> write a module that requires version 2.0 of the same jar, how can I add
> this dependency to the pom file of a module, and make maven use the more
> recent dependency declared in the pom file of the module ? At the moment,
> what happens when I try this is both versions of the jar get loaded, and a
> casting error occurs.
>
> Any advice on how to manage this would be very much appreciated !
>
> --
> Best Regards,
>
> Suranga
>

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

[Vincent Latombe]

When you rewrite history of something that has been already pushed, you
need to push and add --force to rewrite history on the remote repo.

Of course, as Fred mentioned, this isn't recommended for branches that have
been pulled by other people, because it will mess their next pull.

Vincent


2013/7/27 Jeff Jensen 

> That message indicates you need to git pull first.  Even though you
> may already have done so and no one else has pushed since, this usually
> happens when modifying a commit that has been pushed/shared.
>
> On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY 
> wrote:
> > the last 2 commits are to be amended: lst one for MNG-5499, previous one
> for
> > MNG-5495
> >
> > I tried git commit --amend -m "[MNG-5499]..." for the last one, but when
> I git
> > push, I get
> >
> > To https://git-wip-us.apache.org/repos/asf/maven.git
> >  ! [rejected]master -> master (non-fast-forward)
> > error: failed to push some refs to '
> https://git-wip-us.apache.org/repos/asf/maven.git'
> > hint: Updates were rejected because the tip of your current branch is
> behind
> > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
> > hint: before pushing again.
> > hint: See the 'Note about fast-forwards' in 'git push --help' for
> details.
> >
> >
> > Did I do something wrong? Or git repo at ASF is configured to avoid such
> > things?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
> >> Of course, if anyone is working down stream of this, they will hate you,
> >> and it should be left as is.
> >>
> >> On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke 
> wrote:
> >> > Yes, easily, if it's the HEAD just do a --amend on it and update it
> >> > yourself, Jason's name will be retained. If it's not HEAD then do
> rebase
> >> > -i
> >> >  then mark the one of interest
> for
> >> > comment edit and proceed.
> >> >
> >> > On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY
> > wrote:
> >> >> IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
> >> >>
> >> >> I'm not a git blackbelt: can the comment be updated to add the
> classical
> >> >> [MNG-5499]?
> >> >> (and next time not be forgotten from initial comment :) )
> >> >>
> >> >> I'm adding a reference to the commit in the Jira issue
> >> >>
> >> >> Regards,
> >> >>
> >> >> Hervé
> >> >>
> >> >> Le samedi 27 juillet 2013 01:45:44 jvan...@apache.org a écrit :
> >> >> > o change the scope of org.eclipse.sisu to test in the
> >> >>
> >> >> maven-aether-provider
> >> >>
> >> >> > to prevent it from leaking out to clients.
> >> >> >
> >> >> >
> >> >> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> >> >> > Commit:
> http://git-wip-us.apache.org/repos/asf/maven/commit/e084ff3b
> >> >> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e084ff3b
> >> >> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e084ff3b
> >> >> >
> >> >> > Branch: refs/heads/master
> >> >> > Commit: e084ff3b8c04bdfdac62a28a1bef8ec87762d4dc
> >> >> > Parents: 0609504
> >> >> > Author: Jason van Zyl 
> >> >> > Authored: Fri Jul 26 21:09:50 2013 -0400
> >> >> > Committer: Jason van Zyl 
> >> >> > Committed: Fri Jul 26 21:09:50 2013 -0400
> >> >> >
> >> >> >
> --
> >> >> >
> >> >> >  maven-aether-provider/pom.xml | 30 --
> >> >> >  1 file changed, 16 insertions(+), 14 deletions(-)
> >> >> >
> >> >> >
> --
> >> >>
> >> >>
> http://git-wip-us.apache.org/repos/asf/maven/blob/e084ff3b/maven-aether-p
> >> >> rov>>
> >> >> > ider/pom.xml
> >> >> >
> --
> >> >>
> >> >> diff
> >> >>
> >> >> > --git a/maven-aether-provider/pom.xml
> b/maven-aether-provider/pom.xml
> >> >>
> >> >> index
> >> >>
> >> >> > 910fab6..9235f1c 100644
> >> >> > --- a/maven-aether-provider/pom.xml
> >> >> > +++ b/maven-aether-provider/pom.xml
> >> >> > @@ -63,20 +63,6 @@ under the License.
> >> >> >
> >> >> >aether-impl
> >> >> >
> >> >> >  
> >> >> >  
> >> >> >
> >> >> > -  org.eclipse.aether
> >> >> > -  aether-connector-wagon
> >> >> > -  test
> >> >> > -
> >> >> > -
> >> >> > -  org.apache.maven.wagon
> >> >> > -  wagon-file
> >> >> > -  test
> >> >> > -
> >> >> > -
> >> >> > -  org.eclipse.sisu
> >> >> > -  org.eclipse.sisu.plexus
> >> >> > -
> >> >> > -
> >> >> >
> >> >> >org.codehaus.plexus
> >> >> >plexus-component-annotations
> >> >> >
> >> >> >  
> >> >> >
> >> >> > @@ -96,6 +82,22 @@ under the License.
> >> >> >
> >> >> >  
> >> >> >
> >> >> >
> >> >> >
> >> >> >  
> >> >> >
> >> >> > +
> >> >> > +
> >> >> > +  org.eclipse.aether
> >> >> > +  aether-connector-wagon
> >> >> > +  test
> >> >> > +
> >> >> > +
> >> >> > +  org.apache.maven.wagon
> >> >> > +  wa

Re: Maven 3.1.0-beta-1

[Vincent Latombe]

OK, thanks for the clarification.
Vincent


2013/6/22 Jason van Zyl :
>
> On Jun 21, 2013, at 11:48 PM, Vincent Latombe  
> wrote:
>
>> Hello,
>>
>> I have a question about the alpha-1 release. I see that Aether has
>> been updated to 0.9.0 M2.
>> Does it implies that issue MNG-2802 (Concurrent-safe access to local
>> Maven repository) is now implemented ?
>>
>
> No, it does not.
>
>> If this is the case, then IMHO this should be mentioned, even
>> highlighted in the release notes. I think this kind of improvement is
>> very expected for all people doing CI, as this would allow a major
>> speed up and reduce storage for local repositories in this kind of
>> environment.
>>
>> Cheers,
>>
>> Vincent
>>
>>
>> 2013/6/21 Jörg Schaible 
>>>
>>> Hi Jason,
>>>
>>> first, thanks that you actually take your time to look into it!
>>>
>>> Jason van Zyl wrote:
>>>
>>>> I unpacked your example and ran your preparation script and it fails in
>>>> 2.2.1 as well:
>>>>
>>>> https://gist.github.com/jvanzyl/5824206
>>>
>>> The submodules are independent projects, you have to run "clean install".
>>> See the following session (I have modified the POMs of the children by
>>> adding a "" element, the original example is now ~2 years
>>> old):
>>>
>>> https://gist.github.com/joehni/6aa8516bd5408144ec53
>>>
>>> Note, that after a successful run with M221, the build with M3x will no
>>> longer fail, but pack stale snapshots. To raise an error, you have to clean
>>> the repo from snapshots in /bugs/maven.
>>>
>>>> What's the overall usecase? You have a build with snapshots and you find
>>>> you need to go back to a release so you lock down to a previous release
>>>> and want to use that?
>>>
>>> The final distribution of our product or projects typically consists of
>>> hundreds of artifacts, where most of them have individual release cycles. In
>>> the HEAD revision those are linked in a nested directory structure using
>>> "builder POMs" i.e. POMs that have only modules declared, but get never
>>> released themselves (like the POM in the root of the example). The versions
>>> of the individual artifact are managed in a shared parent POM. In HEAD those
>>> are typically all snapshot versions.
>>>
>>> This changes after a major release of the overall product, then all those
>>> versions become final, the shared parent is released first followed by all
>>> other artifacts in dependency order using this released parent. This works
>>> all fine.
>>>
>>> Now we get into maintenance mode of that major release. Due to the
>>> independence of the artifacts we have to branch only the affected projects
>>> in case of bugs. Say we have JAR artifacts JAR-A to JAR-Z and we develop bug
>>> fixes for JAR-C and JAR-S. This means we branch the shared parent, set JAR-C
>>> and JAR-S to snapshot and also the artifacts that will assemble those to two
>>> jars, say WAR-X and DIST-ZIP. Then we create a builder for the maintenance
>>> branch that contains those jars, the war and the distribution zip as module.
>>> Building this we should get a war that contains JAR-C and JAR-S as snapshot
>>> and all the others as release and the distribution contains the affected
>>> WAR-X as snapshot and all other stuff as released version - the perfect
>>> situation to test the fix.
>>>
>>> Unfortunately M3 fails here, because it is under some circumstance not able
>>> to calculate the proper build order (maybe it does no longer take attached
>>> snapshot artifacts into account ?!?) and will either pack a stale snapshot
>>> from the local repository or fail, because the snapshot is built at a later
>>> time.
>>>
>>>> If you want to iteratively work on it together put it in a github repo.
>>>
>>> If you bear with me, may day-to-day work is with svn only and my learning
>>> curve with git/github is still steep, e.g. I did not know about gists, so I
>>> already learned something new.
>>>
>>> Cheers and thanks for your time,
>>> Jörg
>>>
>>>
>>>
>>> -
>>> 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
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
>   -- Jakob Burckhardt
>
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.1.0-beta-1

[Vincent Latombe]

Hello,

I have a question about the alpha-1 release. I see that Aether has
been updated to 0.9.0 M2.
Does it implies that issue MNG-2802 (Concurrent-safe access to local
Maven repository) is now implemented ?

If this is the case, then IMHO this should be mentioned, even
highlighted in the release notes. I think this kind of improvement is
very expected for all people doing CI, as this would allow a major
speed up and reduce storage for local repositories in this kind of
environment.

Cheers,

Vincent


2013/6/21 Jörg Schaible 
>
> Hi Jason,
>
> first, thanks that you actually take your time to look into it!
>
> Jason van Zyl wrote:
>
> > I unpacked your example and ran your preparation script and it fails in
> > 2.2.1 as well:
> >
> > https://gist.github.com/jvanzyl/5824206
>
> The submodules are independent projects, you have to run "clean install".
> See the following session (I have modified the POMs of the children by
> adding a "" element, the original example is now ~2 years
> old):
>
> https://gist.github.com/joehni/6aa8516bd5408144ec53
>
> Note, that after a successful run with M221, the build with M3x will no
> longer fail, but pack stale snapshots. To raise an error, you have to clean
> the repo from snapshots in /bugs/maven.
>
> > What's the overall usecase? You have a build with snapshots and you find
> > you need to go back to a release so you lock down to a previous release
> > and want to use that?
>
> The final distribution of our product or projects typically consists of
> hundreds of artifacts, where most of them have individual release cycles. In
> the HEAD revision those are linked in a nested directory structure using
> "builder POMs" i.e. POMs that have only modules declared, but get never
> released themselves (like the POM in the root of the example). The versions
> of the individual artifact are managed in a shared parent POM. In HEAD those
> are typically all snapshot versions.
>
> This changes after a major release of the overall product, then all those
> versions become final, the shared parent is released first followed by all
> other artifacts in dependency order using this released parent. This works
> all fine.
>
> Now we get into maintenance mode of that major release. Due to the
> independence of the artifacts we have to branch only the affected projects
> in case of bugs. Say we have JAR artifacts JAR-A to JAR-Z and we develop bug
> fixes for JAR-C and JAR-S. This means we branch the shared parent, set JAR-C
> and JAR-S to snapshot and also the artifacts that will assemble those to two
> jars, say WAR-X and DIST-ZIP. Then we create a builder for the maintenance
> branch that contains those jars, the war and the distribution zip as module.
> Building this we should get a war that contains JAR-C and JAR-S as snapshot
> and all the others as release and the distribution contains the affected
> WAR-X as snapshot and all other stuff as released version - the perfect
> situation to test the fix.
>
> Unfortunately M3 fails here, because it is under some circumstance not able
> to calculate the proper build order (maybe it does no longer take attached
> snapshot artifacts into account ?!?) and will either pack a stale snapshot
> from the local repository or fail, because the snapshot is built at a later
> time.
>
> > If you want to iteratively work on it together put it in a github repo.
>
> If you bear with me, may day-to-day work is with svn only and my learning
> curve with git/github is still steep, e.g. I did not know about gists, so I
> already learned something new.
>
> Cheers and thanks for your time,
> Jörg
>
>
>
> -
> 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

Re: The archetype/archetype-catalog mess

[Vincent Latombe]

+1

Vincent


2013/4/18 Olivier Lamy 

> sounds good idea.
> +1
>
> 2013/4/18 Anders Hammar :
> > Currently, maven-archetype-plugin ignores the configured Maven
> > infrastructure when fetching the archetype-catalog. That is, it is
> > hard-coded to get the catalog from central. This causes problems in
> > environments where Internet access is restricted and a MRM is used. Also,
> > in cases where Internet is accessible I think the current behavior where
> > configured repositories/mirrors are ignored is strange. I would expect my
> > Maven configuration to be honored and the catalog to downloaded from my
> > configured remote repos (incl. mirrors).
> >
> > Do anyone object if I do some drastic changes to this logic in the
> plugin?
> > I'm thinking that the plugin should follow the Maven configuration and
> not
> > have anything hard-coded in itself wrt where to get the archetype
> > catalog(s) from.
> > Related tickets are ARCHETYPE-427 and ARCHETYPE-358 primarily, but it
> > touches on other ones as well.
> >
> > /Anders
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: configuring maven profile to replace web.xml values

[Vincent Latombe]

Hi,
you should write to maven users mailing list us...@maven.apache.org. The
Maven Developers mailing list is meant to discuss maven development, not to
provide help to maven users.

Regards,

Vincent


2013/3/5 rr 

> I am trying to replace a attribute in my web.xml by using the maven
> replacer
> plugin but it seems to not be doing anything bec. when I look at my
> generated war file  the web.xml contains the orginal attribute that I had
> wanted to replace - I only want to replace it during a specific build
> profile - not for all my build profiles - can you please send me an example
> on how to  do it.
>
> currently I have:
> 
> prod
> 
>  //maven replacer plugin
> 
> 
>
>
> 
> //maven war plugin
> 
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/configuring-maven-profile-to-replace-web-xml-values-tp5749476.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MSITE-604 - Properties from settings.xml are not recognized in site distribution management

[Vincent Latombe]

Hi,

thank you for your feedback!

1) Several issues are actually interleaved, I believe the patch I propose
also fix MSITE-632, and maybe other related issues, I haven't reviewed them
all. Overall, the root cause seems to be that the parent is returned
without being interpolated (see my comment [1]).
2)3) I believe @...@ are replaced by maven-invoker-plugin before calling
the IT itself, so from the IT, this is an absolute path.

To sum up :
- a parent pom is declaring the site url (including protocol) in a property
that is provided *only* by settings.xml
- the parent pom's site is correctly built/deployed
- but, if you declare a child pom, it retrieves the site declaration from
parent, not interpolated, so the plugin will complain about the missing
protocol [2]

Vincent

[1]
http://jira.codehaus.org/browse/MSITE-604?focusedCommentId=296956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-296956
[2]
http://jira.codehaus.org/browse/MSITE-604?focusedCommentId=290463&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-290463


2012/10/30 Lukas Theussl 

> Hi,
>
> First: thanks for working on this!
>
> I have had a brief look and have a few comments:
>
> 1) your patch of IT MSITE-604 seems to address a different issue than
> the one originally described in the JIRA. If this is the case you
> should open a separate ticket.
>
> 2) I am wondering about the validity of the use case. You are putting
> the following property into a profile inside settings.xml:
>
> file://@project.build.directory@
> /it/MSITE-604/target/settingsRepositoryUrl
>
> However, the settings guide [1] states that only system and
> environment variables can be interpolated in settings.xml and
> furthermore, properties defined in profiles within the settings.xml
> cannot be used for interpolation at all.
>
> 3) Finally, the syntax @project.build.directory@ is known and used
> only by the invoker plugin (AFAIK) [2], the site plugin shouldn't be
> concerned with interpolating this. It is not clear to me how this
> would be relevant in a stand-alone project, maybe you can attach a
> small test project to reproduce the issue.
>
> I'd also appreciate the opinion of other devs with better
> property/interpolation knowledge, I confess I am confused by this
> issue...
>
> Cheers,
> -Lukas
>
>
> [1] http://maven.apache.org/settings.html
> [2]
> http://maven.apache.org/plugins/maven-invoker-plugin/examples/filtering.html
>
>
>
> On Mon, Oct 29, 2012 at 5:38 PM, Vincent Latombe
>  wrote:
> >
> > Hello,
> >
> > I think I have an acceptable IT + fix for this issue [1] (at least in
> Maven
> > 3 context), so I would be really grateful if someone with karma could
> take
> > a look at it and let me know about it :)
> >
> > Cheers,
> >
> > [1] http://jira.codehaus.org/browse/MSITE-604
> >
> > --
> > Vincent
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [incremental build] Detect leftovers from a previous build

[Vincent Latombe]

Hi,

the topic has been raised a long time ago, someone even wrote a plugin to
try to address this problem.
see http://maven-incremental-build.java.net/site/index.html

Vincent


2012/9/6 Romain Manni-Bucau 

> Ok so bad thread but the not stays valid. Triggering a clean is not a
> solution for me
> Le 6 sept. 2012 21:05, "Mark Struberg"  a écrit :
>
> > Hi Romain,
> >
> > Should have prefaced the baseline ;)
> >
> > I am now only focusing on plugin internal work inside a single maven pom
> > module. See bullet B. in [1]
> >
> > The Maven Reactor code will trigger a 'clean' on the whole module if it
> > detects an external dependency change / pom change / profile change /
> etc.
> > See bullet A. [1]
> >
> >
> > We are now really only focusing on the plugins itself as first step (aka
> > B.).
> >
> > LieGrue,
> > strub
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds
> >
> >
> > >
> > > From: Romain Manni-Bucau 
> > >To: Mark Struberg ; Maven Developers List <
> > dev@maven.apache.org>
> > >Sent: Thursday, September 6, 2012 8:59 PM
> > >Subject: Re: [incremental build] Detect leftovers from a previous build
> > >
> > >
> > >What about browsing the build tree to detect the dep modules which needs
> > to be built (avoid a real clean which can cost really too much to make
> incr
> > feature useful)? Can be done in parallel and can be pretty fast
> > >Le 6 sept. 2012 20:53, "Mark Struberg"  a écrit :
> > >
> > >
> > >>
> > >>Hi!
> > >>
> > >>I had some idea for detecting stale changes in maven which is pretty
> > generic
> > >>
> > >>
> > >>The problem hits us if you compile BeanA and BeanA2 in a project where
> > BeanA2 is using BeanA.
> > >>On a
> > >>
> > >>$> mvn clean compile
> > >>
> > >>you will get both BeanA.class and BeanA2.class in target/classes
> > >>Now delete BeanA.java
> > >>Currently (2.6-SNAPSHOT) the maven-compiler-plugin only compiles all
> > sources without doing any cleanup and thus BeanA.class will still remain
> in
> > target/classes.
> > >>
> > >>
> > >>That is clearly a bug as BeanA2 will be left broken, packaged into a
> > broken jar, ...
> > >>
> > >>
> > >>
> > >>How can we avoid that?
> > >>
> > >>Simple answer: A plugin which doesnt support those cases by the
> > underlying took (javac) must always first clean up the stuff it generated
> > during the last invocation.
> > >>
> > >>How can we do that?
> > >>
> > >>step 1: Start a DirectoryScanner and get all files in target/classes.
> > Remember this list!
> > >>
> > >>
> > >>step 2: Run the compiler
> > >>
> > >>
> > >>step 3: List all files in target/classes again and remove all files you
> > found in step 1. You will end up with a list of all files generated by
> the
> > compilation as result.
> > >>
> > >>step 4: Store this list into
> > target/maven-status/maven-compiler-plugin/default/createdfiles.lst
> > ('default' is the plugin execution. We need this in case we have multiple
> > ).
> > >>
> > >>
> > >>On the next compile you just need to check if you have such a
> > createdfiles.lst file and then first remove all the files listed in it as
> > step 0.
> > >>Then you can continue with step 1 from scratch.
> > >>
> > >>We could easily create a utility class for it which keeps the state
> with
> > methods
> > >>
> > >>public class ChangeDetector /* TODO find better name */
> > >>{
> > >>File[] readPreviouslyDetectedFileList(File targetFile);
> > >>void recordFiles(File baseDir)
> > >>File[] detectNewFiles();
> > >>storeDetectedFileList(File targetFile)
> > >>}
> > >>
> > >>This can e.g. also be used by the maven-resources-plugin to get rid of
> > copied resources which got deleted from src/main/resources.
> > >>
> > >>Do you have a better idea? Any ideas for improving this?
> > >>And a big question: how can I get hold of the current  id in
> > a plugin?
> > >>
> > >>
> > >>LieGrue,
> > >>strub
> > >>
> > >>-
> > >>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
> >
> >
>

discussion on MNG-4637 : -pl switch negates recursion into sub projects

[Vincent Latombe]

Hello,

I would be very interested to have [1] implemented. Our use case is to
compile a subpart of our aggregator + all associated dependencies. The
current behaviour requires us to provide *all* individual modules, which
defeats the purpose of aggregators.

I've made a patch proposal a while ago [2] but got so far no feedback
(positive or negative). I know that you don't monitor pull requests on GH
for Maven, but since in my company we start having serious needs for this,
I'd like to take the necessary steps for this to be integrated. I'm
guessing some ITs will be required, but I just want to know if the change
sounds like a reasonable one (given that is changing a bit the semantic of
the '-pl' option).

Thanks for your feedback,

Vincent

[1] http://jira.codehaus.org/browse/MNG-4637
[2] https://github.com/apache/maven-3/pull/2

Re: Preparing for two releases of Maven Site Plugin

[Vincent Latombe]

Hi Lukas,

I've proposed a second patch only affecting the site-plugin, which reuses
AbstractSiteMojo.isMaven3OrMore()

Vincent


2012/4/23 Lukas Theussl 

>
> AbstractSiteMojo.**isMaven3OrMore() is an example how to check if you're
> running maven 3. In any case, fixing this this would require a release of
> doxia-integration-tools-1.5. Or was that planned anyway?
>
> -Lukas
>
>
> Vincent Latombe wrote:
>
>> On my side, I really would like to see MSITE-604 fixed, I've given it some
>> thoughts today, and unfortunately I can only fix it for Maven 3, not for
>> Maven 2 (because of MNG-1943
>> <http://jira.codehaus.org/**browse/MNG-1943<http://jira.codehaus.org/browse/MNG-1943>>that
>> is only fixed with
>>
>> Maven 3). I've proposed a patch that is still work
>> in progress (since I don't know a clean way to detect from this context
>> whether we are in maven 2 or maven 3 context).
>>
>> Vincent
>>
>>
>> 2012/4/20 Lukas Theussl
>>
>>
>>> MSITE-601 is a wagon issue IIUC, the other issues can be delayed.
>>>
>>> Thanks Denis for doing this!
>>>
>>> -Lukas
>>>
>>>
>>>
>>> Robert Scholte wrote:
>>>
>>>  Hi Dennis,
>>>>
>>>> I don't see any blockers in Jira, only one critical (MSITE-601) but this
>>>> seems to be a rare case, so I'd prefer to push that one to a later
>>>> release too.
>>>> MSITE-582 is confirmed by Hervé, an IT has been added.
>>>>
>>>> I'd expect that the new Doxia versions should result in a very enhanced
>>>> version of the m-site-p.
>>>>
>>>> I don't see issues I'd like to pick up for this release.
>>>>
>>>> -Robert
>>>>
>>>> Op Wed, 18 Apr 2012 22:01:43 +0200 schreef Dennis Lundberg
>>>> :
>>>>
>>>>  Hi,
>>>>
>>>>>
>>>>> Now that the Doxia releases are done, I'd like to focus on Maven Site
>>>>> Plugin. We have two pending releases; 2.4 which will be the last
>>>>> release
>>>>> of the 2.x series and then 3.1.
>>>>>
>>>>> Looking in JIRA, all the issues scheduled for 2.4 have been fixed and
>>>>> closed. Does anyone want to add anything more to that release? If not,
>>>>> I'll prepare the 2.4 release this weekend.
>>>>>
>>>>> When we look at the 3.1 release in JIRA there are 5 scheduled issues
>>>>> that have not been solved. Here's a summary of them and how I'd like to
>>>>> handle them:
>>>>>
>>>>> MSITE-484 Support adding and overriding report plugins in new
>>>>> maven-site-plugin 3.x reportPlugins configuration format
>>>>> http://jira.codehaus.org/browse/MSITE-484<http://jira.codehaus.org/**browse/MSITE-484>
>>>>> <http://jira.**codehaus.org/browse/MSITE-484<http://jira.codehaus.org/browse/MSITE-484>
>>>>> >
>>>>>
>>>>> This is a major issue that might require changes to Maven core. Push it
>>>>> to later release.
>>>>>
>>>>> MSITE-582 Make it possible to remove breadcrumbs in child projects
>>>>> again
>>>>> http://jira.codehaus.org/browse/MSITE-582<http://jira.codehaus.org/**browse/MSITE-582>
>>>>> <http://jira.**codehaus.org/browse/MSITE-582<http://jira.codehaus.org/browse/MSITE-582>
>>>>> >
>>>>>
>>>>> Might already be solved.
>>>>>
>>>>> MSITE-596 inheritedReports IT fails
>>>>> http://jira.codehaus.org/browse/MSITE-596<http://jira.codehaus.org/**browse/MSITE-596>
>>>>> <http://jira.**codehaus.org/browse/MSITE-596<http://jira.codehaus.org/browse/MSITE-596>
>>>>> >
>>>>>
>>>>> Proposed solution requires changes to Maven core. Push to a later
>>>>> release, but document the current behavior as per Lukas' comment.
>>>>>
>>>>> MSITE-601 Period added to URL prevents proper cloning with Mercurial
>>>>> http://jira.codehaus.org/browse/MSITE-601<http://jira.codehaus.org/**browse/MSITE-601>
>>>>> <http://jira.**codehaus.org/browse/MSITE-601<http://jira.codehaus.org/browse/MSITE-601>
>>>>> >
>>>>>
>>>>> Unless someone 

Re: Preparing for two releases of Maven Site Plugin

[Vincent Latombe]

On my side, I really would like to see MSITE-604 fixed, I've given it some
thoughts today, and unfortunately I can only fix it for Maven 3, not for
Maven 2 (because of MNG-1943
that is only fixed with
Maven 3). I've proposed a patch that is still work
in progress (since I don't know a clean way to detect from this context
whether we are in maven 2 or maven 3 context).

Vincent


2012/4/20 Lukas Theussl 

>
> MSITE-601 is a wagon issue IIUC, the other issues can be delayed.
>
> Thanks Denis for doing this!
>
> -Lukas
>
>
>
> Robert Scholte wrote:
>
>> Hi Dennis,
>>
>> I don't see any blockers in Jira, only one critical (MSITE-601) but this
>> seems to be a rare case, so I'd prefer to push that one to a later
>> release too.
>> MSITE-582 is confirmed by Hervé, an IT has been added.
>>
>> I'd expect that the new Doxia versions should result in a very enhanced
>> version of the m-site-p.
>>
>> I don't see issues I'd like to pick up for this release.
>>
>> -Robert
>>
>> Op Wed, 18 Apr 2012 22:01:43 +0200 schreef Dennis Lundberg
>> :
>>
>>  Hi,
>>>
>>> Now that the Doxia releases are done, I'd like to focus on Maven Site
>>> Plugin. We have two pending releases; 2.4 which will be the last release
>>> of the 2.x series and then 3.1.
>>>
>>> Looking in JIRA, all the issues scheduled for 2.4 have been fixed and
>>> closed. Does anyone want to add anything more to that release? If not,
>>> I'll prepare the 2.4 release this weekend.
>>>
>>> When we look at the 3.1 release in JIRA there are 5 scheduled issues
>>> that have not been solved. Here's a summary of them and how I'd like to
>>> handle them:
>>>
>>> MSITE-484 Support adding and overriding report plugins in new
>>> maven-site-plugin 3.x reportPlugins configuration format
>>> http://jira.codehaus.org/**browse/MSITE-484
>>> This is a major issue that might require changes to Maven core. Push it
>>> to later release.
>>>
>>> MSITE-582 Make it possible to remove breadcrumbs in child projects again
>>> http://jira.codehaus.org/**browse/MSITE-582
>>> Might already be solved.
>>>
>>> MSITE-596 inheritedReports IT fails
>>> http://jira.codehaus.org/**browse/MSITE-596
>>> Proposed solution requires changes to Maven core. Push to a later
>>> release, but document the current behavior as per Lukas' comment.
>>>
>>> MSITE-601 Period added to URL prevents proper cloning with Mercurial
>>> http://jira.codehaus.org/**browse/MSITE-601
>>> Unless someone has a patch for it, I'd like to unschedule it.
>>>
>>> MSITE-604 Properties from settings.xml are not recognized in site
>>> distribution management
>>> http://jira.codehaus.org/**browse/MSITE-604
>>> This is strangely related to MSITE-632, but I cannot find a suitable
>>> solution to either of them. Push to a later release.
>>>
>>>
>>> Do we want to add any more issues to the 3.1 release?
>>>
>>>
>>> Please comment on this.
>>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@maven.apache.**org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@maven.apache.**org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

For a mojo with requiresProject=false, I would like to avoid Maven from loading the pom.xml from working directory

[Vincent Latombe]

Hello,

I'm coding a plugin where I can have a goal that is using requiresProject =
false, which I call directly from command line.

In some cases, this plugin can be called in a context where there is a
pom.xml in the working directory. The project itself may be invalid, but I
still would like to be able to execute the mojo.
Currently, Maven tries to parse the project and if it fails, it doesn't
even call my mojo. Is there any way to workaround this ?

I would be fine with a flag that would tell Maven to ignore the pom in the
current directory and call directly the mojo, but I don't believe it
currently exists.

Any clue?

Vincent

Re: Converting an Artifact (Aether) to MavenProject

[Vincent Latombe]

Hello,

once resolved, get the File using
org.sonatype.aether.artifact.Artifact#getFile

then use org.apache.maven.project.ProjectBuilder#build(File,
ProjectBuildingRequest) to get the MavenProject.

Vincent


2012/4/1 Asaf Mesika 

> Hi,
>
> I'm writing a Mojo, and I have a question:
>
> I have a piece of code which resolves an Aether Artifact based on its GAV
> string, from specific repository defined programmatic.
>
> Once I have the "org.sonatype.aether.artifact.Artifact"  at hand - how do I
> convert it to a MavenProject  or any other pojo which enables me to
> interrogate it's pom:
> Get a list of its dependencies and transitive dependencies, its SCM info,
> etc?
>
> It's worth noting my mojo is running with @requiresProject false
>
>
> Thanks!
>
> Asaf
>

Re: Functional distinction between install and deploy operations

[Vincent Latombe]

In my opinion you'll get more relevant answers on the Aether ML.

Vincent


2012/2/23 Chas Emerick 

> As I said, I'm building a Clojure library on top of Aether, so the notions
> of goals and lifecycles and plugins are nowhere to be found.
>
> By "'deploy' operation", I mean the operation implemented by e.g.
> RepositorySystem.deploy in Aether, or the same operation implemented in the
> maven-ant-tasks, or in whatever was the underpinning of Maven 2.x.
>  Likewise for "'install' operation".
>
> It seems odd to me that all of the responses so far have been referring to
> userland concepts, rather than the semantics of the fundamental operations
> implemented by those libraries/APIs...
>
> - Chas
>
> On Feb 23, 2012, at 8:24 AM, Thiessen, Todd (Todd) wrote:
>
> > Interesting thread, although I find it a big confusing.  Are you using
> the deploy goal, not lifecycle, to deploy artifacts to your local
> repository?  What do you mean by "'deploy' operation"?  Are you actually
> using the deploy plugin?
> >
> > Your comment about them not being documented well I also find a bit
> confusing. The deploy and install plugins are both documented quite well.
>  But I don't think you are referring to the plugin. I think you mean
> something else when you say "deploy operation".
> >
> >> -Original Message-
> >> From: Chas Emerick [mailto:c...@cemerick.com]
> >> Sent: Thursday, February 23, 2012 7:38 AM
> >> To: Maven Developers List
> >> Subject: Re: Functional distinction between install and deploy
> >> operations
> >>
> >>
> >> On Feb 23, 2012, at 1:01 AM, Chris Graham wrote:
> >>
> >>> Remember that 'deploy' still calls 'install'.
> >>
> >> Very true for `mvn`.  Not true in Aether; this would seem to be a
> >> userland tool convention, and not a fundamental characteristic of the
> >> 'deploy' operation.
> >>
> >> However, even Aether leaves some resolver-status and metadata files in
> >> the local repository after completing a 'deploy'...although I can't
> >> determine the significance of them.
> >>
> >> One thing I've discovered is that an installed SNAPSHOT will always
> >> take precedence over SNAPSHOTs from remote repositories, whereas this
> >> is not the case for SNAPSHOTs that are deployed to a local repository.
> >> So, there's one significant difference at least.
> >>
> >> It's unfortunate that the most fundamental things in Maven are
> >> essentially undocumented AFAICT: what 'deploy' and 'install' do, the
> >> various contents (and potential contents) of repositories in different
> >> contexts and their semantics, and so on.
> >>
> >> - Chas
> >> -
> >> 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
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Detecting current phase in a plugin

[Vincent Latombe]

Hello Carson,

you can achieve what you need by defining a new packaging, as described in
http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/

Vincent


2012/1/3 Carson Gross 

> Yes, it appears that I have a different mental model for plugins than Maven
> provides.  Let me explain what I'm trying to accomplish, and perhaps a
> better high-level approach is available:
>
> I work on Gosu (http://gosu-lang.org) a small language for the JVM.  Me
> and
> a few other guys are trying to get Gosu to play well with Maven.
>  Unfortunately for us, Gosu has a slightly different compilation model than
> Java: it is source based and lazily compiled, like many scripting
> languages.  We don't (currently) generate .class files, rather we compile
> and load them dynamically at runtime.
>
> Our goal with our Maven plugin is to make Gosu participate, as
> transparently as possible, with the various Maven phases, given that
> constraint.  Ideally, we would hook into the compile phase (the equivalent
> in Gosu would be to verify the source), the test phase (sounds like we the
> surefire API may make this easy/possible), etc.
>
> The way I was thinking about it, I'd prefer the user to not have to
> configure our plugin for any phases at all: I'd just want them to say
> something like this:
>
>  
>  
>org.gosu-lang
>maven-gosu-plugin
>1.0
>
>  0.9-SNAPSHOT
>
>  
>  
>
> And never have to mention phases or goals at all, and let the plugin wire
> itself in to the appropriate places to make gosu work.
>
> So that's what I'm trying to accomplish, and, as a total Maven noob, I'm
> happy to hear suggestions, clarifications of my language or other thoughts.
>
> Thanks,
> Carson
>
> On Tue, Jan 3, 2012 at 1:36 AM, Jochen Wiedmann
> wrote:
>
> > Sure you really want to do that? It would amount to hard wiring your
> > plugin to a certain phase, whereas
> > a plugin should typically be able to run in any phase, depending on the
> > POM.
> >
> >
> > On Tue, Jan 3, 2012 at 5:21 AM, Carson Gross 
> > wrote:
> > > I'd like to detect the current phase of a build within a plugin's
> > execute()
> > > method.  I dug around in the project object and plugin context, but
> > > couldn't find it.  Can anyone point me the right direction?
> > >
> > > Cheers,
> > > Carson
> >
> >
> >
> > --
> > "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja
> > Buchung."
> > Dieter Hildebrandt
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Creating an ear file from a combination of two other ears

[Vincent Latombe]

I'm having a similar requirement (kind of ear overlay feature). I agree with
sharing the dependencies, however you still have to repeat the ear
configuration (context-roots mappings etc.) if you have 2 different ears.

My use case is the following :
- for development we use an ear with a few wars
- for later phases (qa, prod...), we include extra wars (legacy stuff, no
development is done on it)

When I'm talking about *extra* wars, I mean about 50 wars so it is really an
overhead if we include them for development.

Ideally, in the production ear, I would declare a dependency to the
development ear, and add the extra wars. Ideally, the ear plugin would pick
up the application.xml from the ear dependency, and append the new wars
declared as dependencies.

Cheers,

Vincent

2010/10/25 Stephane Nicoll 

> Are the two others ears built with Maven as well? If so, I would try to
> share the dependencies between 1&2 and 3 somehow and rebuild the whole EAR
> instead of merging it.
>
> You could use something like the dependency plugin to unpack the dependency
> and excluding some files but there's nothing that will generate the
> application.xml for you. Looking at it from a distance, adding exclude on
> *files* is worse than trying to get a common dependency tree between your
> three projects.
>
> HTH,
> S.
>
> On Sun, Oct 24, 2010 at 4:21 PM, Varsha Hardikar
> wrote:
>
> > I am doing a project where I have to build an ear file (lets call it
> EAR3)
> > from a combination of two other ears (EAR1 and EAR2).
> >
> > EAR3  will have some libraries and war files that are copied from EAR1
> and
> > EAR2.
> > Additionally, I want to remove some jars from the libraries and war files
> > from EAR3 and generate a META-INF/application.xml and make changes to it.
> >
> > I was looking at two approaches 1) Maven assembly plugin 2) ant
> >
> > Has anyone done anything like this or guide me to what the best approach
> > would be.
> >
> >
> > Regards
> > Varsha
> >
> >
>

Re: [VOTE] Release Apache Maven 3.0-beta-3 (take 2)

[Vincent Latombe]

I opened http://jira.codehaus.org/browse/MNG-4786 . The test case comes
directly from the Maven book (see
http://www.sonatype.com/books/mhandbook/reference/ch04s04.html)

2010/8/31 Benjamin Bentmann 

> Vincent Latombe wrote:
>
>  I'm getting an NPE, calling a plugin that uses ant scripts
>> Caused by: java.lang.NullPointerException
>> at
>>
>> org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.java:126)
>> at
>>
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>>
>
> Please fill an issue with details and steps to reproduce so we can have a
> closer look.
>
>
> Benjamin
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Vincent

Re: [VOTE] Release Apache Maven 3.0-beta-3 (take 2)

[Vincent Latombe]

I'm getting an NPE, calling a plugin that uses ant scripts
Caused by: java.lang.NullPointerException
at
org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.java:126)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)

I had no problem with beta-2.

2010/8/31 Jeff Jensen 

> +1 (non-binding)
> "better, stronger, faster" :-)
>
>
> -Original Message-
> From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu]
> Sent: Monday, August 30, 2010 8:09 AM
> To: Maven Developers List
> Subject: [VOTE] Release Apache Maven 3.0-beta-3 (take 2)
>
> Hi,
>
> what's a better start for a week than a new fresh release :-) ? So here
> we go!
>
> Apart from another few regression fixes, this release includes Guice and
> Aether [0] and shall help to get some more community testing on these
> new components.
>
> Overall, we solved 19 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=166
> 81
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&sta
> tus=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-157/
>
> Staged source and binary distros:
>
> https://repository.apache.org/content/repositories/maven-157/org/apache/mave
> n/apache-maven/3.0-beta-3/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> +1 from me
>
>
> Benjamin
>
>
> [0] http://github.com/sonatype/sonatype-aether
>
> -
> 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
>
>


-- 
Vincent