RE: Self-Extracting Maven Plugin

[Edelson, Justin]

1) Put the binaries in src/main/resources. (make sure resource filtering isn't 
enabled)
2) Watch them get compiled into your plugin's JAR file.
3) use Class.getResourceAsStream() to get an InputStream to each binary.
4) copy the bytes from the InputStream to a FileOutputStream.
 
No need to use any part of the Maven API for this, although there is probably a 
utility class in plexus-utils that will handle step #4 for you.
 
Justin



From: Ian Graham [mailto:ian.gra...@citrix.com]
Sent: Mon 5/18/2009 6:57 PM
To: users@maven.apache.org
Subject: Self-Extracting Maven Plugin



Hello,
I'm working on a Maven Reporting plugin that depends on a set of binaries to do 
its work, but I haven't been able to find a way to package those binaries with 
my plugin, and extract them for use at runtime. Ideally, I'd like to store the 
binaries and some associated configuration files, etc. in the plugin's 
src/main/resources directory, and when the plugin is invoked, the binaries 
would be extracted to the output directory of whatever project is calling the 
plugin.

The obvious solution would be to include the plugin itself in the project's 
dependencies, and then use the maven-dependency-plugin to extract the binaries 
directly from the plugin jar. However, I need to be able to invoke the plugin 
without modifying the project's POM.

So far, I've tried the following:

- Create a separate package for the binaries, which the plugin includes as a 
runtime dependency. In the Plugin's POM, I configured the dependency plugin to 
extract the binary package, but when the plugin is invoked from a separate 
project, the package doesn't get extracted.

- Manually extract the contents of the plugin's .jar file as part of its own 
executeReport() method. This didn't work because the Artifact for my plugin as 
returned by MavenProject.getReportArtifacts() doesn't contain a reference to 
the actual jar file (Artifact.getFile() returns null). I also tried manually 
looking up the Artifact using an ArtifactFactory, but I can't see any way to 
properly construct an instance of or obtain a reference to an ArtifactFactory 
from within a plugin.

Is there a simple solution that I'm overlooking here? At this point, I'm out of 
ideas, and any help would be greatly appreciated!

Thanks,

--Ian


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

Re: How can one handle release candidates in Maven?

[sebb]

On 15/05/2009, sebb  wrote:
> On 14/05/2009, Brian Fox  wrote:
>  > On Thu, May 14, 2009 at 3:19 PM, Sahoo  wrote:
>  >
>  >  > Brian,
>  >  >
>  >  > Thanks for the excellent write up. In approach #2, when a build is done 
> by
>  >  > just replacing RC versions by actual versions, since new binaries are 
> going
>  >  > to be produced, don't they have to be tested again?
>  >
>  >
>  >
>  > Absolutely. However in the maven use case we don't need dozens of people
>  >  testing every possible permutation like we try to do during the RCs.
>  >  Assuming no code changed, we're really making sure that the binaries are 
> not
>  >  completely broken. Regardless, this is the build that we do the voting on 
> so
>  >  it does tend to have plenty of people using it before casting a vote.
>  >
>  >
>  >
>  >  > I understand since no source code is changed(only version is changing in
>  >  > pom.xmls), the chances of side effects are very low, but an organisation
>  >  > with stricter quality control processes in place won't allow bits to be
>  >  > released without them being tested. Once you involve testing, we are 
> back to
>  >  > square one, where we are not sure if the bits are final. Or, am I 
> missing
>  >  > anything?
>  >  >
>  >
>  >
>  > Nope, you are correct and I agree with that policy.
>  >
>  >  It's what we do at Sonatype as well as Maven.  When a release is staged to
>  >  Nexus, our QA thoroughly checks out that build. Those exact binaries are
>  >  what eventually get promoted assuming they pass.
>  >
>  >  I guess what I'm saying is that with the current maven release process, 
> you
>  >  don't run RC's exactly the same way you do the final release. You need to
>  >  rebuild it when you move from the RC to the release unfortunately, but you
>  >  do still test the final binaries before promoting it.

Sorry, one more question:

What happens if an error is found in the final binaries?
It's unlikely, but AFAICT it is not impossible.

>  >  This is exactly what
>  >  the Nexus staging is about, it lets you test the binaries before you 
> promote
>  >  it to your release repo, where it's too late to pull it back.
>  >
>
>
> Thanks for answering my question so thoroughly.
>
>
>  >
>  >  >
>  >  > Thanks,
>  >  > Sahoo
>  >  >
>  >  >
>  >  > Brian Fox wrote:
>  >  >
>  >  >> First, I'll acknowledge that it's not easy/possible to "promote" an
>  >  >> artifact
>  >  >> from one version to another - say 1.0-RC-10 to 1.0. Lets just accept 
> that
>  >  >> for now as it's a known issue that will be resolved down the road. Lets
>  >  >> instead discuss a few ways to work within those bounds, since 
> discussing
>  >  >> what "could be" doesn't help the issue now (which i believe this thread
>  >  >> derived from the discussion on commons-dev regarding a pending 
> release).
>  >  >> There are two approaches to this process, both are valid and I think 
> you
>  >  >> could pick one based on your requirements:
>  >  >>
>  >  >> The first is to append a build number to your version that is always
>  >  >> incremented. So instead of 1.0 you have 1.0-1 or 1.0-b1. You increment
>  >  >> this
>  >  >> forever until you have a release that is good and that's the one that
>  >  >> stays,
>  >  >> it could be 1.0-b10 or 1.0-500. I've used this approach before and it's
>  >  >> similar to what many commercial orgs do (if you look under the hood at 
> MS
>  >  >> versions for example, Vista SP1 is 6001.16659.070916-1443). In other
>  >  >> words,
>  >  >> the marketing for a release might be "1.0" but the actual version of 
> the
>  >  >> files might be 1.0-. This may be ok for things where the end 
> result is
>  >  >> a
>  >  >> war or ear but probably not as desirable for projects like commons that
>  >  >> release jars that are intended to be consumed.
>  >  >>
>  >  >>
>  >  >> The approach we use in the Maven project is slightly different. We 
> used to
>  >  >> stage versions like 2.0.8 over and over until we got it right. The
>  >  >> problems
>  >  >> with this approach where: 1) you need to rollback the tag and versions
>  >  >> every
>  >  >> time and 2) someone may have an artifact called 2.0.8 that was actually
>  >  >> not
>  >  >> the final 2.0.8. This was a bigger problem when we wanted to start 
> getting
>  >  >> maven-users involved to test the release candidates.
>  >  >>
>  >  >> We instead use the RC versions (eg 2.0.9-RC10) until we get to a 
> release
>  >  >> that we decide is ready to do. The versions are all staged on Nexus and
>  >  >> the
>  >  >> binaries are ditched each time we rebuild, but the tags stay in place.
>  >  >> Since
>  >  >> each release is uniquely versioned, we no longer have to revert the
>  >  >> versions
>  >  >> and we don't have to worry about someone having an RC and thinking 
> it's a
>  >  >> final release. Since it's not possible currently to promote an actual 
> RC
>  >  >> to
>  >  >> the final release (eg 2.0.9-RC10 to 2.0.9), we simply rebuild and 
> 

