Assembly and repository resolution

[Randall Fidler]

Hello,

 

 Looked into an issue I've encountered with assembly not using
snapshots correctly.  I believe it's due to Maven 3.0.3 restricting
libraries to "configured" repositories only, but not sure why the
assembly plugin doesn't have the repository in question "configured" for
use.

 

I've basically got...

 

A

|--B  <-- assembly is run from here (mvn package
assembly:assembly -Dmaven.test.skip=true)

   |

   -C

   -D

 

 

E

 

Assembly puts all the sub projects artifacts into a zip file with some
organization, fairly simple.  Projects C, D require project E, which is
listed as 3.1.0.0_b1-SNAPSHOT as a dependency.  During compile, running
tests, etc, project E is downloaded from our repo (we use Artifactory)
and all is well.  When the assembly pukes, it says that it cannot find
project E version 3.1.0.0_b1-SNAPSHOT and yet the dependency is in the
local .m2.  I have the following repositories setup in the project A pom
file:

 





central

http://build.x.com:8080/artifactory/repo



false







snapshots

http://build.x.com:8080/artifactory/repo



false







 

 

Like I said, if I remove the artifact and try to run assembly, it will
download the file (for package goal) but then say it can't find it for
assembly.  It did suggest to mvn install the file, which I did and to my
surprise assembly then worked.  Looking further into it, it appears that
"local repo tracking" feature that's new to Maven 3.0.3 that's causing
the issue.  For the project E artifact, I noticed when I deleted it from
local .m2 and did a mvn install, it created a _maven.repositories file
that did NOT specify the repository (assembly worked fine with this).
So to be clear, when I did mvn install I get a _maven.repository file
with E-3.1.0.0_b1-SNAPSHOT.jar>= and when assembly fails, that same file
will have E-3.1.0.0_b1-SNAPSHOT.jar>snapshots= and I do understand why
it has snapshots listed as "normally" it downloads the artfact from our
artifactory repo which, according to repositories entries (above) is
called snapshots.

 

What I don't understand here is why doesn't the assembly plugin think
it's ok for it to use artifacts from the snapshots repository?

 

So to recap...

 

If I remove project E from local .m2, manually install project E
artifact, assembly works fine (no maven repository is associated with
project E artifact in local .m2).

 

If I remove project E from local .m2, project E artifact is downloaded
from repo and assembly fails.  Project E is listed as coming from
snapshots repository.

 

Repository scope issue somehow between main build "context" and
assembly?

 

Sugestions?  Thoughts?

 

Thanks

 

Randall

Assembly not picking up snapshots

[Randall Fidler]

Hello,

 

I've got an assembly that runs at the parent level for a
multi-module project.  Let me preface by saying this setup works fine
with Maven 2.x, going to Maven 3.0.3 the issue appeared.  Anyhow, we
have dependency and if we have it set to a snapshot the package goal
runs fine but assembly complains that it cannot find the artifact.  It's
on the local .m2 store, it's on the repo (we use Artifactory).  In the
setup we have two repos, one for releases and one for snapshots, one
thing I thought was interesting is that when Maven fails saying can't
find the artifact, it only lists the "release" repo in it's error
message and not both release and snapshot repos.   I did a -X run and
dug through the debug, it does see both the release and snapshot repos
yet the error only references release repo... ?

 

Again, this same setup works fine with Maven 2.x.  Just for giggles I
updated to the latest revision of assembly plugin but that gave no joy.
I have been running "mvn package assembly:assembly
-Dmaven.tests.skip=true" but also tried using "mvn package
assembly:single -Dmaven.test.skip=true" - no change.

 

What I don't get is when it's compiling/packaging it's able to find the
dependency (which is something like X-1.0.0_b0-SNAPSHOT.jar) but when it
tries to do the assembly... BARF.  Does assembly only work with
releases?  If so, that stinks... how do you do nightly snapshot builds?

 

Any suggestions / pointers are greatly appreciated.

 

Regards,

 

Randall

DecoderException

[Randall Fidler]

Hello,

 

   Has anybody seen an issue when using release plugin (release:peform)
via Maven2 on XP it not being able to find
org.apache.commons.codec.DecoderException while trying to generate
JavaDoc?  I had javadoc setup under reporting and tried removing that
but it still creates it hits this.  I thought using -Dgoal=deploy for
release:perform would get it to skip site generation but it appears to
do that as well.  I'm totally fine to either resolve the issue and have
it crank out JavaDoc or just skip JavaDoc creation entirely at this
point.

 

More of the stacktrace is below but any insight or clues is greatly
appreciated!!

 

Thanks

 

Randall

 

java.lang.NoClassDefFoundError:
org/apache/commons/codec/DecoderExceptio

n

at
org.apache.commons.httpclient.HttpMethodBase.(HttpMetho

dBase.java:220)

at
org.apache.commons.httpclient.methods.GetMethod.(GetMet

hod.java:89)

at
org.apache.maven.plugin.javadoc.JavadocUtil.fetchURL(JavadocU

til.java:797)

at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.isValidJa

vadocLink(AbstractJavadocMojo.java:5539)

at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.addLinkAr

guments(AbstractJavadocMojo.java:3852)

at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.addStanda

rdDocletOptions(AbstractJavadocMojo.java:4617)

at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeRe

port(AbstractJavadocMojo.java:1919)

at
org.apache.maven.plugin.javadoc.JavadocReport.generate(Javado

cReport.java:124)

at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDo

cument(ReportDocumentRenderer.java:139)

at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.rende

rModule(DefaultSiteRenderer.java:269)

at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.rende

r(DefaultSiteRenderer.java:101)

at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.

java:133)

at
org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:

100)

at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(Defa

ultPluginManager.java:490)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGo

als(DefaultLifecycleExecutor.java:694)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGo

alWithLifecycle(DefaultLifecycleExecutor.java:556)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGo

al(DefaultLifecycleExecutor.java:535)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGo

alAndHandleFailures(DefaultLifecycleExecutor.java:387)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTa

skSegments(DefaultLifecycleExecutor.java:348)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(D

efaultLifecycleExecutor.java:180)

at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328

)

at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)

at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMai

n.java:60)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)

RE: Release dependency fails (2.0.9 vs 2.2.1)

[Randall Fidler]

Jorg,

Direct reference in Child_B dependency section to Child_A.

Thanks!

-Randall

-Original Message-
From: Jörg Schaible [mailto:joerg.schai...@gmx.de] 
Sent: Wednesday, April 28, 2010 12:11 PM
To: users@maven.apache.org
Subject: Re: Release dependency fails (2.0.9 vs 2.2.1)

Hi Randall,

Randall Fidler wrote:

> Hello,
> 
>  
> 
> Using Maven 2.2.1, release:perform seems to break in that it cannot
> find a dependency.  I switch back to using Maven 2.0.9 and all is well.
> Simple example...
> 
>  
> 
> Parent pom  (1.0.0.0_b0-snapshot)
> 
> |
> 
> | Child A (1.0.0.0_b0-snapshot)
> 
> | Child B (1.0.0.0_b0-snapshot)   <-- has a dependency to child
> A 1.0.0.0_b0-snapshot
> 
>  
> 
> With 2.0.9, can release b0 (mvn clean, release:prepare, release:perform
> on parent) and Child B is updated to depend on Child A 1.0.0.0_b0 and
> all is well - release is complete.
> 
>  
> 
> When I update to Maven 2.2.1, Child A 1.0.0.0_b1 is "built" (it's in the
> target dir) but Child_B complains that it cannot find the dependency.  I
> do have the pom locked down to use version 2.0 beta 7 of the release
> plugin so I'm going to try taking off that "lockdown" and see what I get
> with Maven 2.2.1.
> 
>  
> 
> Anybody else experience release plugin problems of this nature with
> 2.2.x?

I remember to run into similar problems, however, it was already from 2.0.9 
to 2.0.10 ... or so ;-)

How do you reference ChildA in ChildB? Version inherited from depMgmt of 
parent? Own depMgmt in ChildB? Direct version in depepndencies section of 
ChildB? Indirect version definition with properties soemwhere?

- Jörg


-
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 dependency fails (2.0.9 vs 2.2.1)

[Randall Fidler]

Hello,

 

Using Maven 2.2.1, release:perform seems to break in that it cannot
find a dependency.  I switch back to using Maven 2.0.9 and all is well.
Simple example...

 

Parent pom  (1.0.0.0_b0-snapshot)

|

| Child A (1.0.0.0_b0-snapshot)

| Child B (1.0.0.0_b0-snapshot)   <-- has a dependency to child
A 1.0.0.0_b0-snapshot

 

With 2.0.9, can release b0 (mvn clean, release:prepare, release:perform
on parent) and Child B is updated to depend on Child A 1.0.0.0_b0 and
all is well - release is complete.

 

When I update to Maven 2.2.1, Child A 1.0.0.0_b1 is "built" (it's in the
target dir) but Child_B complains that it cannot find the dependency.  I
do have the pom locked down to use version 2.0 beta 7 of the release
plugin so I'm going to try taking off that "lockdown" and see what I get
with Maven 2.2.1.

 

Anybody else experience release plugin problems of this nature with
2.2.x?

 

Thanks!

 

Randall

RE: Test fail for release:perform only - no failure info

[Randall Fidler]

Finally!  As suspected... it was some stupid trivial item.  I'm posting this 
just so the thread on the mail archive will be complete.