Self-Extracting Maven Plugin

[Ian Graham]

Hello,
I'm working on a Maven Reporting plugin that depends on a set of binaries to do 
its work, but I haven't been able to find a way to package those binaries with 
my plugin, and extract them for use at runtime. Ideally, I'd like to store the 
binaries and some associated configuration files, etc. in the plugin's 
src/main/resources directory, and when the plugin is invoked, the binaries 
would be extracted to the output directory of whatever project is calling the 
plugin. 

The obvious solution would be to include the plugin itself in the project's 
dependencies, and then use the maven-dependency-plugin to extract the binaries 
directly from the plugin jar. However, I need to be able to invoke the plugin 
without modifying the project's POM. 

So far, I've tried the following:

- Create a separate package for the binaries, which the plugin includes as a 
runtime dependency. In the Plugin's POM, I configured the dependency plugin to 
extract the binary package, but when the plugin is invoked from a separate 
project, the package doesn't get extracted. 

- Manually extract the contents of the plugin's .jar file as part of its own 
executeReport() method. This didn't work because the Artifact for my plugin as 
returned by MavenProject.getReportArtifacts() doesn't contain a reference to 
the actual jar file (Artifact.getFile() returns null). I also tried manually 
looking up the Artifact using an ArtifactFactory, but I can't see any way to 
properly construct an instance of or obtain a reference to an ArtifactFactory 
from within a plugin. 

Is there a simple solution that I'm overlooking here? At this point, I'm out of 
ideas, and any help would be greatly appreciated!

Thanks,

--Ian


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

RE: avoid oracle driver jar

[Martin Gainty]

something like...


  
  ear
  
ear
  
  false
  

  /

  
  

  /
  true
  runtime
  
commons-dbcp:commons-dbcp
com.oracle:ojdbc
  
 
   



Martin Gainty 
__ 
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und 
Vertraulichkeitanmerkung/Note de déni et de confidentialité
 Ez az
üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs.  Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




> Date: Mon, 18 May 2009 16:56:44 -0400
> Subject: avoid oracle driver jar
> From: fachh...@gmail.com
> To: users@maven.apache.org
> 
> I have maven project , which is jar, war and ear. Ear I deploy in weblogic ,
> and to save time I run war with jetty.
> 
> because my project uses datasource  , which is provided by weblogic and not
> by jetty  and  in order to run   in jetty
> I add the deopendency
> 
>   
>   commons-dbcp
>   commons-dbcp
>   1.2.2
>   compile
>   
> 
>   
>   com.oracle
>   ojdbc
>   14
>   compile
>   
> 
> and also created new file jetty-env.xml .
> 
> now I want to tell maven to exclude the above three  whenever ear is build ,
> becasue its for weblogic and i donto the them , please tell me how i can
> tell maven to avaoi above files and dependency ?

_
Insert movie times and more without leaving Hotmail®.
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009

Re: avoid oracle driver jar

[Fabien KRUBA]

You can may be try to define 2 profiles for your project:one for weblogic
without the jdbc driver and one for jetty with that dependency...

your profile can be activated by -P option on maven command line



On Mon, May 18, 2009 at 4:56 PM, tubin gen  wrote:

> I have maven project , which is jar, war and ear. Ear I deploy in weblogic
> ,
> and to save time I run war with jetty.
>
> because my project uses datasource  , which is provided by weblogic and not
> by jetty  and  in order to run   in jetty
> I add the deopendency
>
>  
>  commons-dbcp
>  commons-dbcp
>  1.2.2
>  compile
>  
>
>  
>  com.oracle
>  ojdbc
>  14
>  compile
>  
>
> and also created new file jetty-env.xml .
>
> now I want to tell maven to exclude the above three  whenever ear is build
> ,
> becasue its for weblogic and i donto the them , please tell me how i can
> tell maven to avaoi above files and dependency ?
>

Re: [PLEASE TEST] Maven 2.2.0-RC2

[Arnaud HERITIER]

No I'm not sure. I just supposed it was it.Sorry

Arnaud

On Mon, May 18, 2009 at 10:13 PM, John Casey  wrote:

> I just grepped the uberjar file listing in RC2 for 'ightweight' and came up
> with nothing. Are you sure the lightweight wagon is present in the copy you
> have?
>
>
> Arnaud HERITIER wrote:
>
>> I thought the wagon-lightweight was always here.It's with the 2.2.0-RC you
>> delivered.
>>
>> Arnaud
>>
>> On Mon, May 18, 2009 at 5:35 PM, John Casey 
>> wrote:
>>
>>  Arnaud, are you saying that you see something like:
>>>
>>> May 6, 2009 1:58:26 PM
>>> hidden.org.apache.commons.httpclient.HttpMethodBase
>>> processCookieHeaders
>>> WARNING: Cookie rejected: "$Version=0;
>>> JSESSIONID=E545E65FB5E46552ED8473D17DF1DC80; $Path=/servlets". Illegal
>>> path
>>> attribute "/servlets". Path of origin:
>>>
>>> "/nonav/repository//com.google.collections/jars/google-collections-0.9.jar"
>>>
>>> even when using the lightweight http wagon?
>>>
>>> Is that using 2.1.0, or did you roll your own Maven 2.2.0-* with
>>> wagon-lightweight reintroduced?
>>>
>>> -john
>>>
>>>
>>> Arnaud HERITIER wrote:
>>>
>>>  With the lightweight http wagon I have the issue NEXUS-1967 (rejected
 cookies) also for downloads.

 Arnaud

 On Fri, May 15, 2009 at 8:47 AM, Markku Saarela >>>
> wrote:
>
  Hi,

> Our release failed. There are two problems.
>
> Command line: mvn -Psome -Denv=some-dev release:perform -X
>
> 1. Command line -Psome profile activation is not working, at least
> prepare
> perform and rollback goals.
> [WARNING]
> Profile with id: 'some' has not been activated.
>
> 2. release:perform failed for some weird -f option
>
> [INFO] Failed to re-parse additional arguments for Maven invocation.
>
> Unrecognized option: -f
> [INFO]
>
> 
> [DEBUG] Trace
>
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> re-parse
> additional arguments for
> Maven invocation.
> at
>
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
> .java:703)
> at
>
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycl
> eExecutor.java:553)
> at
>
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
> java:523)
> at
>
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
> ifecycleExecutor.java:371)
> at
>
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
> xecutor.java:268)
> at
>
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
> :181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
> re-parse additional arguments f
> or Maven invocation.
> at
>
>
> org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:133)
> at
>
>
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
>
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
> .java:678)
> ... 16 more
> Caused by: org.apache.maven.shared.release.ReleaseExecutionException:
> Failed to re-parse additional
> arguments for Maven invocation.
> at
>
>
> org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase
> .java:89)
> at
>
>
> org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute(RunPerformGoalsPhase.j
> ava:67)
> at
>
>
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
> 336)
> at
>
>
> org.apache.maven.shar

avoid oracle driver jar

[tubin gen]

I have maven project , which is jar, war and ear. Ear I deploy in weblogic ,
and to save time I run war with jetty.

because my project uses datasource  , which is provided by weblogic and not
by jetty  and  in order to run   in jetty
I add the deopendency

  
  commons-dbcp
  commons-dbcp
  1.2.2
  compile
  

  
  com.oracle
  ojdbc
  14
  compile
  

and also created new file jetty-env.xml .

now I want to tell maven to exclude the above three  whenever ear is build ,
becasue its for weblogic and i donto the them , please tell me how i can
tell maven to avaoi above files and dependency ?

Re: [PLEASE TEST] Maven 2.2.0-RC2

[John Casey]

I just grepped the uberjar file listing in RC2 for 'ightweight' and came 
up with nothing. Are you sure the lightweight wagon is present in the 
copy you have?


Arnaud HERITIER wrote:

I thought the wagon-lightweight was always here.It's with the 2.2.0-RC you
delivered.

Arnaud

On Mon, May 18, 2009 at 5:35 PM, John Casey  wrote:


Arnaud, are you saying that you see something like:

May 6, 2009 1:58:26 PM hidden.org.apache.commons.httpclient.HttpMethodBase
processCookieHeaders
WARNING: Cookie rejected: "$Version=0;
JSESSIONID=E545E65FB5E46552ED8473D17DF1DC80; $Path=/servlets". Illegal path
attribute "/servlets". Path of origin:
"/nonav/repository//com.google.collections/jars/google-collections-0.9.jar"

even when using the lightweight http wagon?

Is that using 2.1.0, or did you roll your own Maven 2.2.0-* with
wagon-lightweight reintroduced?

-john


Arnaud HERITIER wrote:


With the lightweight http wagon I have the issue NEXUS-1967 (rejected
cookies) also for downloads.

Arnaud

On Fri, May 15, 2009 at 8:47 AM, Markku Saarela 
wrote:

 Hi,

Our release failed. There are two problems.

Command line: mvn -Psome -Denv=some-dev release:perform -X

1. Command line -Psome profile activation is not working, at least
prepare
perform and rollback goals.
[WARNING]
 Profile with id: 'some' has not been activated.

2. release:perform failed for some weird -f option

[INFO] Failed to re-parse additional arguments for Maven invocation.

Unrecognized option: -f
[INFO]

[DEBUG] Trace

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
re-parse
additional arguments for
Maven invocation.
 at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:703)
 at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycl
eExecutor.java:553)
 at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
java:523)
 at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
ifecycleExecutor.java:371)
 at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
xecutor.java:268)
 at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
:181)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
re-parse additional arguments f
or Maven invocation.
 at

org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:133)
 at

org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
 at

org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:678)
 ... 16 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException:
Failed to re-parse additional
arguments for Maven invocation.
 at

org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase
.java:89)
 at

org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute(RunPerformGoalsPhase.j
ava:67)
 at

org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
336)
 at

org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
282)
 at

org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
262)
 at

org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:129)
 ... 18 more
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException:
Failed to re-parse additiona
l arguments for Maven invocation.
 at

org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecut
or.java:335)
 at

org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecut
or.java:377)
 at

org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecut
or.java:413)
 at

org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase
.java:81)
 ... 23 more
Caused 

Re: Anyone have a plugin to check if the surefire tests pass?

[Jeffrey N Hagelberg]

We've got one.  It uses the SurefireReportParser from the
maven-surefire-report-plugin to parse the reports.  I'll have to get
permission from my manager to send it, but that's the basic idea.

-Jeff

Jeffrey Hagelberg, Software Engineer
XMeta Development
IBM Software Group
Phone: 978-899-2055 T/L:276-2055)
Email:jnhag...@us.ibm.com


   
  From:   Kalle Korhonen   
   
  To: Maven Users List 
   
  Date:   05/18/2009 04:00 PM  
   
  Subject:Re: Anyone have a plugin to check if the surefire tests pass?
   





Why don't you just write a unit test base class that runs Jetty embedded?
If
you store the server in a static attribute and start it in @BeforeClass (or
similar) conditionally if hasn't been started before, you'll save the
restart costs between each test. As a bonus, these integration tests are
easily runnable from your IDE. This is exactly what I do.

Kalle


On Mon, May 18, 2009 at 9:16 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hey, before you think this guy is crazy, surefire will do that for you...
>
> pre-integration-test: jetty:run daemon=true
> integration-test: surefire:test testFailureIgnore=true
> post-integration-test: jetty:stop
> verify: __:__
>
> so that I can run my integration tests and tidy-up afterwards and then
fail
> the build after the tidy-up...
>
> yes, yes, yes I know about putting the tests in a separate module and all
> that jazz... but this is in some ways a bit cleaner
>
> -Stephen
>

Re: Anyone have a plugin to check if the surefire tests pass?

[Kalle Korhonen]

Why don't you just write a unit test base class that runs Jetty embedded? If
you store the server in a static attribute and start it in @BeforeClass (or
similar) conditionally if hasn't been started before, you'll save the
restart costs between each test. As a bonus, these integration tests are
easily runnable from your IDE. This is exactly what I do.

Kalle


On Mon, May 18, 2009 at 9:16 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hey, before you think this guy is crazy, surefire will do that for you...
>
> pre-integration-test: jetty:run daemon=true
> integration-test: surefire:test testFailureIgnore=true
> post-integration-test: jetty:stop
> verify: __:__
>
> so that I can run my integration tests and tidy-up afterwards and then fail
> the build after the tidy-up...
>
> yes, yes, yes I know about putting the tests in a separate module and all
> that jazz... but this is in some ways a bit cleaner
>
> -Stephen
>

Custom Lifecycle

[Jeffrey N Hagelberg]

Hello,

We are trying to define a custom lifecycle for our nightly build.  We 
basically want it to have the following phases:

1.  run-build
2.  process-build-results
3.  report-build-results

The idea is that we will have a separate nightly build maven project that 
runs the nightly build.  In "run-build", we would use the maven invoker 
plugin to run "mvn deploy" on another project.  In "process-build-results" 
we would parse the test results and put them in format suitable for 
emailing.  In "report-build-results" we would send out an email with the 
test results and generate and deploy the maven site.

I've tried doing this by creating a lifecycle.xml and components.xml in my 
nightly build plugin and enabling extensions for the plugin in my nightly 
build project.  However, it does not seem to be working.  It seems like I 
must be missing something, but I'm not sure what it is.

Do you have any idea what it might be? 

I really could not find much documentation on how to create a custom 
lifecycle.  I tried to follow what's in 
http://www.sonatype.com/books/maven-book/reference/writing-plugins-sect-custom-lifecycle.html
.