Effectively what was causing the issue was some of surefire reports got checked 
into the scm under the target directory {project}/target/surefire-reports.  
This is what caused surefire via release plugin to fail on the perform goal and 
not the prepare goal.  Reason being is that prepare runs a clean (and I usually 
run mvn clean release:prepare anyhow) as it's first step.  When the release 
goal was running, it would check out the entire project again to 
{project}/target/checkout/ in which those same surefire reports that were in 
the scm, would be placed into 
{project}/target/checkout/target/surefire-reports.  As a consequence, the 
surefire plugin would bomb on perform and not prepare (because prepare deleted 
them via it's own clean execution). Perform would does not run a clean so when 
it checked out the entire project again, the reports were in the target 
directory which throws surefire for a loop.

I wish surefire would give you more information, such as it had a problem with 
a report file already existing, that would have saved SO much time, oh well.

Lesson learned: Make sure you don't check anything into your projects target 
directory on your SCM, IT'S NOT A GOOD IDEA! ;)


Regards,

Randall

-Original Message-
From: Randall Fidler [mailto:randall.fid...@testadvantage.com] 
Sent: Monday, March 15, 2010 1:32 PM
To: Maven Users List
Subject: RE: Test fail for release:perform only - no failure info

Wayne,

One issue... how do you get the "maven.surefire.debug" option to the 
surefire plugin since it's running via the release plugin?  For instance, if I 
try to tell it just to skip tests, (i.e. -Dmaven.test.skip=true) it won't 
because the release plugin has it's own surefire config (I'm guessing).  So 
even if I want to debug it using Eclipse to attach to the test jvm, I don't see 
how can I get that parameter to the surefire instance that the release plugin 
is firing up.  I'll try anyhow, but think this will be a problem.

Regards,

Randall

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Monday, March 15, 2010 1:14 PM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info

>    I read somewhere that you can hook a debugger to the surefire plugin,
> is that what you're talking about?  I believe that plugin has a parameter
> that tells it to wait until the "debugger" has connected and then it proceeds
> to run the tests.

Googling "maven surefire debugger" brought the proper results to the
top... give it a try. ;-)

Wayne

-
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


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

RE: Test fail for release:perform only - no failure info

[Randall Fidler]

Wayne,

One issue... how do you get the "maven.surefire.debug" option to the 
surefire plugin since it's running via the release plugin?  For instance, if I 
try to tell it just to skip tests, (i.e. -Dmaven.test.skip=true) it won't 
because the release plugin has it's own surefire config (I'm guessing).  So 
even if I want to debug it using Eclipse to attach to the test jvm, I don't see 
how can I get that parameter to the surefire instance that the release plugin 
is firing up.  I'll try anyhow, but think this will be a problem.

Regards,

Randall

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Monday, March 15, 2010 1:14 PM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info

>    I read somewhere that you can hook a debugger to the surefire plugin,
> is that what you're talking about?  I believe that plugin has a parameter
> that tells it to wait until the "debugger" has connected and then it proceeds
> to run the tests.

Googling "maven surefire debugger" brought the proper results to the
top... give it a try. ;-)

Wayne

-
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: Test fail for release:perform only - no failure info

[Randall Fidler]

Thank you, I appreciate it.  I'll let ya know what I find.

Regards,

Randall

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Monday, March 15, 2010 1:14 PM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info

>    I read somewhere that you can hook a debugger to the surefire plugin,
> is that what you're talking about?  I believe that plugin has a parameter
> that tells it to wait until the "debugger" has connected and then it proceeds
> to run the tests.

Googling "maven surefire debugger" brought the proper results to the
top... give it a try. ;-)

Wayne

-
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: Test fail for release:perform only - no failure info

[Randall Fidler]

Wayne,

I read somewhere that you can hook a debugger to the surefire plugin, is 
that what you're talking about?  I believe that plugin has a parameter that 
tells it to wait until the "debugger" has connected and then it proceeds to run 
the tests.

Can you give me suggestions on setup/environment to do that?  Thanks for your 
help by the way.

Regards,

Randall


-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Monday, March 15, 2010 11:26 AM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info

> It seems like the surefire 'thread' is just bailing out.  One other
> thing to note just to be complete, I also tried running with Java 1.6
> (thinking maybe somebody else put a 1.6 specific test case in the
> project) but it gets the same result as using 1.5.

You may need to bundle things up into something you can share
(assuming this is even possible) that has the problem so others can
take a look at it. Otherwise you'll need to get it into a runtime
debugger and see where things go wrong yourself.

Wayne

-
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: Test fail for release:perform only - no failure info

[Randall Fidler]

Wayne,

All the test reports/output show no errors - all the test reports who
each test passing.  I spent the time and went through each one, there
are no errors.

I had one test which required line arguments to be set to increase the
amount of memory and set the perm size (the one thing that seems to have
changed since release:perform last worked).  I removed that test and the
line arguments from the surefire configuration, same result.

It seems like the surefire 'thread' is just bailing out.  One other
thing to note just to be complete, I also tried running with Java 1.6
(thinking maybe somebody else put a 1.6 specific test case in the
project) but it gets the same result as using 1.5.

Regards,

Randall

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Monday, March 15, 2010 10:29 AM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info

> [INFO] Please refer to D:\Project\Code\Library\x_3.0.0\target\c
> heckout\target\surefire-reports for the individual test results.

Any info here that might help?

Wayne

-
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: Test fail for release:perform only - no failure info

[Randall Fidler]

Hello,

  Still can't get this bugger to work.  I've locked down the version of the 
surefire plugin to the latest (2.5), using Maven 2.2.1 and found a thread 
(http://jira.codehaus.org/browse/MRELEASE-140) thinking that perhaps something 
with the site plugin might be screwing up the release:perform so I tried taking 
out anything site related (site plugin config, etc) - but still no luck.

Just to recap...

Mvn test works fine, mvn release:prepare works fine (all tests pass)

Tests fail with mvn release:perform, except there aren't any test failures!

[INFO] Running com.x.exception.XExceptionTest
[INFO] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
[INFO] [INFO] --
--
[INFO] [ERROR] BUILD FAILURE
[INFO] [INFO] --
--
[INFO] [INFO] There are test failures.
[INFO]
[INFO] Please refer to D:\Project\Code\Library\x_3.0.0\target\c
heckout\target\surefire-reports for the individual test results.
[INFO] [INFO] --
--
[INFO] [INFO] For more information, run Maven with the -e switch
[INFO] [INFO] --
--
[INFO] [INFO] Total time: 10 seconds
[INFO] [INFO] Finished at: Mon Mar 15 10:14:29 MST 2010
[INFO] [INFO] Final Memory: 20M/39M
[INFO] [INFO] --
--
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Maven execution failed, exit code: '1'

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 46 seconds

You can see from above that the build fails, but there are no summary stats, 
such as "Tests: 506  Failures: 17   Errors:7", it's as if the surefire plugin 
just stopped.

Failure seemed to occur with one particular test, I removed that test and the 
problem just moved to another test, so doensn't appear to be test dependent.

Tried using Windows/Linux machines (just to ensure it wasn't something machine 
dependent), still no joy.

I also tried changing surefire forkmode to pretest, but that didn't change 
anything.

This project normally takes more than 10m to run, notice the total time is 1m 
46s, some something is very screwy, just can't figure out what changed.  This 
same project was running release:perform fine with Maven 2.0.9 a few months ago 
(this same project does get the same error with Maven 2.0.9, btw... I only 
upgraded to 2.2.1 to try and resolve this issue).

Any suggestions/insight is greatly appreciated.

Thanks!

Randall

-Original Message-
From: Randall Fidler [mailto:randall.fid...@testadvantage.com] 
Sent: Friday, March 12, 2010 10:37 AM
To: Maven Users List
Subject: RE: Test fail for release:perform only - no failure info

Hmm... just tried with Maven 2.2.1 and surefire plugin vesion 2.5.  Still none 
of the tests are failing but the build fails because there are test errors.  I 
thought it was one particular test, but I removed it from the project and same 
result.  All tests pass on release:prepare but I get the "build failed due to 
test failures with no failing tests" when I do release:perform.

Ideas?

Thanks!

Randall

-Original Message-
From: Randall Fidler [mailto:randall.fid...@testadvantage.com] 
Sent: Thursday, March 11, 2010 3:18 PM
To: Maven Users List
Subject: RE: Test fail for release:perform only - no failure info

I'm downloading Maven 2.2.1 right now.  I'm on a 'loaner' laptop as mine is in 
the shop so I think not having MAVEN_OPTS set for memory settings could be an 
option.  Maybe it runs out of memory under the release:perform and not 
release:prepare?  Anyhow, I'll give both a try.

Thanks!  Any other ideas are welcome.

Regards,

Randall

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Thursday, March 11, 2010 3:08 PM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info

> I'm using Maven 2.0.9.
> Any ideas?  Where to start looking?

Did you try Maven 2.0.10? Or 2.0.11 that was recently released? Or
2.2.1 for that matter if you don't need to use JDK 1.4?

Wayne

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


-
To unsub

RE: Test fail for release:perform only - no failure info

[Randall Fidler]

Hmm... just tried with Maven 2.2.1 and surefire plugin vesion 2.5.  Still none 
of the tests are failing but the build fails because there are test errors.  I 
thought it was one particular test, but I removed it from the project and same 
result.  All tests pass on release:prepare but I get the "build failed due to 
test failures with no failing tests" when I do release:perform.

Ideas?

Thanks!

Randall

-Original Message-----
From: Randall Fidler [mailto:randall.fid...@testadvantage.com] 
Sent: Thursday, March 11, 2010 3:18 PM
To: Maven Users List
Subject: RE: Test fail for release:perform only - no failure info

I'm downloading Maven 2.2.1 right now.  I'm on a 'loaner' laptop as mine is in 
the shop so I think not having MAVEN_OPTS set for memory settings could be an 
option.  Maybe it runs out of memory under the release:perform and not 
release:prepare?  Anyhow, I'll give both a try.

Thanks!  Any other ideas are welcome.

Regards,

Randall

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Thursday, March 11, 2010 3:08 PM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info

> I'm using Maven 2.0.9.
> Any ideas?  Where to start looking?

Did you try Maven 2.0.10? Or 2.0.11 that was recently released? Or
2.2.1 for that matter if you don't need to use JDK 1.4?

Wayne

-
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


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

RE: Test fail for release:perform only - no failure info

[Randall Fidler]

I'm downloading Maven 2.2.1 right now.  I'm on a 'loaner' laptop as mine is in 
the shop so I think not having MAVEN_OPTS set for memory settings could be an 
option.  Maybe it runs out of memory under the release:perform and not 
release:prepare?  Anyhow, I'll give both a try.

Thanks!  Any other ideas are welcome.

Regards,

Randall

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Thursday, March 11, 2010 3:08 PM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info

> I'm using Maven 2.0.9.
> Any ideas?  Where to start looking?

Did you try Maven 2.0.10? Or 2.0.11 that was recently released? Or
2.2.1 for that matter if you don't need to use JDK 1.4?

Wayne

-
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: Test fail for release:perform only - no failure info

[Randall Fidler]

Locked it down the latest surefire plugin version, just for tricks - no
joy.

-Original Message-
From: Randall Fidler [mailto:randall.fid...@testadvantage.com] 
Sent: Thursday, March 11, 2010 2:28 PM
To: users@maven.apache.org
Subject: Test fail for release:perform only - no failure info

Hello,

 

 

 Seeing something weird... a project where all tests pass for
release:prepare but release:perform says it has test failures.  None of
the tests show up with the << FAILURE notation.  I also looked through
all the surefire reports and none of the tests are failing.  I tried
running with error trace (-e) but that provided no further information.


 

I'm using Maven 2.0.9.

 

Any ideas?  Where to start looking?

 

Thanks!

 

Randall


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

Test fail for release:perform only - no failure info

[Randall Fidler]

Hello,

 

 

 Seeing something weird... a project where all tests pass for
release:prepare but release:perform says it has test failures.  None of
the tests show up with the << FAILURE notation.  I also looked through
all the surefire reports and none of the tests are failing.  I tried
running with error trace (-e) but that provided no further information.


 

I'm using Maven 2.0.9.

 

Any ideas?  Where to start looking?

 

Thanks!

 

Randall

Assembly Excludes

[Randall Fidler]

Hello,

 

I'm trying to filter out some dependencies in an assembly
and it works from some but not others.  Here's the block I'm
referencing:

 

...





 
${artifactId}.${extension}

false

provided

/libs





 
javax.jms:jms

 
xerces:xercesImpl

 


 
jboss:jboss-system



 
true







 

If I uncomment that line trying to exclude jbossall-client the build
fails due to the useStrictFiltering (which is fine).  I have double and
triple checked the dependency group id and artifact id and it's correct
but for whatever reason, if I uncomment the line the exclude doesn't
trigger and if I comment the line out, I get the jar in the /libs
directory.  So the problem is that for whatever reason it just will not
exclude that jbossall-client dependency, which as far as I can tell has
the correct group/artifact id.  Is there any way to tell what the
assembly plugin is dealing with?  I.e. "I'm including {group
id}.{artifact id}" That way I'd be able to tell what it 'thinks' the
meta-data for jbossall-client dependency is and exclude it.

 

NOTE: The other excludes work fine, no problem.

 

Thanks!

 

Randall

RE: Disable/Enable tests per plugin/goal

[Randall Fidler]

I think the only way you'd be able to do it was if you could have verify
use profile A (with clover setup in it) and deploy use profile B
(sans-Clover) but from I've seen that's not possible.  My understanding
is you can use either a single or multiple profiles but they apply to
the entire execution, you can't change horses halfway.

-Randall

-Original Message-
From: Randall Fidler [mailto:randall.fid...@testadvantage.com] 
Sent: Monday, February 23, 2009 2:28 PM
To: Maven Users List
Subject: RE: Disable/Enable tests per plugin/goal

Stephen,

Agreed... it's a bit wacked to say the least but I've got to
basically do that to get ride of the 'optimized' source code, which has
the clover hooks in it - the compiled src / jar cannot be deployed to a
repository for production use as it has the clover 'hooks' in it.

Optimally, (using Hudson BTW) Hudson would have multiple "executions"
for a phase and that would make things easier but it would still result
in two lifecycle executions... something like:

1.  mvn verify -Pclover.optimize
2.  mvn clean deploy -Dmaven.tests.skip=true

Basically I'm trying to save time by using Clover's test optimization
but in the same 'build' on the CI server deploy a cloverLESS package.
Hudson doesn't provide for running maven "twice" (that I've seen) and so
I'm trying to see if I can get Maven to do it. Thinking more on it, it
does require two lifecycle runs in order to eliminate the src with the
clover hooks in it BEFORE deployment.

Thanks for the response.

Regards,

Randall

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Monday, February 23, 2009 2:19 PM
To: Maven Users List
Cc: Maven Users List
Subject: Re: Disable/Enable tests per plugin/goal

wtf...

you do know running verify followed by deploy is running the lifecycle  
twice!

if you are using the freestyle project type (and _I_ do not recommend  
the m2 project type as it fecks with your pons behind your back) just  
run maven twice, problem solved

Sent from my [rhymes with myPod] ;-)

On 23 Feb 2009, at 21:08, "Randall Fidler"
 wrote:

> Hello,
>
>
>
>I'm looking into using a feature of Clover, test
> optimization, and run into a tricky situation.  I would like to use  
> the
> test optimization to speed up build times on Hudson and the issue  
> comes
> in that Clover, as part of it's test optimization, puts hooks inside
> your code.  This effectively means you cannot use any artifacts
> generated during the test optimization process for deployment, which  
> in
> turn means the CI can't automatically deploy snapshots if Clover
> optimization is on.
>
>
>
> So, where's the Maven question?  Well what I'm trying to figure out is
> can you, in one call, specify variables per plugin or even a profile  
> per
> plugin?  For example, I believe the following "could" work:
>
>
>
> mvn verify -Pclover.optimize clean deploy
>
>
>
> NOTE: the clover.optimize profile simply configures the clover2 plugin
> to run the proper clover goals, it doesn't change any other behavior
> with other plugins.
>
>
>
> I say it could work IF tests were disabled for deploy.  If tests are  
> not
> disabled for deploy then what's the point of trying to optimize as all
> the tests would be run anyhow - right?  This is where things get  
> tricky,
> I could just disable tests but then the clover plugin thinks it  
> doesn't
> have any work to do so my question is: is there a way with Maven to  
> say
> that tests are disabled for the deploy goal but NOT for the clover
> portion?
>
>
>
> I thought for a minute thatmvn verify -Pclover.optimize clean
> package deploy might work but of course the default lifecycle is going
> to run the test goal when deploy runs, which I can't disable - at  
> least
> not per goal/plugin that I've found.
>
>
>
> Any advice is appreciated.
>
>
>
> Regards,
>
>
>
> Randall
>

-
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



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

RE: Disable/Enable tests per plugin/goal

[Randall Fidler]

Stephen,

Agreed... it's a bit wacked to say the least but I've got to
basically do that to get ride of the 'optimized' source code, which has
the clover hooks in it - the compiled src / jar cannot be deployed to a
repository for production use as it has the clover 'hooks' in it.

Optimally, (using Hudson BTW) Hudson would have multiple "executions"
for a phase and that would make things easier but it would still result
in two lifecycle executions... something like:

1.  mvn verify -Pclover.optimize
2.  mvn clean deploy -Dmaven.tests.skip=true

Basically I'm trying to save time by using Clover's test optimization
but in the same 'build' on the CI server deploy a cloverLESS package.
Hudson doesn't provide for running maven "twice" (that I've seen) and so
I'm trying to see if I can get Maven to do it. Thinking more on it, it
does require two lifecycle runs in order to eliminate the src with the
clover hooks in it BEFORE deployment.

Thanks for the response.

Regards,

Randall

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Monday, February 23, 2009 2:19 PM
To: Maven Users List
Cc: Maven Users List
Subject: Re: Disable/Enable tests per plugin/goal

wtf...

you do know running verify followed by deploy is running the lifecycle  
twice!

if you are using the freestyle project type (and _I_ do not recommend  
the m2 project type as it fecks with your pons behind your back) just  
run maven twice, problem solved

Sent from my [rhymes with myPod] ;-)

On 23 Feb 2009, at 21:08, "Randall Fidler"
 wrote:

> Hello,
>
>
>
>I'm looking into using a feature of Clover, test
> optimization, and run into a tricky situation.  I would like to use  
> the
> test optimization to speed up build times on Hudson and the issue  
> comes
> in that Clover, as part of it's test optimization, puts hooks inside
> your code.  This effectively means you cannot use any artifacts
> generated during the test optimization process for deployment, which  
> in
> turn means the CI can't automatically deploy snapshots if Clover
> optimization is on.
>
>
>
> So, where's the Maven question?  Well what I'm trying to figure out is
> can you, in one call, specify variables per plugin or even a profile  
> per
> plugin?  For example, I believe the following "could" work:
>
>
>
> mvn verify -Pclover.optimize clean deploy
>
>
>
> NOTE: the clover.optimize profile simply configures the clover2 plugin
> to run the proper clover goals, it doesn't change any other behavior
> with other plugins.
>
>
>
> I say it could work IF tests were disabled for deploy.  If tests are  
> not
> disabled for deploy then what's the point of trying to optimize as all
> the tests would be run anyhow - right?  This is where things get  
> tricky,
> I could just disable tests but then the clover plugin thinks it  
> doesn't
> have any work to do so my question is: is there a way with Maven to  
> say
> that tests are disabled for the deploy goal but NOT for the clover
> portion?
>
>
>
> I thought for a minute thatmvn verify -Pclover.optimize clean
> package deploy might work but of course the default lifecycle is going
> to run the test goal when deploy runs, which I can't disable - at  
> least
> not per goal/plugin that I've found.
>
>
>
> Any advice is appreciated.
>
>
>
> Regards,
>
>
>
> Randall
>