I've attached watered-down versions of the projects for the plugin and the 
nightly build, including their pom.xml files and the lifecycle.xml and 
components.xml. 

The error I am seeing is:


>mvn com.ibm.mmi:mmi-nightly-build-plugin:nightly-build

[INFO] Scanning for projects...
[INFO] 

[INFO] Building nightly_build
[INFO]task-segment: 
[com.ibm.mmi:mmi-nightly-build-plugin:nightly-build]
[INFO] 

[INFO] Preparing mmi-nightly-build:nightly-build
[INFO] 

[ERROR] BUILD FAILURE
[INFO] 

[INFO] Unable to find lifecycle for phase 'report-build-results'
[INFO] 

[INFO] For more information, run Maven with the -e switch
[INFO] 

[INFO] Total time: 1 second
[INFO] Finished at: Mon May 18 15:18:43 EDT 2009
[INFO] Final Memory: 4M/20M
[INFO] 


Stack trace:

[INFO] Trace
org.apache.maven.BuildFailureException: Unable to find lifecycle for phase 
'repo
rt-build-results'
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleForPh
ase(DefaultLifecycleExecutor.java:1185)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecy
cle(DefaultLifecycleExecutor.java:1028)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(Def
aultLifecycleExecutor.java:1009)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:627)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
Goal(DefaultLifecycleExecutor.java:553)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:523)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:371)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:332)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)

We're using maven 2.1.0 with Java 1.5.0

Thanks for any help you can provide.



Jeffrey Hagelberg, Software Engineer
XMeta Development
IBM Software Group
Phone: 978-899-2055 T/L:276-2055)
Email:jnhag...@us.ibm.com

Re: Anyone have a plugin to check if the surefire tests pass?

[Brian Fox]

Use one of the enforcer rules or make a new one to validate the conditionss.

On Mon, May 18, 2009 at 2:59 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> nope.
>
> that will stop trying to build the current module but continue with the
> next module... I don't want the current module to stop after
> integration-test but after verify
>
> I have a sneaky feeling I'm going to have to write a plugin to do this
>
> but seriously, my use case has got to have been faced by somebody else
> already
>
> Sent from my [rhymes with myPod] ;-)
>
>
> On 18 May 2009, at 18:31, "Edelson, Justin" 
> wrote:
>
>  Can you use -fae to do this?
>>
>> On May 18, 2009, at 12:17 PM, "Stephen Connolly" <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>  Hey, before you think this guy is crazy, surefire will do that for you...
>>>
>>> pre-integration-test: jetty:run daemon=true
>>> integration-test: surefire:test testFailureIgnore=true
>>> post-integration-test: jetty:stop
>>> verify: __:__
>>>
>>> so that I can run my integration tests and tidy-up afterwards and then
>>> fail
>>> the build after the tidy-up...
>>>
>>> yes, yes, yes I know about putting the tests in a separate module and all
>>> that jazz... but this is in some ways a bit cleaner
>>>
>>> -Stephen
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven: The Definitive Guide in French

[Arnaud HERITIER]

I think you can create a google group to discuss in french.I'll join it,
even if I don't think I'll have the time  to help you before september.

Arnaud

On Mon, May 18, 2009 at 7:17 PM, Fabien KRUBA wrote:

> Same here, but it could be a good starting point to learn it:)Should we
> create a mailing list in order to manage the translation with you and
> Baptiste and avoiding pollution of us...@maven mailing list with french
> text
> ? Already have some questions regarding translation coherence..(which terms
> should we use, should we translate technical words etc..)
>
> Fabien.
>
> On Mon, May 18, 2009 at 1:13 PM, Emmanuel Hugonnet  >wrote:
>
> > You will have to be indulgent my git skills are very low :o(
> > Ma "maitrise" de git est au niveau débutant alors faut pas trop m'en
> > demander :o(
> > Emmanuel
> >
>



-- 
Arnaud

Re: Anyone have a plugin to check if the surefire tests pass?

[Stephen Connolly]

nope.

that will stop trying to build the current module but continue with  
the next module... I don't want the current module to stop after  
integration-test but after verify


I have a sneaky feeling I'm going to have to write a plugin to do this

but seriously, my use case has got to have been faced by somebody else  
already


Sent from my [rhymes with myPod] ;-)

On 18 May 2009, at 18:31, "Edelson, Justin"  
 wrote:



Can you use -fae to do this?

On May 18, 2009, at 12:17 PM, "Stephen Connolly" > wrote:


Hey, before you think this guy is crazy, surefire will do that for  
you...


pre-integration-test: jetty:run daemon=true
integration-test: surefire:test testFailureIgnore=true
post-integration-test: jetty:stop
verify: __:__

so that I can run my integration tests and tidy-up afterwards and  
then fail

the build after the tidy-up...

yes, yes, yes I know about putting the tests in a separate module  
and all

that jazz... but this is in some ways a bit cleaner

-Stephen


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



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

Re: Anyone have a plugin to check if the surefire tests pass?

[Edelson, Justin]

Can you use -fae to do this?

On May 18, 2009, at 12:17 PM, "Stephen Connolly" > wrote:


Hey, before you think this guy is crazy, surefire will do that for  
you...


pre-integration-test: jetty:run daemon=true
integration-test: surefire:test testFailureIgnore=true
post-integration-test: jetty:stop
verify: __:__

so that I can run my integration tests and tidy-up afterwards and  
then fail

the build after the tidy-up...

yes, yes, yes I know about putting the tests in a separate module  
and all

that jazz... but this is in some ways a bit cleaner

-Stephen


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

Re: Have maven stop compilation when some rule is broken

[Brian Fox]

The maven-enforcer-plugin is well suited for this. You could use one of the
existing rules, perhaps the failIfFileExists or easily write your own rule.

On Mon, May 18, 2009 at 12:47 PM, bgik  wrote:

>
> Hi
> I have a 3rd party lib that i have no control over.
>
> In my env it makes no sense to create 2 instances of a given class from
> this
> lib, in fact it may cause issues, so i have updated my codebase to wrap one
> in a singleton. Going forward there's nothing to stop anyone creating
> another one though.
>
> What i would like is for
>
> mvn compile
>
> to actually fail even though my code is syntactically correct if it
> encounters any attempt to create a 2nd instance of this class.
>
> Is there a way to do this? I presume I could write some plugin but i'd like
> to avoid that if possible as time is short
>
> many thanks
> --
> View this message in context:
> http://www.nabble.com/Have-maven-stop-compilation-when-some-rule-is-broken-tp23601222p23601222.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Release plugin checking remote dependencies for modules

[Brian Fox]

Because it's making sure that the build is correct, it's basic snapshot
behavior.

On Mon, May 18, 2009 at 12:53 PM, Danilo Tuler wrote:

> >> I have a multi-module project with a dozen modules.
> >> Whenever I do a "maven release:prepare" maven checks remotely for
> >> SNAPSHOT dependencies of my own modules, instead of first checking the
> >> reactor.
>
> > You can speed this up by creating a repository group [virtual
> > repository] and configuring Maven to only use the one url.
>
> Our version of archiva (1.0.2) does not support virtual repositories.
> We plan to upgrade ASAP.
>
> But why does maven do that?
>
> Danilo
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven: The Definitive Guide in French

[Fabien KRUBA]

Same here, but it could be a good starting point to learn it:)Should we
create a mailing list in order to manage the translation with you and
Baptiste and avoiding pollution of us...@maven mailing list with french text
? Already have some questions regarding translation coherence..(which terms
should we use, should we translate technical words etc..)

Fabien.

On Mon, May 18, 2009 at 1:13 PM, Emmanuel Hugonnet wrote:

> You will have to be indulgent my git skills are very low :o(
> Ma "maitrise" de git est au niveau débutant alors faut pas trop m'en
> demander :o(
> Emmanuel
>

Re: Maven: The Definitive Guide in French

[Emmanuel Hugonnet]

You will have to be indulgent my git skills are very low :o(
Ma "maitrise" de git est au niveau débutant alors faut pas trop m'en
demander :o(
Emmanuel

Re: Release plugin checking remote dependencies for modules

[Danilo Tuler]

>> I have a multi-module project with a dozen modules.
>> Whenever I do a "maven release:prepare" maven checks remotely for
>> SNAPSHOT dependencies of my own modules, instead of first checking the
>> reactor.

> You can speed this up by creating a repository group [virtual
> repository] and configuring Maven to only use the one url.

Our version of archiva (1.0.2) does not support virtual repositories.
We plan to upgrade ASAP.

But why does maven do that?

Danilo

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

Have maven stop compilation when some rule is broken

[bgik]

Hi
I have a 3rd party lib that i have no control over.

In my env it makes no sense to create 2 instances of a given class from this
lib, in fact it may cause issues, so i have updated my codebase to wrap one
in a singleton. Going forward there's nothing to stop anyone creating
another one though.

What i would like is for 

mvn compile

to actually fail even though my code is syntactically correct if it
encounters any attempt to create a 2nd instance of this class.

Is there a way to do this? I presume I could write some plugin but i'd like
to avoid that if possible as time is short

many thanks
-- 
View this message in context: 
http://www.nabble.com/Have-maven-stop-compilation-when-some-rule-is-broken-tp23601222p23601222.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Release plugin checking remote dependencies for modules

[Wendy Smoak]

On Mon, May 18, 2009 at 6:07 AM, Danilo Tuler  wrote:

> I use archiva and have a lot of remote repositories, and because of
> that the release takes an hour or so.

You can speed this up by creating a repository group [virtual
repository] and configuring Maven to only use the one url.

-- 
Wendy

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

Re: Release plugin checking remote dependencies for modules

[Brian Fox]

That's normal unless you disable automatic snapshot updates for each of
these repos in your settings.

On Mon, May 18, 2009 at 9:07 AM, Danilo Tuler  wrote:

> Hi,
>
> I have a multi-module project with a dozen modules.
> Whenever I do a "maven release:prepare" maven checks remotely for
> SNAPSHOT dependencies of my own modules, instead of first checking the
> reactor.
> Is this correct?
>
> I use archiva and have a lot of remote repositories, and because of
> that the release takes an hour or so.
> My modules does not define version themselves, but define the versioned
> parent.
> The inter module dependencies are defined as ${version} instead of
> sticking the version.
> I'm using maven 2.1.0.
>
> Thanks,
> Danilo
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: mvn deploy puts snapshots into releases directory

[Brian Fox]

Yours looks right.

On Sun, May 17, 2009 at 8:15 PM, Reiner Saddey  wrote:

>
>
> BRIAN FOX-5 wrote:
> >
> > Paste the output of help:effective-pom
> >
> > On Sun, May 17, 2009 at 2:09 PM, Reiner Saddey  wrote:
> >
> >>
> >>
> >> Jan Torben Heuer-5 wrote:
> >> >
> >> > Hi,
> >> >
> >> > When I deploy my artifact (version 1.0-SNAPSHOT), maven puts it in the
> >> > /releases directory although I set up both, repository and
> >> > snapshotrepository in the parent pom
> >> > ...
> >> >
> >>
> >> Hi Jan,
> >>
> >> are you sure - or are you using Apache Archiva (1.2)?
> >>
> >> Using Maven 2.1.0, after having deployed a snapshot pom to an Archiva
> >> repository, I thought that Maven had failed (just as you described).
> >>
> >> However, the artifact has indeed correctly been saved to my snapshots
> >> repository, BUT within its GUI (and just there), Archiva would "lie" and
> >> state the wrong (releases) repository.
> >
>
> Hi Brian,
> yep, gladly. Mine looks rather dull though, maybe Jan's more interesting.
> Regards,
> Reiner
>
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
> 
> [INFO] Building Elegate Root Parent Project
> [INFO]task-segment: [help:effective-pom] (aggregator-style)
> [INFO]
> 
> [INFO] [help:effective-pom]
> [INFO]
> Effective POMs, after inheritance, interpolation, and profiles are applied:
>
> 
> 
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>  4.0.0
>  com.elegate
>  root-parent
>  1.0-SNAPSHOT
>  pom
>  Elegate Root Parent Project
>  Elegate, the Mobile Link.
>  http://www.elegate.com/
>  2009
>  
>Elegate GmbH
>http://www.elegate.com/
>  
>  
>
>  Elegate propriatary software.
>  http://www.elegate.com/licenses/
>  repo
>
>  
>  
>
> scm:svn:
> http://vcgsvn.carano.de/svn/2008_Elegate/Projekte/maven/pom/trunk/root-parent
> 
>
> scm:svn:
> http://vcgsvn.carano.de/svn/2008_Elegate/Projekte/maven/pom/trunk/root-parent
> 
>
> 
> http://vcgsvn.carano.de/trac/elegate/browser/Projekte/maven/pom/trunk/root-parent
> 
>  
>  
>C:\Dokumente und Einstellungen\rsa\Eigene
> Dateien\NetBeansProjects\root-parent\src\main\java
>src/main/scripts
>C:\Dokumente und Einstellungen\rsa\Eigene
> Dateien\NetBeansProjects\root-parent\src\test\java
>C:\Dokumente und Einstellungen\rsa\Eigene
> Dateien\NetBeansProjects\root-parent\target\classes
>C:\Dokumente und Einstellungen\rsa\Eigene
>
> Dateien\NetBeansProjects\root-parent\target\test-classes
>
>  
>resource-0
>C:\Dokumente und Einstellungen\rsa\Eigene
> Dateien\NetBeansProjects\root-parent\src\main\resources
>  
>
>
>  
>resource-1
>C:\Dokumente und Einstellungen\rsa\Eigene
> Dateien\NetBeansProjects\root-parent\src\test\resources
>  
>
>C:\Dokumente und Einstellungen\rsa\Eigene
> Dateien\NetBeansProjects\root-parent\target
>root-parent-1.0-SNAPSHOT
>
>  
>
>  maven-antrun-plugin
>  1.3
>
>
>  maven-assembly-plugin
>  2.2-beta-2
>
>
>  maven-clean-plugin
>  2.2
>
>
>  maven-compiler-plugin
>  2.0.2
>  
>UTF-8
>  
>
>
>  maven-dependency-plugin
>  2.0
>
>
>  maven-deploy-plugin
>  2.4
>
>
>  maven-ear-plugin
>  2.3.1
>
>
>  maven-ejb-plugin
>  2.1
>
>
>  maven-install-plugin
>  2.2
>
>
>  maven-jar-plugin
>  2.2
>
>
>  maven-javadoc-plugin
>  2.5
>
>
>  maven-plugin-plugin
>  2.4.3
>
>
>  maven-rar-plugin
>  2.2
>
>
>  maven-release-plugin
>  2.0-beta-8
>
>
>  maven-resources-plugin
>  2.3
>  
>UTF-8
>  
>
>
>  maven-site-plugin
>  2.0-beta-7
>
>
>  maven-source-plugin
>  2.0.4
>
>
>  maven-surefire-plugin
>  2.4.3
>
>
>  maven-war-plugin
>  2.1-alpha-2
>
>  
>
>
>  
>maven-help-plugin
>2.1
>  
>
>  
>  
>
>  elegate-releases
>  Elegate Maven2 Releases
>
> 
> http://vcgdevelegate.carano.de:8889/archiva/repository/elegate-releases
> 
>
>
>  elegate-snapshots
>  Elegate Maven2 Snapshots
>
> 
> http://vcgdevelegate.carano.de:8889/ar

Anyone have a plugin to check if the surefire tests pass?

[Stephen Connolly]

Hey, before you think this guy is crazy, surefire will do that for you...

pre-integration-test: jetty:run daemon=true
integration-test: surefire:test testFailureIgnore=true
post-integration-test: jetty:stop
verify: __:__

so that I can run my integration tests and tidy-up afterwards and then fail
the build after the tidy-up...

yes, yes, yes I know about putting the tests in a separate module and all
that jazz... but this is in some ways a bit cleaner

-Stephen

Re: [PLEASE TEST] Maven 2.2.0-RC2

[Arnaud HERITIER]

I thought the wagon-lightweight was always here.It's with the 2.2.0-RC you
delivered.

Arnaud

On Mon, May 18, 2009 at 5:35 PM, John Casey  wrote:

> Arnaud, are you saying that you see something like:
>
> May 6, 2009 1:58:26 PM hidden.org.apache.commons.httpclient.HttpMethodBase
> processCookieHeaders
> WARNING: Cookie rejected: "$Version=0;
> JSESSIONID=E545E65FB5E46552ED8473D17DF1DC80; $Path=/servlets". Illegal path
> attribute "/servlets". Path of origin:
> "/nonav/repository//com.google.collections/jars/google-collections-0.9.jar"
>
> even when using the lightweight http wagon?
>
> Is that using 2.1.0, or did you roll your own Maven 2.2.0-* with
> wagon-lightweight reintroduced?
>
> -john
>
>
> Arnaud HERITIER wrote:
>
>> With the lightweight http wagon I have the issue NEXUS-1967 (rejected
>> cookies) also for downloads.
>>
>> Arnaud
>>
>> On Fri, May 15, 2009 at 8:47 AM, Markku Saarela > >wrote:
>>
>>  Hi,
>>>
>>> Our release failed. There are two problems.
>>>
>>> Command line: mvn -Psome -Denv=some-dev release:perform -X
>>>
>>> 1. Command line -Psome profile activation is not working, at least
>>> prepare
>>> perform and rollback goals.
>>> [WARNING]
>>>  Profile with id: 'some' has not been activated.
>>>
>>> 2. release:perform failed for some weird -f option
>>>
>>> [INFO] Failed to re-parse additional arguments for Maven invocation.
>>>
>>> Unrecognized option: -f
>>> [INFO]
>>> 
>>> [DEBUG] Trace
>>>
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>>> re-parse
>>> additional arguments for
>>> Maven invocation.
>>>  at
>>>
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
>>> .java:703)
>>>  at
>>>
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycl
>>> eExecutor.java:553)
>>>  at
>>>
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
>>> java:523)
>>>  at
>>>
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
>>> ifecycleExecutor.java:371)
>>>  at
>>>
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
>>> xecutor.java:268)
>>>  at
>>>
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
>>> :181)
>>>  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
>>>  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
>>>  at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
>>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>  at
>>>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>  at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>  at java.lang.reflect.Method.invoke(Method.java:597)
>>>  at
>>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>>>  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>>>  at
>>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>>>  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>>> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
>>> re-parse additional arguments f
>>> or Maven invocation.
>>>  at
>>>
>>> org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:133)
>>>  at
>>>
>>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
>>>  at
>>>
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
>>> .java:678)
>>>  ... 16 more
>>> Caused by: org.apache.maven.shared.release.ReleaseExecutionException:
>>> Failed to re-parse additional
>>> arguments for Maven invocation.
>>>  at
>>>
>>> org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase
>>> .java:89)
>>>  at
>>>
>>> org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute(RunPerformGoalsPhase.j
>>> ava:67)
>>>  at
>>>
>>> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
>>> 336)
>>>  at
>>>
>>> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
>>> 282)
>>>  at
>>>
>>> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
>>> 262)
>>>  at
>>>
>>> org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:129)
>>>  ... 18 more
>>> Caused by: org.apache.maven.shared.release.exec.MavenExecutorException:
>>> Failed to re-parse additiona
>>> l arguments for Maven invocation.
>>>  at
>>>
>>> org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecut
>>> or.java:335)
>>>  at
>>>
>>> org.apache.maven.shared.release.exec.Invoker