-
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

Disable/Enable tests per plugin/goal

[Randall Fidler]

Hello,

 

I'm looking into using a feature of Clover, test
optimization, and run into a tricky situation.  I would like to use the
test optimization to speed up build times on Hudson and the issue comes
in that Clover, as part of it's test optimization, puts hooks inside
your code.  This effectively means you cannot use any artifacts
generated during the test optimization process for deployment, which in
turn means the CI can't automatically deploy snapshots if Clover
optimization is on.

 

So, where's the Maven question?  Well what I'm trying to figure out is
can you, in one call, specify variables per plugin or even a profile per
plugin?  For example, I believe the following "could" work:

 

mvn verify -Pclover.optimize clean deploy

 

NOTE: the clover.optimize profile simply configures the clover2 plugin
to run the proper clover goals, it doesn't change any other behavior
with other plugins.

 

I say it could work IF tests were disabled for deploy.  If tests are not
disabled for deploy then what's the point of trying to optimize as all
the tests would be run anyhow - right?  This is where things get tricky,
I could just disable tests but then the clover plugin thinks it doesn't
have any work to do so my question is: is there a way with Maven to say
that tests are disabled for the deploy goal but NOT for the clover
portion?

 

I thought for a minute thatmvn verify -Pclover.optimize clean
package deploy might work but of course the default lifecycle is going
to run the test goal when deploy runs, which I can't disable - at least
not per goal/plugin that I've found.

 

Any advice is appreciated.

 

Regards,

 

Randall

RE: Multi module site deploy using file

[Randall Fidler]

Hi Dennis,

For both parent and child or just the child?  I can't understand
how having that extra '/' would have the child end up in the proper
location under the parent but I'll give it a whirl.  Currently I do not
have three slashes, just two.

Regards,

Randall

-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org] 
Sent: Sunday, February 15, 2009 8:18 AM
To: Maven Users List
Subject: Re: Multi module site deploy using file