Re: [PLEASE TEST] Maven 2.2.0-RC2

[John Casey]

Arnaud, are you saying that you see something like:

May 6, 2009 1:58:26 PM 
hidden.org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; 
JSESSIONID=E545E65FB5E46552ED8473D17DF1DC80; $Path=/servlets". Illegal 
path attribute "/servlets". Path of origin: 
"/nonav/repository//com.google.collections/jars/google-collections-0.9.jar"


even when using the lightweight http wagon?

Is that using 2.1.0, or did you roll your own Maven 2.2.0-* with 
wagon-lightweight reintroduced?


-john

Arnaud HERITIER wrote:

With the lightweight http wagon I have the issue NEXUS-1967 (rejected
cookies) also for downloads.

Arnaud

On Fri, May 15, 2009 at 8:47 AM, Markku Saarela wrote:


Hi,

Our release failed. There are two problems.

Command line: mvn -Psome -Denv=some-dev release:perform -X

1. Command line -Psome profile activation is not working, at least prepare
perform and rollback goals.
[WARNING]
  Profile with id: 'some' has not been activated.

2. release:perform failed for some weird -f option

[INFO] Failed to re-parse additional arguments for Maven invocation.

Unrecognized option: -f
[INFO]

[DEBUG] Trace

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to re-parse
additional arguments for
Maven invocation.
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:703)
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycl
eExecutor.java:553)
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
java:523)
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
ifecycleExecutor.java:371)
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
xecutor.java:268)
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
:181)
  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
  at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
  at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
re-parse additional arguments f
or Maven invocation.
  at
org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:133)
  at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:678)
  ... 16 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException:
Failed to re-parse additional
arguments for Maven invocation.
  at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase
.java:89)
  at
org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute(RunPerformGoalsPhase.j
ava:67)
  at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
336)
  at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
282)
  at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:
262)
  at
org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:129)
  ... 18 more
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException:
Failed to re-parse additiona
l arguments for Maven invocation.
  at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecut
or.java:335)
  at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecut
or.java:377)
  at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecut
or.java:413)
  at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase
.java:81)
  ... 23 more
Caused by: org.apache.commons.cli.UnrecognizedOptionException: Unrecognized
option: -f
  at org.apache.commons.cli.Parser.processOption(Parser.java:363)
  at org.apache.commons.cli.Parser.parse(Parser.java:199)
  at org.apache.commons.cli.Parser.parse(Parser.java:85)
  at
org.apache.maven.shared.release.exe

Re: Error while trying to generate the site

[Lukas Theussl]

http://jira.codehaus.org/browse/MPIR-142

HTH,
-Lukas

HHB wrote:

Hey,
I get the following exception when trying mvn site
++
[INFO] Generating "Dependencies" report.
[WARNING] Unable to process class
com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class in JarAnalyzer File
/home/hhb/.m2/repository/com/ibm/icu/icu4j/2.6.1/icu4j-2.6.1.jar
org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant
pool: 60
at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146)
at org.apache.bcel.classfile.ConstantPool.(ConstantPool.java:67)
at
org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222)
at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136)
at
org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze(JarClassesAnalysis.java:92)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:286)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1389)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:533)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
at 
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
++
The project is supposed to use PMD, FindBugs and Cobertura


org.codehaus.mojo
findbugs-maven-plugin
2.0.1
test


org.codehaus.mojo
cobertura-maven-plugin
2.2
test


org.codehaus.mojo
findbugs-maven-plugin
2.0.1
test


My platform is Ubuntu 8.10 , JDK 6 update 10
Thanks.


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

Replacing file from project1.jar with file from project2

[Stephan Bauer]

Hi,

I have 2 projects: project1 and project2 whereby project2 shall replace a java 
class file from project1.jar with a file available in project2. Is there a 
standard way (or a workaround) to achieve this? (suppose project1 is opensource 
and project2 makes "closed-source" additions to project1). BTW, I would be able 
to change the pom.xml of both projects if necessary.

Many thanks in advance,
Stephan


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

Error while trying to generate the site

[HHB]

Hey,
I get the following exception when trying mvn site
++
[INFO] Generating "Dependencies" report.
[WARNING] Unable to process class
com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class in JarAnalyzer File
/home/hhb/.m2/repository/com/ibm/icu/icu4j/2.6.1/icu4j-2.6.1.jar
org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant
pool: 60
at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146)
at org.apache.bcel.classfile.ConstantPool.(ConstantPool.java:67)
at
org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222)
at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136)
at
org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze(JarClassesAnalysis.java:92)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:286)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1389)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:533)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
at 
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
++
The project is supposed to use PMD, FindBugs and Cobertura


org.codehaus.mojo
findbugs-maven-plugin
2.0.1
test


org.codehaus.mojo
cobertura-maven-plugin
2.2
test


org.codehaus.mojo
findbugs-maven-plugin
2.0.1
test


My platform is Ubuntu 8.10 , JDK 6 update 10
Thanks.
-- 
View this message in context: 
http://www.nabble.com/Error-while-trying-to-generate-the-site-tp23596070p23596070.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Maven: The Definitive Guide in French

[Baptiste MATHUS]

Ouaip, ça m'intéresse aussi. Va bien falloir que je me mette à Git :-).

About git, I always remember Linus torvalds being asked why he
named it "git". He answered "I'm an egotistical bastard, and I name all my
projects after myself." :-).

Cheers.

2009/5/18 Fabien KRUBA 

> Hi
> I can give some help for translation
> Regards
> Fabien Kruba
>
> On Mon, May 18, 2009 at 3:58 AM, Emmanuel Hugonnet  >wrote:
>
> > Hi,
> > I have started the French Translation for the Maven Guide here:
> > http://github.com/ehsavoie/maven-guide/tree/master
> > Feel free to contact me if you want to help :o) (reading, translating,
> > ...).
> >
> > Emmanuel
> >
> > PS: I am currently translating the introduction chapter.
> >
> > --
> > Emmanuel Hugonnet
> > Tel: +336.25.34.19.46
> > http://www.ehsavoie.com
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Maven: The Definitive Guide in French

[Fabien KRUBA]

Hi
I can give some help for translation
Regards
Fabien Kruba

On Mon, May 18, 2009 at 3:58 AM, Emmanuel Hugonnet wrote:

> Hi,
> I have started the French Translation for the Maven Guide here:
> http://github.com/ehsavoie/maven-guide/tree/master
> Feel free to contact me if you want to help :o) (reading, translating,
> ...).
>
> Emmanuel
>
> PS: I am currently translating the introduction chapter.
>
> --
> Emmanuel Hugonnet
> Tel: +336.25.34.19.46
> http://www.ehsavoie.com
>

Re: SNAPSHOT for parent pom versioning

[Anders Hammar]

Could it be an Artifactory bug? What's the content of the
maven-metadata.xml file of the
seta.config:seta-general-configuration:1.0-SNAPSHOT artifact?