Randall Fidler wrote:
> Hello,
> 
>  
> 
> I have a multi-module project that seemed to deploy fine
> with SCP but not with FILE.  Inside settings.xml I've got a var which
> points to the local directory where the site files should be deployed
to
> and things work fine for the parent but not the child.
> 
>  
> 
> Parent (1.0_SNAPSHOT)   (has site in dist mgmt set to
> file://${site.dir}/${project.artifactId}/${project.version}

Does ${site.dir} start with a / ?

A file URL normally has three /-characters, like this:

file:///directory/path

This is because the host is omitted from the URL.

> 
>  |
> 
>  |
> 
>  - Child (1.0_SNAPSHOT) 
> 
>  
> 
> What happens is I end up with both sites in the same directory instead
> of the child being nested under the parent, which means that the link
in
> the modules section of the parent site has the wrong link for the
child
> site.  It thinks the child is at {parent site directory}/Child  but as
I
> said, the parent and child are at the same level.
> 
>  
> 
> Suggestions?  As I said, the sites are structured properly deployed
> using SCP but with file it doesn't com out correctly.
> 
>  
> 
> Regards,
> 
>  
> 
> Randall
> 
> 


-- 
Dennis Lundberg

-
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

Multi module site deploy using file

[Randall Fidler]

Hello,

 

I have a multi-module project that seemed to deploy fine
with SCP but not with FILE.  Inside settings.xml I've got a var which
points to the local directory where the site files should be deployed to
and things work fine for the parent but not the child.

 

Parent (1.0_SNAPSHOT)   (has site in dist mgmt set to
file://${site.dir}/${project.artifactId}/${project.version}

 |

 |

 - Child (1.0_SNAPSHOT) 

 

What happens is I end up with both sites in the same directory instead
of the child being nested under the parent, which means that the link in
the modules section of the parent site has the wrong link for the child
site.  It thinks the child is at {parent site directory}/Child  but as I
said, the parent and child are at the same level.

 

Suggestions?  As I said, the sites are structured properly deployed
using SCP but with file it doesn't com out correctly.

 

Regards,

 

Randall

Central Repo Issues?

[Randall Fidler]

Hello,

 

Has something occurred recently (past few days) with the
maven central server?  Project was working fine then it starting
complaining that it couldn't check meta-data for maven-clean-plugin from
the central maven repository.  To get around the issue, I temporary
locked down the version in my pom to the current version I already have
(so it won't check for an update) but I'd like to know if something is
hosed with the repo or it's on my end.

 

Regards,

 

Randall

Release plugin question

[Randall Fidler]

Hello,

 

  Using the release plugin if you wanted to assemble your project
BEFORE it rolls over the next SNAPSHOT, how would you accomplish that?

 

For instance:

 

When you do a release:prepare then release:perform and then
assembly:assembly (to run a customer assembler) instead of ending up
with artifacts at, let's say PROJECT-1.0_B0, I end up with an assembly
that is referencing PROJECT-1.0_B1-SNAPSHOT, which is the next version
in line.  From what I can tell this makes sense and at the time the
assembly runs, the version has moved to the next SNAPSHOT.

 

I did see a note that you can tie actions to the relase plugin to do
BEFORE it submits - would you simply put assembly goal in there?  Is
that location referencing between prepare and perform or before it
submits prepare changes or... where?

 

So, just to recap... I'm trying to get my assembly to play with the
PROJECT-1.0_b0 version and not the PROJECT-1.0_b1-SNAPSHOT version.

 

Thanks for any help!

 

Randall

Release perform...

[Randall Fidler]

Hello,

 

Running into an issue with the release plugin.  Using maven
2.0.7 (tried 2.0.8 also) I have a parent pom which has:

 



commons <-- jar file

HostAdapter <-- jar file

FileHostAdapterService  <-- failure occurs here

SocketHostAdapterService

FileTransferServer

standardServer

standardService

HAServer

HAService

HibernateService

web  <-- war file

StepOne



 

 

When doing a release:perform (prepare works fine BTW) Maven compiles,
tests and deploys the commons project and then compiles / tests the
HostAdapter project but DOES NOT DEPLOY it.  When the next project needs
to be compiled (FileHostAdapterService) it complains that it cannot find
the HostAdapter jar (because it wasn't deployed!).  

 

Looking at the lifecycle for jars (as defined here
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycl
e.html) deploy should get run so I'm at a loss why the hostAdapter jar
isn't deployed.

 

Suggestions where to look?

 

Regards,

 

Randall

RE: Maven asks password many times

[Randall Fidler]

Hello,

We went with the public/private rsa key approach for ssh...
works great with Windows clients (using putty) and Ubuntu on the
backside.

Regards,

Randall

-Original Message-
From: Marxx88 [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 28, 2008 2:23 PM
To: users@maven.apache.org
Subject: Maven asks password many times


Hallo everybody,

I use OpenVPN to connect to our server. I set username/password in
maven's
settings.xml.
It asks password again 6-8 times when I run command: mvn deploy. I try
to
use sftp, scp with the same result.

Do you have any ideas? :working:
-- 
View this message in context:
http://www.nabble.com/Maven-asks-password-many-times-tp15145764s177p1514
5764.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Running javadoc:javadoc with site:site causes problems

[Randall Fidler]

What's your project file structure?  Nothing in your POM stuck out as
being obviously wrong at a quick glance...

Also, what version of the plugin are you using?  Perhaps you've got an
older version of the javadoc plugin.  Not sure if there have been any
new releases but might be worth running with -up (I think that's the
switch) to see if there is a new JavaDoc plugin.

One more thing, what version of Maven?  I took a quick peek but didn't
see it in your log files.

Regards,

Randall

-Original Message-
From: Michael [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 15, 2008 7:34 AM
To: Maven Users List
Subject: Re: Running javadoc:javadoc with site:site causes problems

Randall Fidler wrote:
> Hi Michael,
> 
>   I haven't tried to use javadoc:javadoc but do get javadoc output
> with my pom configured like below and running site:site or even
site:run
> 
> 
> 
> ...
> 
> 
> 
> maven-javadoc-plugin
> 
> 
> 
> ...
> 
> 
> 
> I'm not sure if that's what you're after, but does crank out javadoc
in
> the Maven generated site.

Hi Randall,

let's make it clearer:

This is my pom.xml: http://rafb.net/p/Ox0fS259.html
this is what I get when I run "mvn javadoc:javadoc": 
http://rafb.net/p/U0KqMb29.html
this is what I get when I run "mvn site:site": 
http://rafb.net/p/7xREXc27.html

Do you see the diffrence?
1. It generates testdocs for some reason
2. it says it can't resolve types and classes which did not happen with 
javadoc:javadoc

Any idea?

-- 
 OOXML - Say NO To Microsoft Office broken standard
http://www.noooxml.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Running javadoc:javadoc with site:site causes problems

[Randall Fidler]

Hi Michael,

I haven't tried to use javadoc:javadoc but do get javadoc output
with my pom configured like below and running site:site or even site:run



  ...



maven-javadoc-plugin



  ...



I'm not sure if that's what you're after, but does crank out javadoc in
the Maven generated site.

Regards,

Randall

-Original Message-
From: Michael [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 15, 2008 7:14 AM
To: users@maven.apache.org
Subject: Running javadoc:javadoc with site:site causes problems

Hi,

I configured my pom reporting to run javadoc:javadoc within the site 
generation.
Running javadoc:javadoc outputs no errors, running site:site gives me 
tonnes of errors telling that some packages cannot be resolved.

I don't understand that since the doc site of javadoc plugins says 
site:site runs javadoc:javadoc too.

Did I something wrong?
Any necessary resource can be provided.

Thx in advance,

Mike
-- 
 OOXML - Say NO To Microsoft Office broken standard
http://www.noooxml.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Where to put documents

[Randall Fidler]

Thanks Sean... that seems to make sense.

Regards,

Randall

-Original Message-
From: Sean Hennessy [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 09, 2007 12:45 PM
To: Maven Users List
Subject: RE: Where to put documents

Hi Randal,

Given command line mvn site
and in the pom.xml there exists a pre-site phase to move/generate
proj.mgmt artifacts..

  
maven-antrun-plugin

  
pre-site



we place proj. mgt. artifacts in src/site/resources/yourProjDocs
they will find a home under target/site/yourProjDocs.

having made the corresponding changes to site.xml


  
yourProj
./yourProjDocs/images/yourProjLogo.jpg
http://yourProj.com/
  
  
./yourProjDocs/images/yourProjLogo2.jpg
  
   

  
   
   
  
  
   
  



  


Regards,
Sean

-Original Message-
From: Randall Fidler [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 09, 2007 9:47 AM
To: users@maven.apache.org
Subject: Where to put documents


Hello,

 

Looking at the standard Maven directory layout
(http://maven.apache.org/guides/introduction/introduction-to-the-standar
d-directory-layout.html) I'm curious if there's a place to incorporate
non-source application documents, misc. flow diagrams for example.  I
would think that mapping them into /docs, as opposed to /src, would be
fine but if Maven has some pre-defined place for it and subsequently
that location feeds some plug-in or process, then I'd like to start out
on the right foot.

 

Thanks,

 

Randall


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Where to put documents

[Randall Fidler]

Hello,

 

Looking at the standard Maven directory layout
(http://maven.apache.org/guides/introduction/introduction-to-the-standar
d-directory-layout.html) I'm curious if there's a place to incorporate
non-source application documents, misc. flow diagrams for example.  I
would think that mapping them into /docs, as opposed to /src, would be
fine but if Maven has some pre-defined place for it and subsequently
that location feeds some plug-in or process, then I'd like to start out
on the right foot.

 

Thanks,

 

Randall

RE: [continuum-1.1-beta-1] pb with Synergy SCM

[Randall Fidler]

Emmanuel,

We've got Continuum running on Ubuntu Linux.

Regards,

Randall

-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 08, 2007 5:49 AM
To: [EMAIL PROTECTED]
Subject: Re: [continuum-1.1-beta-1] pb with Synergy SCM

Randall, David,

What is your OS?

dvicente a écrit :
> no i haven't seen your earlier post but it seems the same problem with
> Synergy.
> 
> Thanks you for your answer
> 
> Randall Fidler wrote:
>> Hi David,
>>
>>  Not sure if you saw the earlier post by myself and another
>> person but the same situation happened with Perforce SCM; upgraded to
>> the latest beta and nothing works since.  It seems like it just doesn't
>> execute the actual scm commands properly in this latest version.
>>
>> Regards,
>>
>> Randall
>>
>>
>> -Original Message-
>> From: david vicente [mailto:[EMAIL PROTECTED] 
>> Sent: Wednesday, August 08, 2007 1:42 AM
>> To: [EMAIL PROTECTED]
>> Subject: [continuum-1.1-beta-1] pb with Synergy SCM
>>
>> Hi all,
>>
>> I used Continuum 1.0.3 with Synergy (with maven-SCM-api-1.0-beta-4.jar
>> and
>> maven-SCM-provider-synergy-1.0-beta-4.jar in my \ lib) and all works
>> fine.
>>
>> I have just continuum-1.1-beta-1 and nothing works since.
>>
>> it does not manage to extract the sources.
>>
>> In Continuum.log, I have that :
>>
>> 339122 [SocketListener0-0] INFO
>> org.apache.maven.continuum.Continuum:default  - Enqueuing
>> 'VignetteOffre'
>> (Build definition id=2).
>> 339169 [pool-1-thread-1] INFO
>> org.apache.maven.continuum.buildcontroller.BuildController:default  -
>> Initializing build
>> 339169 [pool-1-thread-1] INFO
>> org.apache.maven.continuum.buildcontroller.BuildController:default  -
>> Starting build of VignetteOffre
>> 339435 [pool-1-thread-1] INFO
>> org.apache.maven.continuum.buildcontroller.BuildController:default  -
>> Updating working dir
>> 339435 [pool-1-thread-1] INFO
>> org.apache.maven.continuum.buildcontroller.BuildController:default  -
>> Performing action check-working-directory
>> 339435 [pool-1-thread-1] INFO
>> org.apache.maven.continuum.buildcontroller.BuildController:default  -
>> Performing action checkout-project
>> 339638 [pool-1-thread-1] INFO
>> org.apache.maven.continuum.scm.ContinuumScm:default  - Checking out
>> project:
>> 'VignetteOffre', id: '1' to 'I:\DONNEES\DATA\continuum-
>> 1.1\working-directory\1'.
>> 348091 [pool-1-thread-1] INFO
>> org.apache.maven.scm.manager.ScmManager:default  - A working project
>> already
>> exists [Query expression must be specified.].
>> 354857 [pool-1-thread-1] INFO
>> org.apache.maven.continuum.buildcontroller.BuildController:default  -
>> Merging SCM results
>> 354935 [pool-1-thread-1] INFO
>> org.apache.maven.continuum.buildcontroller.BuildController:default  -
>> Error
>> updating from SCM, not building
>>
>> and my build result traces :
>>
>> Exception:
>> Cannot checkout sources.
>> Exception while executing SCM command.
>> Commandeline = cmd.exe /X /C '"ccm sync -r -p "Query expression must be
>> specified.""'
>> STDOUT = Project reference requires name and version optionally followed
>> by
>> instance: 'Query expression must be specified.'
>>
>> STDERR = Warning: Unable to identify project.
>>
>> I try to set level log to DEBUG but nothing more
>>
>> could you help me ?
>>
>> David Vicente
>>
>>
> 

RE: Perforce SCM

[Randall Fidler]

Good to know I'm not the only one seeing this.  I agree with you, it
acts like the actual Perforce commands aren't being executed.  Hmmm


-Original Message-
From: jpringle [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 07, 2007 12:34 PM
To: [EMAIL PROTECTED]
Subject: Re: Perforce SCM


I'm seeing this as well in 1.1-beta-1.  I see that the client is
actually
getting created correctly (p4 clients -u ), but for whatever
reason
it's like the checkout commands aren't really getting executed or
something.

It must be something in continuum that's changed, as the relevant files
in
the perforce scm provider haven't changed in like 6 months.





Randall Fidler wrote:
> 
> Hello,
> 
>  
> 
> Is anybody using Perforce as their SCM?  Upgraded to
version
> '1.1-beta-1' and the log file only tells me that it was unable to
check
> out the files; it does show the command being issued which appears
> correct (p4 -d [working dir] client -i).  Is there somewhere else I
can
> look for scm error other than the general log?  
> 
>  
> 
> Additionally, is there any way to test the scm setup independently of
> Continuum?
> 
>  
> 
> Thanks!!
> 
>  
> 
> Randall 
> 
> 
> 

-- 
View this message in context:
http://www.nabble.com/Perforce-SCM-tf4203476.html#a12040900
Sent from the Continuum - Users mailing list archive at Nabble.com.

RE: Accessing Continuum Webapp

[Randall Fidler]

Hi Alexander,

I too just installed to 1.1-beta-1 but didn't have any problems with
the web service.  When started Continuum was at
http://:8080/continuum.  Are you sure the service/daemon is running?
Another thing is did you upgrade or remove 1.0.3 and then install
1.1-beta-1 fresh?

Regards,

Randall

-Original Message-
From: Morgovsky, Alexander (US - Glen Mills)
[mailto:[EMAIL PROTECTED] 
Sent: Friday, August 03, 2007 7:26 AM
To: [EMAIL PROTECTED]
Subject: Accessing Continuum Webapp

I installed Continuum 1.1-beta-1 as a service.  Unlike in 1.0.3, I
cannot access it by going to http://:8080/continuum.  What is the
new way of accessing it?  I did not change any of the default
configurations.

The continuum.log file only has the following:
   [WrapperSimpleAppMain] INFO  org.codehaus.plexus.PlexusContainer  -
Loading on start [role,roleHint]:
[org.apache.maven.continuum.Continuum,default]

Thank you. 


This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law.  If you are not the intended recipient, you should
delete this message. 


Any disclosure, copying, or distribution of this message, or the taking
of any action based on it, is strictly prohibited. [v.E.1]

RE: First build errors

[Randall Fidler]

Emmanuel,

 What about the mail configuration that is in:

apps/continuum/webapps/WEB-INF/classes/META-INF/plexus/application.xml

There are some mail configs here, some there - which are correct?  Is one set a 
leftover from a prior version?

Regards,

Randall

-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 02, 2007 12:04 AM
To: [EMAIL PROTECTED]
Subject: Re: First build errors

in conf/plexus.xml, you configure the jndi parameters for the mail session like 
that:

   
 mail/Session
 javax.mail.Session
 
   
 mail.smtp.host
 smtp.hostname.com
   
   
 mail.smtp.port
 25
   
   
 mail.smtp.auth
 true
   
   
 mail.smtp.user
 your_username
   
   
 password
 your_password
   
   
 mail.smtp.debug
 true
   
 
   

Emmanuel

Randall Fidler a écrit :
> Found it, thanks.
> 
> On another note, can anybody provide example config for mail notifier with 
> SMTP authorization?  I tried with username and password setup in addition to 
> the information from the continuum mini guide but the application doesn't run 
> (web app doesn't come up) with those settings.  Is there a valid example 
> somewhere on the net?
> 
> Thanks,
> 
> Randall
> 
> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, August 01, 2007 2:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: First build errors
> 
> The documentation is out of date and we must fix it asap.
> 
> The conf file is now under 
> apps/continuum/webapps/WEB-INF/classes/META-INF/plexus/
> 
> Emmanuel
> 
> Randall Fidler a écrit :
>> Hello,
>>
>>  I've got 1.1-beta-1 running now and now I don't find as many
>> configuration options in the /apps/continuum/conf/application.xml.  I
>> have started and then restarted the service but it doesn't seem to
>> unpack the system, as detailed here
>> (http://maven.apache.org/continuum/guides/mini/guide-configuration.html)
>> so I'm wondering if the change of versions corrupted something?  Is
>> there a way to force the new version to "unpack"?  Note: The only entry
>> is the file is for Jetty.
>>
>> I've ensured that the old version was removed and the web app seems to
>> run fine (not building yet but I can navigate the site) so I'm wondering
>> what happened the IM configs that were in the same config file under the
>> old version?  Are these removed in the new default application.xml?
>>
>> Thanks!
>>
>> Randall
>>
>> -Original Message-
>> From: Jesse McConnell [mailto:[EMAIL PROTECTED] 
>> Sent: Tuesday, July 31, 2007 1:28 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: First build errors
>>
>> I would recommend trying out the continuum 1.1-beta-1, there as been a
>> lot of work all across continuum since the version you are using.
>>
>> log file and configuration would help, if the log file is too big just
>> post a link to it and we can take a peek.
>>
>> I would recommend changing your mail configuration back and seeing if
>> the problem persists, just so we can isolate the issue a bit more :)
>>
>> cheers
>>
>> jesse
>>
>> On 7/30/07, Randall Fidler <[EMAIL PROTECTED]> wrote:
>>> Hello,
>>>
>>>
>>>
>>>I'm running Continuum v1.0.3 on Ubuntu Linux with Maven
>>> 2.0.7 and Java 1.5.0_011.   The web service comes up, I can login and
>>> upload a POM but when I run it, all I end up with is "Exception:
>>> Null" for the build status.  I've increased the logging to DEBUG for
>> all
>>> the default categories in the config but nothing stands out in the log
>>> file.  It appears to be working with Derby fine and there isn't an
>> error
>>> with a huge stack trace so I don't really see what's null.  Can
>> somebody
>>> point me in the right direction?  Would the log file help?
>>>
>>> Regards,
>>>
>>> Randall
>>>
>>>
>>>
>>> p.s. Other than the log files, the only other configuration change I
>>> made was to the mail setup.
>>>
>>>
>>
> 
> 
> 
> 

Perforce SCM

[Randall Fidler]

Hello,

 

Is anybody using Perforce as their SCM?  Upgraded to version
'1.1-beta-1' and the log file only tells me that it was unable to check
out the files; it does show the command being issued which appears
correct (p4 -d [working dir] client -i).  Is there somewhere else I can
look for scm error other than the general log?  

 

Additionally, is there any way to test the scm setup independently of
Continuum?

 

Thanks!!

 

Randall 

RE: First build errors

[Randall Fidler]

Found it, thanks.

On another note, can anybody provide example config for mail notifier with SMTP 
authorization?  I tried with username and password setup in addition to the 
information from the continuum mini guide but the application doesn't run (web 
app doesn't come up) with those settings.  Is there a valid example somewhere 
on the net?

Thanks,

Randall

-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 01, 2007 2:54 PM
To: [EMAIL PROTECTED]
Subject: Re: First build errors

The documentation is out of date and we must fix it asap.

The conf file is now under 
apps/continuum/webapps/WEB-INF/classes/META-INF/plexus/

Emmanuel

Randall Fidler a écrit :
> Hello,
> 
>   I've got 1.1-beta-1 running now and now I don't find as many
> configuration options in the /apps/continuum/conf/application.xml.  I
> have started and then restarted the service but it doesn't seem to
> unpack the system, as detailed here
> (http://maven.apache.org/continuum/guides/mini/guide-configuration.html)
> so I'm wondering if the change of versions corrupted something?  Is
> there a way to force the new version to "unpack"?  Note: The only entry
> is the file is for Jetty.
> 
> I've ensured that the old version was removed and the web app seems to
> run fine (not building yet but I can navigate the site) so I'm wondering
> what happened the IM configs that were in the same config file under the
> old version?  Are these removed in the new default application.xml?
> 
> Thanks!
> 
> Randall
> 
> -Original Message-
> From: Jesse McConnell [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, July 31, 2007 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: First build errors
> 
> I would recommend trying out the continuum 1.1-beta-1, there as been a
> lot of work all across continuum since the version you are using.
> 
> log file and configuration would help, if the log file is too big just
> post a link to it and we can take a peek.
> 
> I would recommend changing your mail configuration back and seeing if
> the problem persists, just so we can isolate the issue a bit more :)
> 
> cheers
> 
> jesse
> 
> On 7/30/07, Randall Fidler <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>>
>>
>>I'm running Continuum v1.0.3 on Ubuntu Linux with Maven
>> 2.0.7 and Java 1.5.0_011.   The web service comes up, I can login and
>> upload a POM but when I run it, all I end up with is "Exception:
>> Null" for the build status.  I've increased the logging to DEBUG for
> all
>> the default categories in the config but nothing stands out in the log
>> file.  It appears to be working with Derby fine and there isn't an
> error
>> with a huge stack trace so I don't really see what's null.  Can
> somebody
>> point me in the right direction?  Would the log file help?
>>
>> Regards,
>>
>> Randall
>>
>>
>>
>> p.s. Other than the log files, the only other configuration change I
>> made was to the mail setup.
>>
>>
> 
> 

RE: First build errors

[Randall Fidler]

Hello,

I've got 1.1-beta-1 running now and now I don't find as many
configuration options in the /apps/continuum/conf/application.xml.  I
have started and then restarted the service but it doesn't seem to
unpack the system, as detailed here
(http://maven.apache.org/continuum/guides/mini/guide-configuration.html)
so I'm wondering if the change of versions corrupted something?  Is
there a way to force the new version to "unpack"?  Note: The only entry
is the file is for Jetty.

I've ensured that the old version was removed and the web app seems to
run fine (not building yet but I can navigate the site) so I'm wondering
what happened the IM configs that were in the same config file under the
old version?  Are these removed in the new default application.xml?

Thanks!

Randall

-Original Message-
From: Jesse McConnell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 31, 2007 1:28 PM
To: [EMAIL PROTECTED]
Subject: Re: First build errors

I would recommend trying out the continuum 1.1-beta-1, there as been a
lot of work all across continuum since the version you are using.

log file and configuration would help, if the log file is too big just
post a link to it and we can take a peek.

I would recommend changing your mail configuration back and seeing if
the problem persists, just so we can isolate the issue a bit more :)

cheers

jesse

On 7/30/07, Randall Fidler <[EMAIL PROTECTED]> wrote:
> Hello,
>
>
>
>I'm running Continuum v1.0.3 on Ubuntu Linux with Maven
> 2.0.7 and Java 1.5.0_011.   The web service comes up, I can login and
> upload a POM but when I run it, all I end up with is "Exception:
> Null" for the build status.  I've increased the logging to DEBUG for
all
> the default categories in the config but nothing stands out in the log
> file.  It appears to be working with Derby fine and there isn't an
error
> with a huge stack trace so I don't really see what's null.  Can
somebody
> point me in the right direction?  Would the log file help?
>
> Regards,
>
> Randall
>
>
>
> p.s. Other than the log files, the only other configuration change I
> made was to the mail setup.
>
>


-- 
jesse mcconnell
[EMAIL PROTECTED]

RE: Surefire classpath issues

[Randall Fidler]

Barrett,

Thanks for your input, glad to know I'm not the only one fighting
the plug-in.  I was hoping that somebody on the list had a work around
but it doesn't appear so.  I'll follow your suggestion and either add to
your existing bug or log a new one with a example project.

Regards,

Randall

-Original Message-
From: Barrett Nuzum [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 20, 2007 8:42 AM
To: Maven Users List
Subject: RE: Surefire classpath issues

Randall:
 
Surefire seems to have a number of issues because of it's dedicated
Resource and Class loaders.
I believe the best practice here is to make an example project and
submit a bug to codehaus.
I've had to do so.
 
http://jira.codehaus.org/browse/SUREFIRE-340
 
Barrett
 
::   
Barrett Nuzum
Consultant, Skill Development
Direct: 918.640.4414
Fax: 972.789.1340 

Valtech Technologies, Inc.
5080 Spectrum Drive
Suite 700 West
Addison, Texas 75001
www.valtech.com <http://www.valtech.com/>   
making IT business friendly


________

From: Randall Fidler [mailto:[EMAIL PROTECTED]
Sent: Wed 6/20/2007 9:58 AM
To: users@maven.apache.org
Subject: Surefire classpath issues



Hello,



Have an issue with trying to leverage Blowfish which ships
with Java 1.5 in relation to unit tests.  The test which I'm trying to
run is using JAXB and Blowfish impl which comes with Java 1.5, i.e.
what's in SunJCE.jar (jre/lib/ext).   



Before I was using a different impl of Blowfish, third party jar
(cryptix) and that was setup as a dependency in my pom so JAXB and the
blowfish impl were on the same "level" - no problems.  The fun begins
when I switch from the third party jar and try to use the java provided
impl.  Now, I can use JAXB and the Java impl together fine, say, when I
run the actual application which is being tested - problems only happen
when running the unit tests via Maven.



First problem:



java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE

Resolved this by enabling the childDelegation for the
surefire plugin.



org.apache.maven.plugins

maven-surefire-plugin



always

true



Note - The surefire plugin describes the childDelegation option as:





When false it makes tests run using the standard classloader delegation
instead of the default Maven isolated classloader. Only used when
forking (forkMode is not "none").



Setting it to false helps with some problems caused by conflicts between
xml parsers in the classpath and the Java 5 provider parser. Default
value is false.











Second problem:

   

When I enable the childDelegation, the plugin then cannot
find the JAXB classes (setup as dependencies in the pom).  I've tried
test/compile scopes on the dependencies but to no avail.



Note: I tried the true
option, but that only seemed to make things worse.









Any help is greatly appreciated!



Regards,



Randall




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Surefire classpath issues

[Randall Fidler]

Hello,

 

Have an issue with trying to leverage Blowfish which ships
with Java 1.5 in relation to unit tests.  The test which I'm trying to
run is using JAXB and Blowfish impl which comes with Java 1.5, i.e.
what's in SunJCE.jar (jre/lib/ext).

 

Before I was using a different impl of Blowfish, third party jar
(cryptix) and that was setup as a dependency in my pom so JAXB and the
blowfish impl were on the same "level" - no problems.  The fun begins
when I switch from the third party jar and try to use the java provided
impl.  Now, I can use JAXB and the Java impl together fine, say, when I
run the actual application which is being tested - problems only happen
when running the unit tests via Maven.

 

First problem:

 

java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE

Resolved this by enabling the childDelegation for the
surefire plugin.

 

org.apache.maven.plugins

maven-surefire-plugin



always

true

 

Note - The surefire plugin describes the childDelegation option as:

 

 

When false it makes tests run using the standard classloader delegation
instead of the default Maven isolated classloader. Only used when
forking (forkMode is not "none").

 

Setting it to false helps with some problems caused by conflicts between
xml parsers in the classpath and the Java 5 provider parser. Default
value is false.

 

 

 

 

 

Second problem:



When I enable the childDelegation, the plugin then cannot
find the JAXB classes (setup as dependencies in the pom).  I've tried
test/compile scopes on the dependencies but to no avail.

 

Note: I tried the true
option, but that only seemed to make things worse.

 

 

 

 

Any help is greatly appreciated!

 

Regards,

 

Randall

Library Resource used in test goal

[Randall Fidler]

Hello,

 

Any ideas why Maven can see classes in sunjce_provider.jar
(SunJCE) at compile time but not when it runs tests?  I wouldn't think
it's a dependency issue as the jar is bundled with the jre I'm using
(1.5_11) and is NOT listed as a dependency.  If it was a test vs compile
dependency issue I could understand but it's not listed as a dependency
and as I said, compiles just fine - it's only during test goal that it
can't find the class.

 

Thoughts?

 

Regards,

 

Randall

RE: Maven 2 - POM Hookup Question

[Randall Fidler]

Wendy,

What protocols does the URL support?  Does it have to be HTTP or
can FTP work?  Just peeking around there's a FTP plugin for Perforce
which could provide access to the poms.

Thanks again!

Regards,

Randall

-Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 22, 2007 9:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Maven 2 - POM Hookup Question

On 5/22/07, Randall Fidler <[EMAIL PROTECTED]> wrote:

> When providing Continuum with a Maven POM via URL, what URL?  POM's
> sitting on a local Maven repository?  The pom which is located in/on
the
> projects website (i.e. website generated by site goal in maven)?
Where
> is this POM located?  Also, how does this work for multi-module POMs?
> Assuming they'd have their own maven project and you can point to the
> pom there?

Usually, it's the pom sitting in the project's source control
repository, which is often visible via a http or https url.  Is that
an option for your project?

Once Continuum retrieves the pom, it uses the (different) url in the
 element to check out the source code.

When the pom has modules, they will get added to the project group as
individual projects.  I'm not sure at which step that happens, but it
does happen.

-- 
Wendy

RE: scp distribution from Windows XP client

[Randall Fidler]

Hi Brendon,

Actually I'm trying to use Windows on both ends.  I am using OpenSSH
currently on the server and I don't have any problems sending files to the
server via SCP using putty - the problems occur only when I try to use Maven
to deploy using SCP via Putty - weird eh? 

I would think that if the client and server can communicate without
any troubles outside of Maven then, unless Maven is using some really odd
command, there shouldn't be any trouble.

Have you had any luck using Windows on both ends?  Both SCP client
and SCP server with Maven?

Thanks,

Randall 
-Original Message-
From: Brendon Matheson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 27, 2007 11:36 PM
To: Maven Users List
Subject: RE: scp distribution from Windows XP client

Hi Randall,

You're talking about deploying to a SCP server running on Windows, rather
than deploying with a SCP client on Windows, right?

Although I haven't used it in a Maven context, I have OpenSSH for Windows
(http://sshwindows.sourceforge.net/) running on a Windows box.  This allows
you to SSH / SCP into the box just like a *nix box running OpenSSH, so I
imagine it should work for deploying artifacts from Maven.  Supports SSH1,
SSH2, public keys etc.

brnzn

-Original Message-
From: Randall Fidler [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 11:53 AM
To: Maven Users List
Subject: RE: scp distribution from Windows XP client


Hi Dennis,
 Are you deploying to a Windows server?  I tried using putty with
Windows XP to do SCP deployments and the SCP server I used had issues with
the commands putty was issuing to it.  I assume since the Maven site
recommends putty and noting your success that it's not putty's fault but the
SCP server I used.
So, can you tell me if you are deploying to a Windows server and if so, what
SCP server did you use?
Regards,
Randall




From: Dennis Lundberg [mailto:[EMAIL PROTECTED]
Sent: Tue 2/27/2007 2:59 PM
To: Maven Users List
Subject: Re: scp distribution from Windows XP client



mark_in_gr skrev:
> Do I need cygwin installed if I want to use the scp style of distribution
> from a Windows box?

No you don't. I do distributions from XP using putty.

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

BEGIN:VCARD
VERSION:2.1
N:Fidler;Randall
FN:Randall Fidler
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20050926T075331Z
END:VCARD


smime.p7s
Description: S/MIME cryptographic signature

RE: scp distribution from Windows XP client

[Randall Fidler]

Hi Dennis,
 Are you deploying to a Windows server?  I tried using putty with Windows 
XP to do SCP deployments and the SCP server I used had issues with the commands 
putty was issuing to it.  I assume since the Maven site recommends putty and 
noting your success that it's not putty's fault but the SCP server I used.
So, can you tell me if you are deploying to a Windows server and if so, what 
SCP server did you use?
Regards,
Randall




From: Dennis Lundberg [mailto:[EMAIL PROTECTED]
Sent: Tue 2/27/2007 2:59 PM
To: Maven Users List
Subject: Re: scp distribution from Windows XP client



mark_in_gr skrev:
> Do I need cygwin installed if I want to use the scp style of distribution
> from a Windows box?

No you don't. I do distributions from XP using putty.

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Assembly plugin bug?

[Randall Fidler]

Jo,

Wow, that explanation was insightful.  Have you had an luck with
unpacking excludes?  I.e. if I want to jar together a bunch of other
"unpacked" jars and exclude any *.txt (for example) files.

I've tried an assembly descriptor that looks like:


  
  
true


**/*.txt
/*.txt
*.txt




But it just refuses to "exclude" the txt files in the dependency jars and
then end up in my final executable jar.

Any clues?

Thanks,

Randall 

NOTE: I posted this question about a week ago but didn't get a response that
I'm aware of so if somebody did answer this already, my apologies.

-Original Message-
From: Jo Vandermeeren [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 26, 2007 12:10 PM
To: Maven Users List
Subject: Re: Assembly plugin bug?

Hi Tommy,

That's no bug.. The assembly plugin filters resources on a per-file basis,
it doesn't apply filtering on fileSets.

So, define a file set for all files that don't need filtering and add
excludes for files that you want to filter..
Then, define  elements for the files that you wan to filter and set
 to true on them..

Here's a snippet:


  blabla
  
zip
  
  

  ${basedir}
  *.sh
  
install.sh
  

  
  

  install.sh
  /
  true

  




Cheers
Jo

On 2/26/07, Tommy Knowlton <[EMAIL PROTECTED]> wrote:
>
> I'm trying to use the maven-assembly-plugin to build a zip that
> contains an install.sh at the top level, along with some arbitrary
> other artifacts.
>
> I want the install.sh source to be filtered so that certain build-time
> variables will be run-time literals.
>
> I've tried to compose an assembly descriptor to do this, but Maven2 is
> telling me about the "Unrecognized tag: 'filtered'".
>
> I wonder whether anybody here that is familiar with the
> maven-assembly-plugin can tell me what I've done wrong?
>
> My assembly descriptor looks like the following:
>
> 
> overlay
> 
> zip
> 
> 
> 
> src/main/bash
> true  
> 
> 
> install.sh
> 
> 
> 
> target
> 
> 
> *.jar
> 
> 
> 
> 
>
> Thanks,
> --
> Tommy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
BEGIN:VCARD
VERSION:2.1
N:Fidler;Randall
FN:Randall Fidler
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20050926T075331Z
END:VCARD


smime.p7s
Description: S/MIME cryptographic signature

Assembly Plugin - unPackOptions

[Randall Fidler]

Has anybody had any luck with the unpack options for the assembly plugin
2.2-SNAPSHOT?  I'm brining in a dependency which is, for the most part,
a normal jar but has some *.dll's packaged with it.  I'm trying to
filter out the *.dll's from being the final "grouped" jar in which all
the dependencies are unpacked and reassembled into a single, final
executable jar.  That's easy enough except the DLLs from the support
library keep finding their way into the end result, I thought
unpackOptions excludes would filter that out... any ideas?

 

I'm using:

 

   

  

  

true



  

**/*.dll

/*.dll

*.dll

  





 

The DLLs are in the root of the dependency jar so I would think that
*.dll would filter them out but when it didn't I tried the other two
patterns just in case.  I've checked the temp location where the plugin
is uncompressing the dependency jars, just as another check, and the
dlls are there so the unpack options are not impacting the unpacking.

 

Thanks,

 

Randall

 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SCP deploy issue

[Randall Fidler]

Hello,

 

Trying to use deploy to place project jar onto network
repository.  I have both Windows client and server (XP / 2003) and am using
Putty for my SHH tool along with pscp.  In my settings I have:

 



  MyRepo

  administrator

testpassword



 

Now, when I try to use the deploy:deploy-file goal, just with a test file,
like so:

 

D:\ >mvn deploy:deploy-file -Durl=scp://10.1.1.13 -DrepositoryId=MyRepo
-Dfile=results.jar

 -DgroupId=Testgroup -DartifactId=test -Dversion=1.0.0 -Dpackaging=jar
-Dmave

n.scp.executable=pscp -e

 

I get:

 

[INFO] Error deploying artifact: Error performing commands for file transfer

 

Exit code: 1 - The syntax of the command is incorrect.

[INFO]


[INFO] Trace

org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifact

: Error performing commands for file transfer

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa

ultLifecycleExecutor.java:559)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone

Goal(DefaultLifecycleExecutor.java:488)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau

ltLifecycleExecutor.java:458)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan

dleFailures(DefaultLifecycleExecutor.java:306)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen

ts(DefaultLifecycleExecutor.java:219)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi

fecycleExecutor.java:140)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.

java:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces

sorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

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: Error deploying
artif

act: Error performing commands for file transfer

at
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.

java:240)

at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi

nManager.java:412)

at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa

ultLifecycleExecutor.java:534)

... 16 more

Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Error

 deploying artifact: Error performing commands for file transfer

at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Def

aultArtifactDeployer.java:91)

at
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.

 

Now, I can run just 'd:>pscp' and get a listing of options so maven should
also be able to find the pscp executable (it's in the 'path').

Also, if I execute "C:\>pscp test.cfg
 [EMAIL PROTECTED]:test.cfg"
(and provide the pasword at prompt), the file is transferred which shows
that the user id and password are working for that server URL.

 

>From what I can tell, maven should be able to see pscp, it has the server
url, the user id and password.  Is there somewhere I can see what command
it's trying to execute via the pscp executable?

 

Any help is appreciated.


Best regards,

Randall

 

BEGIN:VCARD
VERSION:2.1
N:Fidler;Randall
FN:Randall Fidler
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20050926T075331Z
END:VCARD


smime.p7s
Description: S/MIME cryptographic signature

RE: SAR PLUGIN

[Randall Fidler]

Doug,

Thanks!  It was just that I had put the resources in the Java
directory... sometimes you just need a slap back into reality.  Now that
it's actually building, let's see if it's generating what I need, that's
another story.

Thanks again,

Randall 
-Original Message-
From: Doug Douglass [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 15, 2006 12:57 PM
To: Maven Users List
Subject: Re: SAR PLUGIN

Randall,

Maybe you just had a typo in your email...try putting the
jboss-service.xmlin src/main/resources/META-INF and it should find it.
I'd be surprised if
src/main/java/resources/META-INF works for the ejb plugin.

Doug

On 12/15/06, Eric Redmond <[EMAIL PROTECTED]> wrote:
>
> What do you mean? What version are you using? Its only available as
> 2.0-SNAPSHOT, and you must add the sandbox repo to your POM:
>
> http://mojo.codehaus.org/using-sandbox-plugins.html
>
> Also, don't use the SAR plugin, it's no longer under development.
>
> Eric
>
> On 12/15/06, Randall Fidler <[EMAIL PROTECTED]> wrote:
> >
> > Eric,
> >
> > Maven just wasn't bringing it down from the repository, i.e.
> can't
> > find plugin.  I got maven to bring the plugin down but now it's saying
> > that
> > it cannot find jboss-service.xml.  Thinking along the lines of the ejb
> > plugin, I thought placing it in the /src/main/java/resources/META-INF
> > directory would be fine but I guess not.
> >
> > The plugin which I did get to work, somewhat, BTW is:
> >
> > http://mojo.codehaus.org/jboss-sar-maven-plugin/sar-mojo.html
> >
> > Thanks for the reply.
> >
> > Thanks,
> >
> > Randall
> >
> > -Original Message-
> > From: Eric Redmond [mailto:[EMAIL PROTECTED]
> > Sent: Friday, December 15, 2006 8:34 AM
> > To: Maven Users List
> > Subject: Re: SAR PLUGIN
> >
> > What problems have you had with the jboss-packaging plugin? Before
> > attempting a work-around, please give some specifics so anything broken
> > can
> > be fixed.
> >
> > Eric
> >
> > On 12/15/06, Randall Fidler <[EMAIL PROTECTED]> wrote:
> > >
> > >  Hello,
> > >
> > >
> > >
> > > Can anybody recommend a sar plugin?  I've tried using the
> > jboss-packaging
> > > plugin but to no avail. has anybody had any luck with that?
> > >
> > >
> > > Regards,
> > >
> > > Randall
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Eric Redmond
> > http://codehaus.org/~eredmond
> >
> >
> >
>
>
> --
> Eric Redmond
> http://codehaus.org/~eredmond
>
>
BEGIN:VCARD
VERSION:2.1
N:Fidler;Randall
FN:Randall Fidler
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20050926T075331Z
END:VCARD


smime.p7s
Description: S/MIME cryptographic signature

RE: SAR PLUGIN

[Randall Fidler]

Eric,

Maven just wasn't bringing it down from the repository, i.e. can't
find plugin.  I got maven to bring the plugin down but now it's saying that
it cannot find jboss-service.xml.  Thinking along the lines of the ejb
plugin, I thought placing it in the /src/main/java/resources/META-INF
directory would be fine but I guess not.

The plugin which I did get to work, somewhat, BTW is:

http://mojo.codehaus.org/jboss-sar-maven-plugin/sar-mojo.html

Thanks for the reply.

Thanks,

Randall 

-Original Message-
From: Eric Redmond [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 15, 2006 8:34 AM
To: Maven Users List
Subject: Re: SAR PLUGIN

What problems have you had with the jboss-packaging plugin? Before
attempting a work-around, please give some specifics so anything broken can
be fixed.

Eric

On 12/15/06, Randall Fidler <[EMAIL PROTECTED]> wrote:
>
>  Hello,
>
>
>
> Can anybody recommend a sar plugin?  I've tried using the jboss-packaging
> plugin but to no avail. has anybody had any luck with that?
>
>
> Regards,
>
> Randall
>
>
>
>


-- 
Eric Redmond
http://codehaus.org/~eredmond
BEGIN:VCARD
VERSION:2.1
N:Fidler;Randall
FN:Randall Fidler
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20050926T075331Z
END:VCARD


smime.p7s
Description: S/MIME cryptographic signature

SAR PLUGIN

[Randall Fidler]

Hello,

 

Can anybody recommend a sar plugin?  I've tried using the jboss-packaging
plugin but to no avail. has anybody had any luck with that?


Regards,

Randall

 

BEGIN:VCARD
VERSION:2.1
N:Fidler;Randall
FN:Randall Fidler
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20050926T075331Z
END:VCARD


smime.p7s
Description: S/MIME cryptographic signature

Maven EAR plugin issue

[Randall Fidler]

Hello,

 

Looking for some insight regarding the maven ear plugin.
Project setup is:

 

+ App pom (contains sub-project module entries)

-  commons (creates jar with POJOs), let's say it's maven id is
'my.commons'

-  ejb jar, maven id is 'my.ejb'

-  service, creates an 'ear' <-- ear plugin sits here

 

For now I'm just trying to use the following to include the POJOs and the
ejb jar

 



org.apache.maven.plugins

maven-ear-plugin





  

  myGroup

  my.ejb

  

  

   myGroup 

 
my.commons

  

  



  

  

 

While produces an error stating:

 

[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven

-ear-plugin:2.2

 

 

 

Cause: Class 'org.apache.maven.plugin.ear.EarModule' cannot be instantiated

 

Using the maven "-e" switch shows that it has a problem with DOM, which I
assume is a parsing error of the configuration:

 

[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven

-ear-plugin:2.2

 

 

 

Cause: Class 'org.apache.maven.plugin.ear.EarModule' cannot be instantiated

[INFO]


[INFO] Trace

org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring:
org.a

pache.maven.plugins:maven-ear-plugin. Reason: Unable to parse the created
DOM fo

r plugin configuration

 

Also, if I take out the the modules it runs, which is obviously because it
doesn't have anything to do, i.e. this works fine:

 



 
org.apache.maven.plugins

maven-ear-plugin











 

Knowing that, could this issue be I'm missing a field for the modules?  I.e.
ejbModule and jarModule?

 

Any help is appreciated.


Best regards,

Randall

 

NOTE:

 

Top level pom has:

 

  pom

  

commons   <-- my.commons

server   <-- my.ejb

service  <-- contains ear build

  

 

BEGIN:VCARD
VERSION:2.1
N:Fidler;Randall
FN:Randall Fidler
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20050926T075331Z
END:VCARD


smime.p7s
Description: S/MIME cryptographic signature