On Mon, May 18, 2009 at 09:24, Bocalinda  wrote:
> Hi Anders,
>
> Thanks a lot.. You are right, I need to specifically specify to update on
> each build.
> When I do so, I can see from Maven's output that it's trying to download my
> POM again, but it actually isn't.
> The POM changed in the remote repository, but it remained the same local
> repository. I'm guessing this is a problem with my remote repository not
> telling Maven that the file has changed.
>
> Just in case it would be useful in some way, here is the Maven output:
>
> [INFO] Scanning for projects...
> [DEBUG] Searching for parent-POM:
> seta.config:seta-general-configuration:pom:1.0-SNAPSHOT of project:
> derivacion:Derivacion:pom:1.0
>  in relative path: ../pom.xml
> [DEBUG] Parent-POM: seta.config:seta-general-configuration:pom:1.0-SNAPSHOT
> not found in relative path: ../pom.xml
> [DEBUG] Retrieving parent-POM:
> seta.config:seta-general-configuration:pom:1.0-SNAPSHOT for project:
> derivacion:Derivacion:pom:1.0 f
> rom the repository.
> [INFO] snapshot seta.config:seta-general-configuration:1.0-SNAPSHOT:
> checking for updates from releases
> [DEBUG] Checking for pre-existing User-Agent configuration.
> [DEBUG] Adding User-Agent configuration.
> [DEBUG] Connecting to repository: 'releases' with url: '
> http://172.18.0.78:/artifactory/releases/
> '.
> [DEBUG] Skipping disabled repository central
> [DEBUG] seta-general-configuration: using locally installed snapshot
> [DEBUG] Trying repository releases
> [DEBUG] Checking for pre-existing User-Agent configuration.
> [DEBUG] Adding User-Agent configuration.
> [DEBUG] Connecting to repository: 'releases' with url: '
> http://172.18.0.78:/artifactory/releases/
> '.
> Downloading:
> http://172.18.0.78:/artifactory/sadiel-releases//seta/config/seta-general-configuration/1.0-SNAPSHOT/seta-general-configuration-1.0
> -SNAPSHOT.pom
> [DEBUG]   Artifact resolved
>
> It says "Downloading" but it didn't actually download anything.
>
> 2009/5/15 Anders Hammar 
>
>> I think SNAPSHOTs are only updated once a day or so, not for every
>> build. You can force it through "mvn -U" or by settings updatePolicy
>> in your settings.xml:
>>
>> http://maven.apache.org/ref/2.0.8/maven-settings/settings.html#class_releases
>>
>> Here's a blog about this:
>>
>> http://jlorenzen.blogspot.com/2008/07/maven-not-downloading-latest-snapshots.html
>>
>> /Anders
>>
>> On Fri, May 15, 2009 at 12:14, Bocalinda  wrote:
>> > Hi List,
>> >
>> > According to the documentation, when specifying a version as -SNAPSHOT,
>> > Maven downloads the artifact on each build.
>> >
>> > I specify:
>> >
>> >  
>> >    config
>> >    seta-general-configuration
>> >    1.0-SNAPSHOT
>> >  
>> >
>> > and expected Maven to download the parent pom again from the repository,
>> > however, this doesn't seem to be the case.
>> > Is this a bug, or is it not supported?
>> >
>> > I manage the parent pom, which is used in many different projects. The
>> > problem is that I am not the developer of all those projects, so if I
>> would
>> > change something in the parent pom, then I have no control over whether
>> > people are updating the parant pom version in order to fetch te latest
>> > version. It would be much easier if I could leave it as SNAPSHOT, and
>> have
>> > Maven download it each time a build is executed.
>> >
>> > I'm using Maven 2.1.0.
>> >
>> > Thanks.
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

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

Release plugin checking remote dependencies for modules

[Danilo Tuler]

Hi,

I have a multi-module project with a dozen modules.
Whenever I do a "maven release:prepare" maven checks remotely for
SNAPSHOT dependencies of my own modules, instead of first checking the
reactor.
Is this correct?

I use archiva and have a lot of remote repositories, and because of
that the release takes an hour or so.
My modules does not define version themselves, but define the versioned parent.
The inter module dependencies are defined as ${version} instead of
sticking the version.
I'm using maven 2.1.0.

Thanks,
Danilo

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

Re: Error transferring file: repo1.maven.org, Repository 'central' will be blacklisted

[Andrea Libero Valori]

Solved: it was only that I was giving wrong names for archetypes! ;)
PS sorry for the late reply

Re: Maven: The Definitive Guide in French

[Emmanuel Hugonnet]

Hi,
I have started the French Translation for the Maven Guide here:
http://github.com/ehsavoie/maven-guide/tree/master
Feel free to contact me if you want to help :o) (reading, translating, ...).

Emmanuel

PS: I am currently translating the introduction chapter.

--
Emmanuel Hugonnet
Tel: +336.25.34.19.46
http://www.ehsavoie.com

Re: SNAPSHOT for parent pom versioning

[Bocalinda]

Hi Anders,

Thanks a lot.. You are right, I need to specifically specify to update on
each build.
When I do so, I can see from Maven's output that it's trying to download my
POM again, but it actually isn't.
The POM changed in the remote repository, but it remained the same local
repository. I'm guessing this is a problem with my remote repository not
telling Maven that the file has changed.

Just in case it would be useful in some way, here is the Maven output:

[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM:
seta.config:seta-general-configuration:pom:1.0-SNAPSHOT of project:
derivacion:Derivacion:pom:1.0
 in relative path: ../pom.xml
[DEBUG] Parent-POM: seta.config:seta-general-configuration:pom:1.0-SNAPSHOT
not found in relative path: ../pom.xml
[DEBUG] Retrieving parent-POM:
seta.config:seta-general-configuration:pom:1.0-SNAPSHOT for project:
derivacion:Derivacion:pom:1.0 f
rom the repository.
[INFO] snapshot seta.config:seta-general-configuration:1.0-SNAPSHOT:
checking for updates from releases
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] Connecting to repository: 'releases' with url: '
http://172.18.0.78:/artifactory/releases/
'.
[DEBUG] Skipping disabled repository central
[DEBUG] seta-general-configuration: using locally installed snapshot
[DEBUG] Trying repository releases
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] Connecting to repository: 'releases' with url: '
http://172.18.0.78:/artifactory/releases/
'.
Downloading:
http://172.18.0.78:/artifactory/sadiel-releases//seta/config/seta-general-configuration/1.0-SNAPSHOT/seta-general-configuration-1.0
-SNAPSHOT.pom
[DEBUG]   Artifact resolved

It says "Downloading" but it didn't actually download anything.

2009/5/15 Anders Hammar 

> I think SNAPSHOTs are only updated once a day or so, not for every
> build. You can force it through "mvn -U" or by settings updatePolicy
> in your settings.xml:
>
> http://maven.apache.org/ref/2.0.8/maven-settings/settings.html#class_releases
>
> Here's a blog about this:
>
> http://jlorenzen.blogspot.com/2008/07/maven-not-downloading-latest-snapshots.html
>
> /Anders
>
> On Fri, May 15, 2009 at 12:14, Bocalinda  wrote:
> > Hi List,
> >
> > According to the documentation, when specifying a version as -SNAPSHOT,
> > Maven downloads the artifact on each build.
> >
> > I specify:
> >
> >  
> >config
> >seta-general-configuration
> >1.0-SNAPSHOT
> >  
> >
> > and expected Maven to download the parent pom again from the repository,
> > however, this doesn't seem to be the case.
> > Is this a bug, or is it not supported?
> >
> > I manage the parent pom, which is used in many different projects. The
> > problem is that I am not the developer of all those projects, so if I
> would
> > change something in the parent pom, then I have no control over whether
> > people are updating the parant pom version in order to fetch te latest
> > version. It would be much easier if I could leave it as SNAPSHOT, and
> have
> > Maven download it each time a build is executed.
> >
> > I'm using Maven 2.1.0.
> >
> > Thanks.
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>