Re: Test classpath issue with v2.0.8 and v2.0.9

[Clifton]

I have a couple of observations... First off I see you're writing you unit
tests in Groovy! That's a good thing of course for far too many reasons.
It's also an important detail to pay attention to. There are a hole host of
other details to look at as well. Secondly it appears you are trying to
query for the resource folder using code. This is not a good thing or a
necessary thing to do. Maven will put all of your "test resources" under the
test-classes folder unless something else somewhere else tells it not to.
Another detail is that your code is asking the wrong question and may have
been mistakenly getting at the right answer all along. It asks the location
of it's execution folder not the location of the resource folder. I can show
you the correct hack to locating the resource folder involving a marker file
which you could run and arrive at a more accurate answer. More on that
later. Here's the important things to consider. Groovy is
interpreted/compiled. Running that same groovy code through a plugin (like
the Groovy plugin or Ant run) would place compiled classes in your classes
output folder. In one case I'm assuming the code was being copied from the
test/resources to the test-classes folder and in another case it is possibly
being filtered. I can't tell without looking.

Here's some things to look for. Find out where the Groovy code is being run
from. Is it being both compiled to target/classes and copied over to
target/test-classes as .groovy files? If so then there's some ambiguity
worth cleaning up. What is it you are actually trying to do? Do you want to
run the scripts or do you want to compile them? If you are compiling them
make sure you point the compiler to the correct output folder.

I feel like I'm babbling and confusing you more than helping but I'm sure
your problem lies in whther you compile to the correct output folder or copy
to the correct output folder. Look for filters that may have been added as
well.

jlo_gestalt wrote:
> 
> When trying to access test resources in my unit tests, maven 2.0.8 and
> above are returning the wrong directory.
> 
> Here is my basic code to access the folder
> def file = new JmblXsltDriverTest().getClass().getResource("/")?.file
> println file
> 
> On 2.0.7 this would print
> /workspace/checkout/weather/trunk/jetjwis/jbi/jmbl-xslt/target/test-classes/
> 
> On 2.0.8 and 2.0.9 this prints
> /workspace/checkout/weather/trunk/jetjwis/jbi/jmbl-xslt/target/classes/
> 
> To me this is a critical bug that would almost certainly cause every
> projects unit tests that access test resources to fail.
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Test-classpath-issue-with-v2.0.8-and-v2.0.9-tp17276386p17281319.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]

Re: Test classpath issue with v2.0.8 and v2.0.9

[Dan Fabulich]

jlo_gestalt wrote:



When trying to access test resources in my unit tests, maven 2.0.8 and above
are returning the wrong directory.

Here is my basic code to access the folder
def file = new JmblXsltDriverTest().getClass().getResource("/")?.file
println file

On 2.0.7 this would print
/workspace/checkout/weather/trunk/jetjwis/jbi/jmbl-xslt/target/test-classes/

On 2.0.8 and 2.0.9 this prints
/workspace/checkout/weather/trunk/jetjwis/jbi/jmbl-xslt/target/classes/

To me this is a critical bug that would almost certainly cause every
projects unit tests that access test resources to fail.


I'm going to guess you're encountering the bug described here:
http://docs.codehaus.org/display/MAVENUSER/Classpath+Ordering+Bugs+in+Maven+Surefire

Upgrading Surefire will probably restore you to the correct behavior.

-Dan

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

Test classpath issue with v2.0.8 and v2.0.9

[jlo_gestalt]

When trying to access test resources in my unit tests, maven 2.0.8 and above
are returning the wrong directory.

Here is my basic code to access the folder
def file = new JmblXsltDriverTest().getClass().getResource("/")?.file
println file

On 2.0.7 this would print
/workspace/checkout/weather/trunk/jetjwis/jbi/jmbl-xslt/target/test-classes/

On 2.0.8 and 2.0.9 this prints
/workspace/checkout/weather/trunk/jetjwis/jbi/jmbl-xslt/target/classes/

To me this is a critical bug that would almost certainly cause every
projects unit tests that access test resources to fail.


-- 
View this message in context: 
http://www.nabble.com/Test-classpath-issue-with-v2.0.8-and-v2.0.9-tp17276386p17276386.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]

Re: Maven 1 classes in my plugin JAR not on runtime classpath?

[Lukas Theussl]

IIRC artifacts of type plugin are not added to the runtime classpath (if 
you run with -X you should see a corresponding message). You have to 
deploy/install the plugin as a jar and declare a dependency of a jar type.


HTH,
-Lukas


christo wrote:

Hi All,

I've read the docs, googled, read mailing list archives, asked in irc
etc. but have been unable to find the answer to this.

I'm writing a maven 1 plugin which adds a goal that calls 
running the main method of a class which is bundled in the plugin jar.
There are jar deps in the plugin but my question is not about ensuring
that the plugin's dependencies are on the runtime classpath of the
jvm. I understand how to do this using the
${plugin.getDependencyPath()} call.

The purpose of the plugin is to create a file for the distribution -
essentially metadata for the app. Originally I tried to implement the
whole thing in Jelly but after a few hours I gave up and wrote it in a
dozen lines of Java.

The plugin runs the goal in my project but when the jvm tries to load
my class it can't find it. Why is the plugin jar not on the classpath
of the project when the goal is sought? I have tried sprinkling magic
fork="true" spawn="true" and this doesn't work.

I've been assuming I need to put a classpath reference into the
 tag.  But I can't do this because my plugin jar is not  a
dep of itself. Below you can see I've descended into cargo culting a
bit in frustration and pasted ant path elements willy nilly.

The only other plugins I can find that bundle classes are build
reports which register themselves explicitly. Do I have to register
for a non report plugin?

My plugin id: maven-hash-registry-plugin
Main class for plugin: com.atlassian.hashregistry.GenerateHashRegistry
Goal name: hashregistry:generate


  











   

  


Any pointers or wisdom would help. I'm just about to check out the
source to Maven!

thanks in advance,

Chris.



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

Maven 1 classes in my plugin JAR not on runtime classpath?

[christo]

Hi All,

I've read the docs, googled, read mailing list archives, asked in irc
etc. but have been unable to find the answer to this.

I'm writing a maven 1 plugin which adds a goal that calls 
running the main method of a class which is bundled in the plugin jar.
There are jar deps in the plugin but my question is not about ensuring
that the plugin's dependencies are on the runtime classpath of the
jvm. I understand how to do this using the
${plugin.getDependencyPath()} call.

The purpose of the plugin is to create a file for the distribution -
essentially metadata for the app. Originally I tried to implement the
whole thing in Jelly but after a few hours I gave up and wrote it in a
dozen lines of Java.

The plugin runs the goal in my project but when the jvm tries to load
my class it can't find it. Why is the plugin jar not on the classpath
of the project when the goal is sought? I have tried sprinkling magic
fork="true" spawn="true" and this doesn't work.

I've been assuming I need to put a classpath reference into the
 tag.  But I can't do this because my plugin jar is not  a
dep of itself. Below you can see I've descended into cargo culting a
bit in frustration and pasted ant path elements willy nilly.

The only other plugins I can find that bundle classes are build
reports which register themselves explicitly. Do I have to register
for a non report plugin?

My plugin id: maven-hash-registry-plugin
Main class for plugin: com.atlassian.hashregistry.GenerateHashRegistry
Goal name: hashregistry:generate


  











   

  


Any pointers or wisdom would help. I'm just about to check out the
source to Maven!

thanks in advance,

Chris.

-- 
Chris Mountford

"In theory, there is no difference between theory and practice. But,
in practice, there is." -- Jan L. A. van de Snepscheut

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

classpath container issues

[Chris_Graham]

Given this fragment:



org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere
 
v6.1 JRE

org.eclipse.jst.server.core.container/com.ibm.ws.ast.st.runtime.runtimeTarget.v61/was.base.v61

org.eclipse.jst.j2ee.internal.module.container


running mvn eclipse:eclipse will generate the appriate .classpath file:


  
  
  
  
  
  
  


Any dependencies listed in the POM will all be added as a variable 
extension using the M2_REPO variable.

This leads me to a question.

We can specify the classpath container entries, fine, and that works.

However, doesn't this conflict with the dependencies section (which in 
turn generates the .classpath entries which will result in duplicate 
entried).

Adding in the classpath container entries fine fine from within eclipse.

However, what happens when you are attempting to build the app outside of 
eclipse (ie, from Hudson or other similar CI tool).

I do not have a good handle on how all of this is meant to work.

-Chris



**
CAUTION - This message is intended for the addressee named above. It may 
contain privileged or confidential information. 

If you are not the intended recipient of this message you must: 
- Not use, copy, distribute or disclose it to anyone other than the addressee;
- Notify the sender via return email; and
- Delete the message (and any related attachments) from your computer 
immediately.

Internet emails are not necessarily secure. Australian Associated Motors 
Insurers Limited ABN 92 004 791 744 (AAMI), and its related entities, do not 
accept responsibility for changes made to this message after it was sent.

Unless otherwise stated, views expressed within this email are the author's own 
and do not represent those of AAMI.
**

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

Re: Modify Classpath

[vicki]

This is exactly what I am doing - an integration test. I decided to create a
separate "test" subproject that  is a peer to the "tested" subprojects.  I
hoped that by declaring the same parent in my test subproject and inheriting
all the project's dependencies I will be able to avoid version confusions
and test the artifacts whose versions are perfectly aligned. I did not want
to employ any hecks to solve my artifact availability problem, but to do it
entirely with dependency mechanism available in maven. 

Michael McCallum-3 wrote:
> 
> in my particular case i needed the code for integration tests so was 
> borderline as to whether the artifact was actually separate or not... 
> 
> but in general i would agree
> On Wed, 14 May 2008 12:02:13 Brian E. Fox wrote:
>> If you have classes that you need outside a war, the correct way is to
>> make this into a jar that is used externally and also packaged inside
>> your war.
>>
> 
> -- 
> Michael McCallum
> Enterprise Engineer
> mailto:[EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Modify-Classpath-tp17215208p17236473.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]

Re: classpath entries in maven-archiver generated MANIFEST.MF cannot be referenced

[aldana]

i tried different things and my guess is that the problems occur because the
problematic module is a webapplication running in the lightweight jetty
container. it seems that the jetty-classloader cannot cope with some
classpath entries. all other non-webapp components i am using with the
generated MANIFEST.MF are working fine.

i heard already some issues about webcontainers and referencing classpaths,
so i suspect the same problem with my app.


-
manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de
-- 
View this message in context: 
http://www.nabble.com/classpath-entries-in-maven-archiver-generated-MANIFEST.MF-cannot-be-referenced-tp17229567p17232146.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]

Re: classpath entries in maven-archiver generated MANIFEST.MF cannot be referenced

[aldana]

no, i copy/pasted the Class-Path bit from my maven-jar-plugin generated
MANIFEST.MF and it is a multi-liner. it follows the 72 bytes block. all
lines have maximum 72 bytes length and each newline starts with a white
space.

maybe this seems more to be a java as a maven-jar-plugin issue. i am using
jre1.6.0_02. will investigate further...


[EMAIL PROTECTED] wrote:
> 
> If this is all on one line, then that is a violation of the java
> Manifest-file specification.
> 
> See:
> http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Manifest%20Specification
> 
> 
> 
>>  * Line length:
>> No line may be longer than 72 bytes (not characters), in its
>> UTF8-encoded form.
>> If a value would make the initial line longer than this, it should
>> be continued on
>> extra lines (each starting with a single SPACE).
>> 
> 


-
manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de
-- 
View this message in context: 
http://www.nabble.com/classpath-entries-in-maven-archiver-generated-MANIFEST.MF-cannot-be-referenced-tp17229567p17230602.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]

Re: classpath entries in maven-archiver generated MANIFEST.MF cannot be referenced

[[EMAIL PROTECTED]]

aldana schrieb:
> hi,
>
> i got problems with the classpath entries MANIFEST.MF. some classes cannot
> be found, though they exist as entry in MANIFEST.MF. weird thing is, that
> some jars are included correctly (i get some basic startup, which needs some
> dependency jars, but in the end all crashes).
>
> startup, which tells me it cannot find a certain type:
> 'java -classpath .:mainJar.jar de..Main'
>
> startup, which gets further, but still crashes afterwards:
> 'java -classpath .:mainJar.jar:../lib/myfaces-impl-1.1.5.jar de..Main'
>
> this tells me that not all class-path entries are included correctly.
>
> the weird thing is, that the generated class-path of MANIFEST.MF (see below)
> looks fine. maybe there are too many entries (~80), which is causing
> problems... has anybody faced similar symptoms when using maven-jar plugin
> and  option?
>
> ---Generated MANIFEST.MF CLASSPATH by maven-jar-plugin-
>
> Class-Path: ../lib/hibernate-commons-annotations-3.3.0.ga.jar ../lib/h
>  ibernate-3.2.5.ga.jar ../lib/ehcache-1.2.3.jar ../lib/commons-logging
>  -1.1.jar ../lib/commons-collections-3.1.jar ../lib/jta-1.0.1B.jar ../
>  lib/asm-attrs-1.5.3.jar ../lib/dom4j-1.6.1.jar ../lib/antlr-2.7.6.jar
>   ../lib/cglib-2.1_3.jar ../lib/asm-1.5.3.jar ../lib/persistence-api-1
>  .0.jar ../lib/tomahawk-1.1.5.jar ../lib/commons-validator-1.3.1.jar .
>  ./lib/commons-beanutils-1.7.0.jar ../lib/commons-digester-1.6.jar ../
>  lib/xml-apis-1.0.b2.jar ../lib/commons-fileupload-1.0.jar ../lib/comm
>  ons-el-1.0.jar ../lib/commons-codec-1.3.jar ../lib/oro-2.0.8.jar ../l
>  ib/commons-lang-2.1.jar ../lib/jstl-1.1.0.jar ../lib/log4j-1.2.12.jar
>   ../lib/castor-0.9.5.4.jar ../lib/openjms-0.7.7.jar ../lib/openjms-co
>  mmon-0.7.7.jar ../lib/hibernate-annotations-3.3.0.ga.jar ../lib/myfac
>  es-api-1.1.5.jar ../lib/spring-2.0.6.jar ../lib/logkit-1.0.1.jar ../l
>  ib/avalon-framework-4.1.3.jar ../lib/common-konnektor-1.1-SNAPSHOT.ja
>  r ../lib/managementPersistence-1.0-SNAPSHOT.jar ../lib/commons-dbcp-1
>  .2.1.jar ../lib/commons-pool-1.2.jar ../lib/hsqldb-1.8.0.7.jar ../lib
>  /baseUtilities-1.1-SNAPSHOT.jar ../lib/jaxb-api-2.1.jar ../lib/stax-a
>  pi-1.0-2.jar ../lib/activation-1.1.jar ../lib/jaxb-impl-2.1.jar ../li
>  b/xml-sec-1.3.jar ../lib/bcprov-1.35.jar ../lib/saaj-impl-1.3.jar ../
>  lib/saaj-api-1.3.jar ../lib/xsom-1.0.1.jar ../lib/relaxngDatatype-200
>  20414.jar ../lib/xalan-2.7.0.jar ../lib/jcalendar-1.3.2.jar ../lib/co
>  mmons-httpclient-3.0.jar ../lib/common-gematik-1.1-SNAPSHOT.jar ../li
>  b/jaxws-rt-2.1.3.jar ../lib/axiom-api-1.2.2.jar ../lib/mail-1.4.jar .
>  ./lib/jaxen-1.1-beta-9.jar ../lib/xercesImpl-2.0.2.jar ../lib/stax-ap
>  i-1.0.1.jar ../lib/release-2.2.1-1.0-SNAPSHOT.jar ../lib/axiom-impl-1
>  .2.2.jar ../lib/axis2-adb-1.1.1.jar ../lib/axis2-kernel-1.1.1.jar ../
>  lib/wsdl4j-1.6.1.jar ../lib/jms-1.1.jar ../lib/openjms-net-0.7.7.jar 
>  ../lib/jsp-2.1-6.1.7.jar ../lib/core-3.1.1.jar ../lib/jsp-api-2.1-6.1
>  .7.jar ../lib/servlet-api-2.5-6.1.7.jar ../lib/ant-1.6.5.jar ../lib/m
>  yfaces-impl-1.1.5.jar ../lib/concurrent-1.3.4.jar ../lib/jetty-plus-6
>  .1.7.jar ../lib/geronimo-spec-jta-1.0.1B-rc4.jar ../lib/jetty-6.1.7.j
>  ar ../lib/jetty-util-6.1.7.jar ../lib/spice-jndikit-1.2.jar ../lib/In
>  tegrityManager-1.0.0-SNAPSHOT.jar
>
>   
If this is all on one line, then that is a violation of the java
Manifest-file specification.

See:
http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Manifest%20Specification


 * Line length:
No line may be longer than 72 bytes (not characters), in its
UTF8-encoded form.
If a value would make the initial line longer than this, it should
be continued on
extra lines (each starting with a single SPACE).



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

classpath entries in maven-archiver generated MANIFEST.MF cannot be referenced

[aldana]

hi,

i got problems with the classpath entries MANIFEST.MF. some classes cannot
be found, though they exist as entry in MANIFEST.MF. weird thing is, that
some jars are included correctly (i get some basic startup, which needs some
dependency jars, but in the end all crashes).

startup, which tells me it cannot find a certain type:
'java -classpath .:mainJar.jar de..Main'

startup, which gets further, but still crashes afterwards:
'java -classpath .:mainJar.jar:../lib/myfaces-impl-1.1.5.jar de..Main'

this tells me that not all class-path entries are included correctly.

the weird thing is, that the generated class-path of MANIFEST.MF (see below)
looks fine. maybe there are too many entries (~80), which is causing
problems... has anybody faced similar symptoms when using maven-jar plugin
and  option?

---Generated MANIFEST.MF CLASSPATH by maven-jar-plugin-

Class-Path: ../lib/hibernate-commons-annotations-3.3.0.ga.jar ../lib/h
 ibernate-3.2.5.ga.jar ../lib/ehcache-1.2.3.jar ../lib/commons-logging
 -1.1.jar ../lib/commons-collections-3.1.jar ../lib/jta-1.0.1B.jar ../
 lib/asm-attrs-1.5.3.jar ../lib/dom4j-1.6.1.jar ../lib/antlr-2.7.6.jar
  ../lib/cglib-2.1_3.jar ../lib/asm-1.5.3.jar ../lib/persistence-api-1
 .0.jar ../lib/tomahawk-1.1.5.jar ../lib/commons-validator-1.3.1.jar .
 ./lib/commons-beanutils-1.7.0.jar ../lib/commons-digester-1.6.jar ../
 lib/xml-apis-1.0.b2.jar ../lib/commons-fileupload-1.0.jar ../lib/comm
 ons-el-1.0.jar ../lib/commons-codec-1.3.jar ../lib/oro-2.0.8.jar ../l
 ib/commons-lang-2.1.jar ../lib/jstl-1.1.0.jar ../lib/log4j-1.2.12.jar
  ../lib/castor-0.9.5.4.jar ../lib/openjms-0.7.7.jar ../lib/openjms-co
 mmon-0.7.7.jar ../lib/hibernate-annotations-3.3.0.ga.jar ../lib/myfac
 es-api-1.1.5.jar ../lib/spring-2.0.6.jar ../lib/logkit-1.0.1.jar ../l
 ib/avalon-framework-4.1.3.jar ../lib/common-konnektor-1.1-SNAPSHOT.ja
 r ../lib/managementPersistence-1.0-SNAPSHOT.jar ../lib/commons-dbcp-1
 .2.1.jar ../lib/commons-pool-1.2.jar ../lib/hsqldb-1.8.0.7.jar ../lib
 /baseUtilities-1.1-SNAPSHOT.jar ../lib/jaxb-api-2.1.jar ../lib/stax-a
 pi-1.0-2.jar ../lib/activation-1.1.jar ../lib/jaxb-impl-2.1.jar ../li
 b/xml-sec-1.3.jar ../lib/bcprov-1.35.jar ../lib/saaj-impl-1.3.jar ../
 lib/saaj-api-1.3.jar ../lib/xsom-1.0.1.jar ../lib/relaxngDatatype-200
 20414.jar ../lib/xalan-2.7.0.jar ../lib/jcalendar-1.3.2.jar ../lib/co
 mmons-httpclient-3.0.jar ../lib/common-gematik-1.1-SNAPSHOT.jar ../li
 b/jaxws-rt-2.1.3.jar ../lib/axiom-api-1.2.2.jar ../lib/mail-1.4.jar .
 ./lib/jaxen-1.1-beta-9.jar ../lib/xercesImpl-2.0.2.jar ../lib/stax-ap
 i-1.0.1.jar ../lib/release-2.2.1-1.0-SNAPSHOT.jar ../lib/axiom-impl-1
 .2.2.jar ../lib/axis2-adb-1.1.1.jar ../lib/axis2-kernel-1.1.1.jar ../
 lib/wsdl4j-1.6.1.jar ../lib/jms-1.1.jar ../lib/openjms-net-0.7.7.jar 
 ../lib/jsp-2.1-6.1.7.jar ../lib/core-3.1.1.jar ../lib/jsp-api-2.1-6.1
 .7.jar ../lib/servlet-api-2.5-6.1.7.jar ../lib/ant-1.6.5.jar ../lib/m
 yfaces-impl-1.1.5.jar ../lib/concurrent-1.3.4.jar ../lib/jetty-plus-6
 .1.7.jar ../lib/geronimo-spec-jta-1.0.1B-rc4.jar ../lib/jetty-6.1.7.j
 ar ../lib/jetty-util-6.1.7.jar ../lib/spice-jndikit-1.2.jar ../lib/In
 tegrityManager-1.0.0-SNAPSHOT.jar


-
manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de
-- 
View this message in context: 
http://www.nabble.com/classpath-entries-in-maven-archiver-generated-MANIFEST.MF-cannot-be-referenced-tp17229567p17229567.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]

Re: Modify Classpath

[Michael McCallum]

in my particular case i needed the code for integration tests so was 
borderline as to whether the artifact was actually separate or not... 

but in general i would agree
On Wed, 14 May 2008 12:02:13 Brian E. Fox wrote:
> If you have classes that you need outside a war, the correct way is to
> make this into a jar that is used externally and also packaged inside
> your war.
>

-- 
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]

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

RE: Modify Classpath

[Brian E. Fox]

If you have classes that you need outside a war, the correct way is to
make this into a jar that is used externally and also packaged inside
your war.

-Original Message-
From: vicki [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 13, 2008 6:49 PM
To: users@maven.apache.org
Subject: Re: Modify Classpath


Olivier, thank you very much for the advice. Unfortunately, my quick
test of
build-classpath did did not solve my runtime classpath problem. First of
all, the examples of the build-classpath goal that I saw, show how to
output
the project's classpath to a file. What I need is to add project
dependencies to a runtime of a maven's "exec" plugin. I did use an

tag that I set to true, hoping that this will take care of putting all
the
dependencies into the runtime, but it didn't. Second, the output file
with a
classpath that build-classpath goal produced, did not resolved the
artifacts
that are packaged as wars. It does put wars in the classpath, but this,
naturally, does not make classes inside these wars available in the
runtime. 


Olivier Dehon-2 wrote:
> 
> Have a look at the build-classpath goal of the dependency plugin:
>
http://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-
mojo.html
> 
> -Olivier
> 
> On Tue, 2008-05-13 at 11:23 -0700, vicki wrote:
>> Hello,
>> I have a maven's subproject that runs tests against the artifacts of
its
>> piers subprojects. Obviously, In other words, to run my tests I need
to
>> create dependencies on the artifacts produced by the other
subprojects. I
>> run my tests with maven's "exec" plugin. All the artifacts packaged
as
>> jars
>> are indeed on my classpath when I run maven exec. But dependencies on
the
>> artifacts packaged as wars are not resolved in such a way that
classes
>> directory inside these wars are put on the classpath. I do not want
to
>> explicitly specify a classpath in the configuration of maven exec
plugin.
>> Instead I'd like to have a classpath that is build with project's
>> dependencies.  Can anyone advise a good way of doing this?
>> Thanks a lot.
>> Vicki
>> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context:
http://www.nabble.com/Modify-Classpath-tp17215208p17220036.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: Modify Classpath

[Michael McCallum]

On Wed, 14 May 2008 11:18:54 Wendy Smoak wrote:
> On Tue, May 13, 2008 at 11:23 AM, vicki <[EMAIL PROTECTED]> wrote:
> >  I have a maven's subproject that runs tests against the artifacts of its
> >  piers subprojects. Obviously, In other words, to run my tests I need to
> >  create dependencies on the artifacts produced by the other subprojects.
> > I run my tests with maven's "exec" plugin. All the artifacts packaged as
> > jars are indeed on my classpath when I run maven exec. But dependencies
> > on the artifacts packaged as wars are not resolved in such a way that
> > classes directory inside these wars are put on the classpath.
>
> Java simply has no concept of putting a war file on the classpath.  If
> you have code in a war module that you need to use elsewhere, the best
> idea is to move the code to a separate module that builds a jar.  That
> jar then becomes a dependency of your war module plus any other module
> that needs it.
>
> If you absolutely can't move the code, the next version of the war
> plugin will have the ability to deploy a classified/attached artifact
> containing the code from a war module.

1) you can make the packaging type of the project jar 
2) add a config for the war plugin to execute war... 
  
maven-war-plugin
2.1-alpha-1

  

  war

  


  true
  application

  
3) this gives you a jar and a war
4) you can then depend upon the jar (default) artifact to get the deps of this 
project and if you need to

a.b
a.b.c
[1,2-!)

5) to use this war as an underlay you can depend on the project with 
classifier 'application'

a.b
a.b.c
[1,2-!)
war




-- 
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]

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

Re: Modify Classpath

[Wendy Smoak]

On Tue, May 13, 2008 at 11:23 AM, vicki <[EMAIL PROTECTED]> wrote:

>  I have a maven's subproject that runs tests against the artifacts of its
>  piers subprojects. Obviously, In other words, to run my tests I need to
>  create dependencies on the artifacts produced by the other subprojects. I
>  run my tests with maven's "exec" plugin. All the artifacts packaged as jars
>  are indeed on my classpath when I run maven exec. But dependencies on the
>  artifacts packaged as wars are not resolved in such a way that classes
>  directory inside these wars are put on the classpath.

Java simply has no concept of putting a war file on the classpath.  If
you have code in a war module that you need to use elsewhere, the best
idea is to move the code to a separate module that builds a jar.  That
jar then becomes a dependency of your war module plus any other module
that needs it.

If you absolutely can't move the code, the next version of the war
plugin will have the ability to deploy a classified/attached artifact
containing the code from a war module.

-- 
Wendy

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

Re: Modify Classpath

[vicki]

Olivier, thank you very much for the advice. Unfortunately, my quick test of
build-classpath did did not solve my runtime classpath problem. First of
all, the examples of the build-classpath goal that I saw, show how to output
the project's classpath to a file. What I need is to add project
dependencies to a runtime of a maven's "exec" plugin. I did use an 
tag that I set to true, hoping that this will take care of putting all the
dependencies into the runtime, but it didn't. Second, the output file with a
classpath that build-classpath goal produced, did not resolved the artifacts
that are packaged as wars. It does put wars in the classpath, but this,
naturally, does not make classes inside these wars available in the runtime. 


Olivier Dehon-2 wrote:
> 
> Have a look at the build-classpath goal of the dependency plugin:
> http://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.html
> 
> -Olivier
> 
> On Tue, 2008-05-13 at 11:23 -0700, vicki wrote:
>> Hello,
>> I have a maven's subproject that runs tests against the artifacts of its
>> piers subprojects. Obviously, In other words, to run my tests I need to
>> create dependencies on the artifacts produced by the other subprojects. I
>> run my tests with maven's "exec" plugin. All the artifacts packaged as
>> jars
>> are indeed on my classpath when I run maven exec. But dependencies on the
>> artifacts packaged as wars are not resolved in such a way that classes
>> directory inside these wars are put on the classpath. I do not want to
>> explicitly specify a classpath in the configuration of maven exec plugin.
>> Instead I'd like to have a classpath that is build with project's
>> dependencies.  Can anyone advise a good way of doing this?
>> Thanks a lot.
>> Vicki
>> 
> 
> 
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Modify-Classpath-tp17215208p17220036.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]

Re: Modify Classpath

[Olivier Dehon]

Have a look at the build-classpath goal of the dependency plugin:
http://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.html

-Olivier

On Tue, 2008-05-13 at 11:23 -0700, vicki wrote:
> Hello,
> I have a maven's subproject that runs tests against the artifacts of its
> piers subprojects. Obviously, In other words, to run my tests I need to
> create dependencies on the artifacts produced by the other subprojects. I
> run my tests with maven's "exec" plugin. All the artifacts packaged as jars
> are indeed on my classpath when I run maven exec. But dependencies on the
> artifacts packaged as wars are not resolved in such a way that classes
> directory inside these wars are put on the classpath. I do not want to
> explicitly specify a classpath in the configuration of maven exec plugin.
> Instead I'd like to have a classpath that is build with project's
> dependencies.  Can anyone advise a good way of doing this?
> Thanks a lot.
> Vicki
> 


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

Modify Classpath

[vicki]

Hello,
I have a maven's subproject that runs tests against the artifacts of its
piers subprojects. Obviously, In other words, to run my tests I need to
create dependencies on the artifacts produced by the other subprojects. I
run my tests with maven's "exec" plugin. All the artifacts packaged as jars
are indeed on my classpath when I run maven exec. But dependencies on the
artifacts packaged as wars are not resolved in such a way that classes
directory inside these wars are put on the classpath. I do not want to
explicitly specify a classpath in the configuration of maven exec plugin.
Instead I'd like to have a classpath that is build with project's
dependencies.  Can anyone advise a good way of doing this?
Thanks a lot.
Vicki

-- 
View this message in context: 
http://www.nabble.com/Modify-Classpath-tp17215208p17215208.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]

PMD plugin and classpath management

[Benson Margulies]

I have written a custom Java rule. I'm now trying to make it run inside
mvn.

One project builds the rule, the others run PMD with it.

To code the rule to begin with, I added a POM dependency for the pmd/pmd
artifact, version 4.2. At runtime, I get a failure complaining that I'm
trying to override AbstractJavaRule.

So, I tried changing the scope of the pmd dependency to provided, on the
theory that the plugin would indeed, well, \provide/ it. No such luck,
now I get a class not found for AbstractJavaRule.

What's the recipe here?



[ERROR] FATAL ERROR
[INFO]

[INFO] class net.sourceforge.pmd.AbstractJavaRule overrides final method
 
.

[INFO]

[INFO] Trace
java.lang.VerifyError: class net.sourceforge.pmd.AbstractJavaRule
overrides final method 
.

at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
at
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
at
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
net.sourceforge.pmd.RuleSetFactory.parseInternallyDefinedRuleNode(RuleSetFactory.java:278)
at
net.sourceforge.pmd.RuleSetFactory.parseRuleNode(RuleSetFactory.java:261)
at
net.sourceforge.pmd.RuleSetFactory.createRuleSet(RuleSetFactory.java:199)
at
net.sourceforge.pmd.RuleSetFactory.createRuleSet(RuleSetFactory.java:172)
at
org.apache.maven.plugin.pmd.PmdReport.executeReport(PmdReport.java:184)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
at
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java


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

RE: Maven Jar plugin 2.0 : ClassPath in manifest

[Thomas Darbois]

Clicked on send before pasting the link:

http://jira.codehaus.org/browse/MJAR-61

Tomas Darbois

-Message d'origine-
De : Thomas Darbois
Envoyé : mercredi 23 avril 2008 11:00
À : 'Maven Users List'
Objet : RE: Maven Jar plugin 2.0 : ClassPath in manifest

Well i ve found the Jira that is linked to that problem :



Tomas Darbois

-Message d'origine-
De : Thomas Darbois [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 23 avril 2008 10:10
À : Maven Users List
Objet : RE: Maven Jar plugin 2.0 : ClassPath in manifest

Thanks for replying :)

I've tried to put  to the pom for test, it didn't change anything. I 
ve check the exported-pom and indeed the tag was already set to 
${artifactId} even without adding your suggestion (it 
inherits that part of the build from his parent pom). It seems that he doesn't 
read finalName tag in the exported-pom(s) that are inside the jar of his 
dependencies, but when you are generating the entire modules from the parent 
module, it keeps in memory all their finalname.

I don't know what you mean with your alternative solution (I might understand 
it but if it's the case it didn't work either).


I'll check the Jira if I see such a problem, but I've done several search and I 
didn't see anything like that (one solution might be working with full name: 
${artifactId}-${version} as finalname instead of just artifactId, but I would 
prefer to avoid that).

And indeed I forget yesterday to put the maven version I'm using.

It's maven 2.0.8.

Tomas Darbois
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Lee Meador
Envoyé : mardi 22 avril 2008 19:34
À : Maven Users List
Objet : Re: Maven Jar plugin 2.0 : ClassPath in manifest

I'm not real familiar with that part of maven, but ...

Did you try adding a  to the pom for "test" to give it the name
without the version number included?

Alternatively, there might be a problem inheriting the dependency plugin
configurations in the toto project. You could try copying them from the
parent.

You might also look in the Jira to see if one of the plugins or maven itself
has such a problem already reported. You didn't mention which maven version
you are using.

-- Lee

On Tue, Apr 22, 2008 at 3:30 AM, Thomas Darbois <[EMAIL PROTECTED]>
wrote:

> Hello
>
> I'm having trouble with a multi module project that I m working on.
>
>
> I need a class path inside the manifest of the built jar (plugin maven jar
> and configuration true in my parent pom defined
> in pluginManagement).
>
> The classpath is perfectly formatted when I'm running the project from the
> parent pom, but when I'm running maven from one of the module the class path
> is not well formatted: it add a version tag at the end of the name of the
> library the module depends on.
>
> Example:
>
>
>
> .
>
>  |-- pom.xml
>
>  |
>
>  |-- test
>
>  |   `-- pom.xml
>
>  `-- toto
>
> `-- pom.xml
>
>
> A module toto (packaging: jar, version: 0.1) dependending on an other
> module test (packaging: jar, version: 0.1) both are called by the pom parent
> (packaging: pom, version: 0.1) using  and both are inheriting from
> him
> (parentcom.edifixio.sample0.1)=>
> fully project inheritance and aggregation.
>
> The parent pom.xml look likes:
>
> 
>  4.0.0
>  com.edifixio.sample
>  parent
>  0.1
>  pom
>  
>toto
>test
>  
>  
>${artifactId}
>
>  
>  org.apache.maven.plugins
> maven-jar-plugin
> 2.0
> 
>   
> 
>
> true
>
> ${mainClass}
> 
>   
> 
> 
>   
> compile
> 
>   jar
> 
>   
> 
>
>  
>  org.apache.maven.plugins
>
>  maven-dependency-plugin
> 
>  
>
>  copy
> 

RE: Maven Jar plugin 2.0 : ClassPath in manifest

[Thomas Darbois]

Well i ve found the Jira that is linked to that problem :



Tomas Darbois
Edifixio Grenoble - Projet ScorWare
04 76 29 89 27
[EMAIL PROTECTED]

-Message d'origine-
De : Thomas Darbois [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 23 avril 2008 10:10
À : Maven Users List
Objet : RE: Maven Jar plugin 2.0 : ClassPath in manifest

Thanks for replying :)

I've tried to put  to the pom for test, it didn't change anything. I 
ve check the exported-pom and indeed the tag was already set to 
${artifactId} even without adding your suggestion (it 
inherits that part of the build from his parent pom). It seems that he doesn't 
read finalName tag in the exported-pom(s) that are inside the jar of his 
dependencies, but when you are generating the entire modules from the parent 
module, it keeps in memory all their finalname.

I don't know what you mean with your alternative solution (I might understand 
it but if it's the case it didn't work either).


I'll check the Jira if I see such a problem, but I've done several search and I 
didn't see anything like that (one solution might be working with full name: 
${artifactId}-${version} as finalname instead of just artifactId, but I would 
prefer to avoid that).

And indeed I forget yesterday to put the maven version I'm using.

It's maven 2.0.8.

Tomas Darbois
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Lee Meador
Envoyé : mardi 22 avril 2008 19:34
À : Maven Users List
Objet : Re: Maven Jar plugin 2.0 : ClassPath in manifest

I'm not real familiar with that part of maven, but ...

Did you try adding a  to the pom for "test" to give it the name
without the version number included?

Alternatively, there might be a problem inheriting the dependency plugin
configurations in the toto project. You could try copying them from the
parent.

You might also look in the Jira to see if one of the plugins or maven itself
has such a problem already reported. You didn't mention which maven version
you are using.

-- Lee

On Tue, Apr 22, 2008 at 3:30 AM, Thomas Darbois <[EMAIL PROTECTED]>
wrote:

> Hello
>
> I'm having trouble with a multi module project that I m working on.
>
>
> I need a class path inside the manifest of the built jar (plugin maven jar
> and configuration true in my parent pom defined
> in pluginManagement).
>
> The classpath is perfectly formatted when I'm running the project from the
> parent pom, but when I'm running maven from one of the module the class path
> is not well formatted: it add a version tag at the end of the name of the
> library the module depends on.
>
> Example:
>
>
>
> .
>
>  |-- pom.xml
>
>  |
>
>  |-- test
>
>  |   `-- pom.xml
>
>  `-- toto
>
> `-- pom.xml
>
>
> A module toto (packaging: jar, version: 0.1) dependending on an other
> module test (packaging: jar, version: 0.1) both are called by the pom parent
> (packaging: pom, version: 0.1) using  and both are inheriting from
> him
> (parentcom.edifixio.sample0.1)=>
> fully project inheritance and aggregation.
>
> The parent pom.xml look likes:
>
> 
>  4.0.0
>  com.edifixio.sample
>  parent
>  0.1
>  pom
>  
>toto
>test
>  
>  
>${artifactId}
>
>  
>  org.apache.maven.plugins
> maven-jar-plugin
> 2.0
> 
>   
> 
>
> true
>
> ${mainClass}
> 
>   
> 
> 
>   
> compile
> 
>   jar
> 
>   
> 
>
>  
>  org.apache.maven.plugins
>
>  maven-dependency-plugin
> 
>  
>
>  copy
>  install
>  
>copy
>  
>  
>
>  

RE: Maven Jar plugin 2.0 : ClassPath in manifest

[Thomas Darbois]

Thanks for replying :)

I've tried to put  to the pom for test, it didn't change anything. I 
ve check the exported-pom and indeed the tag was already set to 
${artifactId} even without adding your suggestion (it 
inherits that part of the build from his parent pom). It seems that he doesn't 
read finalName tag in the exported-pom(s) that are inside the jar of his 
dependencies, but when you are generating the entire modules from the parent 
module, it keeps in memory all their finalname.

I don't know what you mean with your alternative solution (I might understand 
it but if it's the case it didn't work either).


I'll check the Jira if I see such a problem, but I've done several search and I 
didn't see anything like that (one solution might be working with full name: 
${artifactId}-${version} as finalname instead of just artifactId, but I would 
prefer to avoid that).

And indeed I forget yesterday to put the maven version I'm using.

It's maven 2.0.8.

Tomas Darbois
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Lee Meador
Envoyé : mardi 22 avril 2008 19:34
À : Maven Users List
Objet : Re: Maven Jar plugin 2.0 : ClassPath in manifest

I'm not real familiar with that part of maven, but ...

Did you try adding a  to the pom for "test" to give it the name
without the version number included?

Alternatively, there might be a problem inheriting the dependency plugin
configurations in the toto project. You could try copying them from the
parent.

You might also look in the Jira to see if one of the plugins or maven itself
has such a problem already reported. You didn't mention which maven version
you are using.

-- Lee

On Tue, Apr 22, 2008 at 3:30 AM, Thomas Darbois <[EMAIL PROTECTED]>
wrote:

> Hello
>
> I'm having trouble with a multi module project that I m working on.
>
>
> I need a class path inside the manifest of the built jar (plugin maven jar
> and configuration true in my parent pom defined
> in pluginManagement).
>
> The classpath is perfectly formatted when I'm running the project from the
> parent pom, but when I'm running maven from one of the module the class path
> is not well formatted: it add a version tag at the end of the name of the
> library the module depends on.
>
> Example:
>
>
>
> .
>
>  |-- pom.xml
>
>  |
>
>  |-- test
>
>  |   `-- pom.xml
>
>  `-- toto
>
> `-- pom.xml
>
>
> A module toto (packaging: jar, version: 0.1) dependending on an other
> module test (packaging: jar, version: 0.1) both are called by the pom parent
> (packaging: pom, version: 0.1) using  and both are inheriting from
> him
> (parentcom.edifixio.sample0.1)=>
> fully project inheritance and aggregation.
>
> The parent pom.xml look likes:
>
> 
>  4.0.0
>  com.edifixio.sample
>  parent
>  0.1
>  pom
>  
>toto
>test
>  
>  
>${artifactId}
>
>  
>  org.apache.maven.plugins
> maven-jar-plugin
> 2.0
> 
>   
> 
>
> true
>
> ${mainClass}
> 
>   
> 
> 
>   
> compile
> 
>   jar
> 
>   
> 
>
>  
>  org.apache.maven.plugins
>
>  maven-dependency-plugin
> 
>  
>
>  copy
>  install
>  
>copy
>  
>  
>
>  
>
>
>  ${project.groupId}
>
>
>
>  ${project.artifactId}
>
&

Re: Maven Jar plugin 2.0 : ClassPath in manifest

[Lee Meador]

I'm not real familiar with that part of maven, but ...

Did you try adding a  to the pom for "test" to give it the name
without the version number included?

Alternatively, there might be a problem inheriting the dependency plugin
configurations in the toto project. You could try copying them from the
parent.

You might also look in the Jira to see if one of the plugins or maven itself
has such a problem already reported. You didn't mention which maven version
you are using.

-- Lee

On Tue, Apr 22, 2008 at 3:30 AM, Thomas Darbois <[EMAIL PROTECTED]>
wrote:

> Hello
>
> I'm having trouble with a multi module project that I m working on.
>
>
> I need a class path inside the manifest of the built jar (plugin maven jar
> and configuration true in my parent pom defined
> in pluginManagement).
>
> The classpath is perfectly formatted when I'm running the project from the
> parent pom, but when I'm running maven from one of the module the class path
> is not well formatted: it add a version tag at the end of the name of the
> library the module depends on.
>
> Example:
>
>
>
> .
>
>  |-- pom.xml
>
>  |
>
>  |-- test
>
>  |   `-- pom.xml
>
>  `-- toto
>
> `-- pom.xml
>
>
> A module toto (packaging: jar, version: 0.1) dependending on an other
> module test (packaging: jar, version: 0.1) both are called by the pom parent
> (packaging: pom, version: 0.1) using  and both are inheriting from
> him
> (parentcom.edifixio.sample0.1)=>
> fully project inheritance and aggregation.
>
> The parent pom.xml look likes:
>
> 
>  4.0.0
>  com.edifixio.sample
>  parent
>  0.1
>  pom
>  
>toto
>test
>  
>  
>${artifactId}
>
>  
>  org.apache.maven.plugins
> maven-jar-plugin
> 2.0
> 
>   
> 
>
> true
>
> ${mainClass}
> 
>   
> 
> 
>   
> compile
> 
>   jar
> 
>   
> 
>
>  
>  org.apache.maven.plugins
>
>  maven-dependency-plugin
> 
>  
>
>  copy
>  install
>  
>copy
>  
>  
>
>  
>
>
>  ${project.groupId}
>
>
>
>  ${project.artifactId}
>
>
>
>  ${project.version}
>
>
>  true
>
>
>  ${project.packaging}
>
>
>
>  ${artifactId}.${project.packaging}
>
>  
>
>
>  ${projectOutput}
>
>  
>
>
>  copy-dependencies
>  install
>  
>
>  copy-dependencies
>  
>  
>
>  true
>
> 

Maven Jar plugin 2.0 : ClassPath in manifest

[Thomas Darbois]

Hello

I'm having trouble with a multi module project that I m working on.


I need a class path inside the manifest of the built jar (plugin maven jar and 
configuration true in my parent pom defined in 
pluginManagement).

The classpath is perfectly formatted when I'm running the project from the 
parent pom, but when I'm running maven from one of the module the class path is 
not well formatted: it add a version tag at the end of the name of the library 
the module depends on.

Example:



.

 |-- pom.xml

 |

 |-- test

 |   `-- pom.xml

 `-- toto

 `-- pom.xml


A module toto (packaging: jar, version: 0.1) dependending on an other module 
test (packaging: jar, version: 0.1) both are called by the pom parent 
(packaging: pom, version: 0.1) using  and both are inheriting from him 
(parentcom.edifixio.sample0.1)=>
 fully project inheritance and aggregation.

The parent pom.xml look likes:


  4.0.0
  com.edifixio.sample
  parent
  0.1
  pom
  
toto
test
  
  
${artifactId}

  
  org.apache.maven.plugins
 maven-jar-plugin
 2.0
 
   
 
   true
   
${mainClass}
 
   
 

   
 compile
 
   jar
 
   
 

  
  org.apache.maven.plugins
  maven-dependency-plugin
 
  

  copy
  install
  
copy
  
  

  

  
${project.groupId}


  
${project.artifactId}


  
${project.version}


true

  
${project.packaging}


  
${artifactId}.${project.packaging}

  


  ${projectOutput}

  


  copy-dependencies
  install
  
copy-dependencies
  
  

true

${projectOutput}
  
  provided

  
  








The directory test contains a pom.xml :


  
com.edifixio.sample
parent
0.1
  
  4.0.0
  
com.edifixio.sample
  
  test


The directory toto contains a pom.xml :


  
com.edifixio.sample

Re: locally-installed jars are not found in classpath

[Wayne Fay]

Show us the declaration of the dependency in the pom.xml, as well as
the "mvn install:install-file" line you are using to install the file
into your local repo cache.

Also, paste the results of "mvn -X package" (or whatever command you
are executing, with the addition of the -X parameter for debug mode)
to www.pastebin.org and send the URL to this list. Do not just send
the entire debug dump via email, or as an attachment.

We need to see specific error strings to really analyze your problem.

Wayne

On 4/19/08, isaacyho <[EMAIL PROTECTED]> wrote:
>
> Hi all--
>
> I have a 3rd-party jar I am trying to install into my maven repository.
> The repository is filled with various jars installed by our company, and our
> current project references these with no problem.
>
> I installed this jar with mvn install-file, and it shows up as expected in
> the local repository.  I then added the dependency to my pom.xml.
>
> This 3rd-party jar is called "reactor.jar" and has a namespace edu.bsallas.
> When I modify my test script--which references the other repository jars no
> problem---to include an "import edu.bsallas.*", then the compilation fails,
> claiming no such package exists.  However, right above it is an "import
> junit.framework.*", which references a locally-installed .jar (in our case)
> in the repository.
>
> The weird part is that maven, in building the test, seems to correctly
> reference the jar, because if I change the name of the jar in the repository
> to something bogus, then maven bombs that a dependency was not found.   So
> the main issue for me: how can a jar be found while building, and then not
> found while running?
>
> I verified that the reactor.jar looks good: directory structure is correct (
> top level is edu, then bsallas, then the class files ).   I also tried
> another .jar file for a commercial product ( p6spy ) and am getting the same
> problems:  class not found errors.
>
> Thanks if you have any ideas!
>
> Isaac
> --
> View this message in context: 
> http://www.nabble.com/locally-installed-jars-are-not-found-in-classpath-tp16786887s177p16786887.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]

locally-installed jars are not found in classpath

[isaacyho]

Hi all--

I have a 3rd-party jar I am trying to install into my maven repository.  
The repository is filled with various jars installed by our company, and our
current project references these with no problem.

I installed this jar with mvn install-file, and it shows up as expected in
the local repository.  I then added the dependency to my pom.xml.

This 3rd-party jar is called "reactor.jar" and has a namespace edu.bsallas. 
When I modify my test script--which references the other repository jars no
problem---to include an "import edu.bsallas.*", then the compilation fails,
claiming no such package exists.  However, right above it is an "import 
junit.framework.*", which references a locally-installed .jar (in our case)
in the repository.

The weird part is that maven, in building the test, seems to correctly
reference the jar, because if I change the name of the jar in the repository
to something bogus, then maven bombs that a dependency was not found.   So
the main issue for me: how can a jar be found while building, and then not
found while running?   

I verified that the reactor.jar looks good: directory structure is correct (
top level is edu, then bsallas, then the class files ).   I also tried
another .jar file for a commercial product ( p6spy ) and am getting the same
problems:  class not found errors.

Thanks if you have any ideas!

Isaac
-- 
View this message in context: 
http://www.nabble.com/locally-installed-jars-are-not-found-in-classpath-tp16786887s177p16786887.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]

Re: Maven2 Eclipse Plugin - ordering of .classpath entries

[Patrick Zeising]

nicolas de loof-3 wrote:
> 
> Could you create a Jira issue for this ?
> 

You can find the issue here: http://jira.codehaus.org/browse/MECLIPSE-437

Greets
Patrick
-- 
View this message in context: 
http://www.nabble.com/Maven2-Eclipse-Plugin---ordering-of-.classpath-entries-tp16722527s177p16761752.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]

Classpath Manifest and format of libraries. Maven-jar-Plugin

[Thomas Darbois]

Hello

I'm having trouble with a multi module project that I m working on.

I need a class path inside the manifest of the built jar (plugin maven jar and 
configuration true in my parent pom defined in 
pluginmanagement).

The classpath is perfectly formatted when I'm running the project from the 
parent pom, but when I'm running maven from one of the module the class path is 
not well formatted: it add a version tag at the end of the name of the library 
the module depends on.

Example:

A module toto(packaging : jar, version : 0.1) dependending on an other module 
test (packaging : jar, version : 0.1) both are called by the pom parent 
(packaging : pom, version : 0.1) using  and both are inheriting from 
him (parent[...])
The parent pom look likes :


toto
test


${artifactId}


org.apache.maven.plugins

maven-jar-plugin
2.0




true





compile

jar









The module toto contains :



XXX

test
0.1





When I m packaging from the parent pom the classpath inside of the manifest of 
toto.jar looks like :
Class-Path: test.jar

When I'm packaging from toto the classpath inside the manifest of toto.jar 
looks like :
Class-Path: test-0.1.jar


Is there anywhere to format the name of the libraries inside the class-path. I 
know we can alter the directory where to find the library (with 
) but the name I can't find any information?

Thanks for your time.

Tomas

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

Re: Maven2 Eclipse Plugin - ordering of .classpath entries

[nicolas de loof]

I get a similar issue, but using "StandardVMType/J2SE-1.5" as JRE container
on a JDK 6.0

This creates (unmodifiable) allowed/forbidden acces rules on eclipse
classpath. As the JRE is first in library ordering, I cannot include jax-ws
API that is allways resolved as "forbidden".

Having any hook to force the javax.ws* libs first solves this...

Maybe the eclipse plugin could detect java* and javax* groupIds and force
them as toplevel ?

This would require :

- improve EclipseConfigWriter to have a new getJavaApiDeps(), and remove
those deps from getDepsOrdered
- improve EclipseClasspathWriter to write getJavaApiDeps prior to the JRE
container.

Could you create a Jira issue for this ?

Nico.



2008/4/16, Patrick Zeising <[EMAIL PROTECTED]>:
>
>
> Hi everybody,
>
> I am using Maven2 with the Maven2 Eclipse plugin and in my project I would
> like to use a newer version of JaxWS (https://jax-ws.dev.java.net/) than
> the
> one supplied with JDK6. When using the eclipse goal ($> mvn
> eclipse:eclipse)
> the generated .classpath file in my project directory contains all
> relevant
> entries headed by the entry for the JRE container.
>
> ---CODE---
> 
>   
>   
>path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
>path="M2_REPO/commons-lang/commons-lang/2.3/commons-lang-2.3.jar"
>
> sourcepath="M2_REPO/commons-lang/commons-lang/2.3/commons-lang-2.3-sources.jar"/>
>   
>path="M2_REPO/dev/java/net/jaxws-api/2.1.1/jaxws-api-2.1.1.jar"/>
>   
>path="M2_REPO/commons-logging/commons-logging/1.1/commons-logging-1.1.jar"
>
> sourcepath="M2_REPO/commons-logging/commons-logging/1.1/commons-logging-1.1-sources.jar"/>
> 
> ---/CODE---
>
> As long as the JRE_CONTAINER is mentioned and loaded first my project will
> not compile in Eclipse. When I set the order of the classpath entries in
> Eclipse (Properties - Java Build Path - Order and Export, setting the
> entry
> for JRE_CONTAINER to the 'bottom') my project will compile.
>
> Is there a way to control the order in which these classpath entries (and
> the one for the JRE_CONTAINER in particular) are written to the .classpath
> file? Is there a better way to do what I'm trying to do? ;)
>
> Thx
> Patrick
>
> --
> View this message in context:
> http://www.nabble.com/Maven2-Eclipse-Plugin---ordering-of-.classpath-entries-tp16722527s177p16722527.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]
>
>

Maven2 Eclipse Plugin - ordering of .classpath entries

[Patrick Zeising]

Hi everybody,

I am using Maven2 with the Maven2 Eclipse plugin and in my project I would
like to use a newer version of JaxWS (https://jax-ws.dev.java.net/) than the
one supplied with JDK6. When using the eclipse goal ($> mvn eclipse:eclipse)
the generated .classpath file in my project directory contains all relevant
entries headed by the entry for the JRE container.

---CODE---

  
  
  
  
  
  
  
  

---/CODE---

As long as the JRE_CONTAINER is mentioned and loaded first my project will
not compile in Eclipse. When I set the order of the classpath entries in
Eclipse (Properties - Java Build Path - Order and Export, setting the entry
for JRE_CONTAINER to the 'bottom') my project will compile.

Is there a way to control the order in which these classpath entries (and
the one for the JRE_CONTAINER in particular) are written to the .classpath
file? Is there a better way to do what I'm trying to do? ;)

Thx
Patrick
-- 
View this message in context: 
http://www.nabble.com/Maven2-Eclipse-Plugin---ordering-of-.classpath-entries-tp16722527s177p16722527.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]

RE: classpath property

[Bernhard David]

Hello,

in a plugin, you can get the classpath like this:

/**
* The project we are dealing with.
* @parameter expression="${project}"
*/
private MavenProject m_project;


List classPath = m_project.getRuntimeClasspathElements();


Greetings,

David

> -Original Message-
> From: Eric White [mailto:[EMAIL PROTECTED] 
> Sent: 15 April 2008 21:46
> To: users@maven.apache.org
> Subject: classpath property
> 
> 
> Is there a plain old maven property equivalent to the antrun
> maven.runtime.classpath reference?
> I need to filter some resources I'm adding to an assembly, 
> and really don't
> want to take the long way around with antrun if I can get 
> there directly.
> Thanks!
> -- 
> View this message in context: 
> http://www.nabble.com/classpath-property-tp16706768s177p16706768.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]

classpath property

[Eric White]

Is there a plain old maven property equivalent to the antrun
maven.runtime.classpath reference?
I need to filter some resources I'm adding to an assembly, and really don't
want to take the long way around with antrun if I can get there directly.
Thanks!
-- 
View this message in context: 
http://www.nabble.com/classpath-property-tp16706768s177p16706768.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]

Re: How can I add a directory to the classpath to run JUnit tests in the command line?

[Jared Blitzstein]

Answered my own question I think, I did it via the POM


  org.apache.maven.plugins
  maven-surefire-plugin
  2.4.2  


src/main/webapp/WEB-INF/additionalClasspathElement>


  


However, my tests don't seem to be returning. I can see it execute the  
first one, then just sit there.


On Apr 15, 2008, at 12:21 PM, Jared Blitzstein wrote:

I'm doing a demo app using JUnit 4 and Spring annotations and having  
some trouble getting maven to run my tests. They launch and run  
correctly in eclipse, but mvn test cannot find my xml context files  
because they're not on the classpath (they're in /webapp/WEB-INF/)  
and my JUnit test is using @ContextConfiguration(locations = { "/ 
todo-application-context.xml", "/todo-data.xml" }). I saw  
maven.plugin.classpath and maven.test.classpath (though it seems  
maven 1.x) and launching via "mvn test -Dmaven.plugin.classpath=/src/ 
main/webapp/WEB-INF/" (i've tried the absolute path too) but it's  
still giving me a FileNotFound exception on my *.xml files. Any ideas?

How can I add a directory to the classpath to run JUnit tests in the command line?

[Jared Blitzstein]

I'm doing a demo app using JUnit 4 and Spring annotations and having  
some trouble getting maven to run my tests. They launch and run  
correctly in eclipse, but mvn test cannot find my xml context files  
because they're not on the classpath (they're in /webapp/WEB-INF/) and  
my JUnit test is using @ContextConfiguration(locations = { "/todo- 
application-context.xml", "/todo-data.xml" }). I saw  
maven.plugin.classpath and maven.test.classpath (though it seems maven  
1.x) and launching via "mvn test -Dmaven.plugin.classpath=/src/main/ 
webapp/WEB-INF/" (i've tried the absolute path too) but it's still  
giving me a FileNotFound exception on my *.xml files. Any ideas?


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

Unit Testing with SureFire Classpath settings

[Kristan Uccello]

Hello,

I am trying to specify the Sure Fire "additionalClasspathElements
Additional elements to be appended to the classpath." and being a
Maven2 newbe I am a bit lost when I'm told to set the plugin values as
a java.util.List.

=== FROM: http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
"...
additionalClasspathElements  Additional elements to be appended to the
classpath.

* Type: java.util.List
* Required: No
..."

=

I have gotten this far in setting up my POM

[The rest of my pom is fine]
...
 
org.apache.maven.plugins
maven-surefire-plugin


?


  
...

It is unclear to me what I am supposed to do to represent the
java.util.List of additional Class path elements here? Is it a comma
delimited list? or do I define it another way?
Some help here would be greatly appreciated

Cheers,

Kristan "Krispy" Uccello

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

RE: Classpath Loader Differences between Surefire 2.3 and 2.4 causes tests to fail

[Andreas Guther]

The solution to the problem is to configure Surefire 2.4.2 to not use
the System Classloader,
i.e in the following way:

false

Or in more details:


 
2.4.2
5.7




org.apache.maven.plugins
maven-surefire-plugin
 
${maven-surefire-plugin-version}

 
false





Dan Fabulich explained to me that this was the default behavior in
Surefire 2.3 and that it was reversed in Surefire 2.4.  



-Original Message-
From: Andreas Guther [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 07, 2008 12:07 PM
To: Maven Users List
Subject: Classpath Loader Differences between Surefire 2.3 and 2.4
causes tests to fail

Hi,

We see a difference in classpath loading between Surefire 2.3 and 2.4.  

If we run the attached test against Surefire 2.3 and TestNG 5.1 we get
the following output:

mvn test -Pthree

---
 T E S T S
---
Running ShowClassPathTest
On my
path:file:/C:/dev/svn.markettools.com/repos/dev/projects/problem/target/
test-classes/
On my
path:file:/c:/m2/repo1/commons-collections/commons-collections/3.1/commo
ns-collections-3.1.jar
On my
path:file:/C:/dev/svn.markettools.com/repos/dev/projects/problem/target/
classes/
On my
path:file:/c:/m2/repo1/commons-io/commons-io/1.2/commons-io-1.2.jar
On my path:file:/c:/m2/repo1/org/testng/testng/5.1/testng-5.1-jdk15.jar
Number of elemenst on my path:5
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031
sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0


If we run the same test with Surefire 2.4 and TestNG 5.7 we get a
totally different classpath:

mvn test -Pfour

---
 T E S T S
---
Running TestSuite
[Parser] Running:
  Command line suite

On my
path:file:/C:/Documents%20and%20Settings/aguther/Local%20Settings/Temp/s
urefirebooter7279.jar
On my path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/sunpkcs11.jar
On my path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/dnsns.jar
On my
path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/sunjce_provider.jar
On my
path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/localedata.jar
Number of elemenst on my path:5
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.235
sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0


Obviously in the second case none of the dependencies or compile
directories are available.

The different behavior gives us problems with the Web Framework we use
(Stripes 1.4) and the associated tests which are not able to find any
classes under Surefire 2.4.  Stripes uses the following line to load the
classes: ClassLoader loader =
Thread.currentThread().getContextClassLoader();


Does anyone have an idea how to solve this issue and get the classes
back on the path under Surefire 2.4?

Thanks in advance for any help.

Andreas




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

Re: Classpath Loader Differences between Surefire 2.3 and 2.4 causes tests to fail

[Dan Fabulich]

Andreas Guther wrote:


Does anyone have an idea how to solve this issue and get the classes
back on the path under Surefire 2.4?


This is a somewhat frequently asked question, so I've written a wiki 
article about it:


http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+Surefire

Executive summary: useSystemClassLoader changed between Surefire 2.3 and 
Surefire 2.4. The default was useSystemClassLoader=false, but now the 
default is useSystemClassLoader=true. If you're having problems, try 
turning it back off to see if that helps.




I've also written another article about classpath ordering (not relevant 
to you, but it has come up a few times):


http://docs.codehaus.org/display/MAVENUSER/Classpath+Ordering+Bugs+in+Maven+Surefire

-Dan

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

Re: Classpath Loader Differences between Surefire 2.3 and 2.4 causes tests to fail

[Martin Höller]

On Monday 07 April 2008 Andreas Guther wrote:
> We see a difference in classpath loading between Surefire 2.3 and 2.4.

Search the archive of this list on nabble.com for "surefire 2.4 classpath" 
and you'll find your answer. Note, that there was a bug in maven 2.0.7, so 
updating to a newer maven version might be necessary.

hth,
- martin


signature.asc
Description: This is a digitally signed message part.

Classpath Loader Differences between Surefire 2.3 and 2.4 causes tests to fail

[Andreas Guther]

Hi,

We see a difference in classpath loading between Surefire 2.3 and 2.4.  

If we run the attached test against Surefire 2.3 and TestNG 5.1 we get
the following output:

mvn test -Pthree

---
 T E S T S
---
Running ShowClassPathTest
On my
path:file:/C:/dev/svn.markettools.com/repos/dev/projects/problem/target/
test-classes/
On my
path:file:/c:/m2/repo1/commons-collections/commons-collections/3.1/commo
ns-collections-3.1.jar
On my
path:file:/C:/dev/svn.markettools.com/repos/dev/projects/problem/target/
classes/
On my
path:file:/c:/m2/repo1/commons-io/commons-io/1.2/commons-io-1.2.jar
On my path:file:/c:/m2/repo1/org/testng/testng/5.1/testng-5.1-jdk15.jar
Number of elemenst on my path:5
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031
sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0


If we run the same test with Surefire 2.4 and TestNG 5.7 we get a
totally different classpath:

mvn test -Pfour

---
 T E S T S
---
Running TestSuite
[Parser] Running:
  Command line suite

On my
path:file:/C:/Documents%20and%20Settings/aguther/Local%20Settings/Temp/s
urefirebooter7279.jar
On my path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/sunpkcs11.jar
On my path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/dnsns.jar
On my
path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/sunjce_provider.jar
On my
path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/localedata.jar
Number of elemenst on my path:5
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.235
sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0


Obviously in the second case none of the dependencies or compile
directories are available.

The different behavior gives us problems with the Web Framework we use
(Stripes 1.4) and the associated tests which are not able to find any
classes under Surefire 2.4.  Stripes uses the following line to load the
classes: ClassLoader loader =
Thread.currentThread().getContextClassLoader();


Does anyone have an idea how to solve this issue and get the classes
back on the path under Surefire 2.4?

Thanks in advance for any help.

Andreas



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/maven-v4_0_0.xsd";>
4.0.0
classloader.problem
problem
1.0-SNAPSHOT
Archetype - problem
http://maven.apache.org



org.testng
testng
${testing-testng-version}
test
jdk15


commons-collections
commons-collections
3.1


commons-io
commons-io
1.2






org.apache.maven.plugins
maven-surefire-plugin
${maven-surefire-plugin-version}






three

2.3.1
5.1



four

2.4.2
5.7




org.apache.maven.plugins
maven-surefire-plugin

true
pertest
-enableassertions







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

Re: antrun plugin - GWT - add the source directory to the classpath [resolved]

[Bernard Lupin]

Please excuse me Nicolas, I was certainly speaking about another maven
plugin, I'll try your link asap.

Returning to my initial problem, I've found a solution to add a directory to
the maven dependencies, which could be useful for other purposes.

The key is to use the  available inside the  tag. So
here is my antrun plugin configuration :




org.apache.maven.plugins
maven-antrun-plugin




com.company.gwt.tools


ant-compile
1.0
compile






com.company.project

gwt-exemple
1.0
system

src/main/java




process-classes

run






















nicolas de loof-3 wrote:
> 
> Such a suggestion should be made to GWT development team !
> 
> As the GWT compilation process is complex (read modules XML, find client
> code and referenced objets...), there is no simple way to know some
> modified
> java source file requires a GWT recompilation...
> 
> The javac compiler is also executed on every build but is fine enough not
> to
> recompile up-to-date classes.
> 
> 
> The issue I was talking about is that the initial GWT Mojo did not avoid
> the
> GWTCompiler to System.exit() during the build. Do you speak from
> http://mojo.codehaus.org/gwt-maven-plugin/ ? I didn't notice this
> classpath
> error, could you report an issue with a test project ?
> 
> Nicolas.
> 
> 
> 2008/4/1, Bernard Lupin <[EMAIL PROTECTED]>:
>>
>>
>> Hi Nicolas,
>> We're already using the gwt-maven-plugin (perhaps the issue your talking
>> about is a "classpath too long problem", comming from my colleague ;-)).
>>
>> But an important improvement for us would be a plugin launching the GWT
>> compilation only if there are changes in java source code. Is it planed ?
>> Do
>> I have to make this suggestion somewhere ?
>> Kind regards,
>> Bernard
>>
>>
>>
>>
>> nicolas de loof-3 wrote:
>> >
>> > Can I suggest you to test the Mojo-sandbox gwt-maven-plugin ?
>> >
>> > I just upgrade it to fix GWTCompiler issue, and it now comes with a DTO
>> > generator from JPA entities.
>> >
>> > Some dependencies are not yet available in central, but the MAVENUPLOAD
>> > request is created for them.
>> >
>> > Nicolas.
>> >
>> > 2008/3/31, Bernard Lupin <[EMAIL PROTECTED]>:
>> >>
>> >>
>> >> Hi all,
>> >> Using the antrun plugin, I'm trying to call an ant task which is
>> >> launching
>> >> the GWT compiler. This ant task is based on the Joachim work at
>> >> http://braindump.dk/tech/gwt-task-for-ant/.
>> >>
>> >> Something specific with GWT is

Re: Classpath for mojo

[nicolas de loof]

Take a look at
http://svn.codehaus.org/mojo/trunk/sandbox/gwt-maven-plugin/src/main/java/org/codehaus/mojo/gwt/CompileMojo.java

The "addProjectClasspathElements" method creates the set of URL to be used
by an URLClassLoader.

Nicolas.


2008/4/1, Timothy Reilly <[EMAIL PROTECTED]>:
>
> Can anyone tell me the "best" way to get the project classpath from with
> a plug-in including transitive dependencies?
>
> I've tried mavenProject.getCompileClasspath() but it doesn't seem to
> have the transitive deps
> Some problem with mavenProject.getDependencies()
>
> I think I need mavenProject.getArtifacts() but how do I resolve this to
> paths to the local repository?
> Am I missing something much simpler like a component or property I can
> just use?
>

Classpath for mojo

[Timothy Reilly]

Can anyone tell me the "best" way to get the project classpath from with
a plug-in including transitive dependencies?
 
I've tried mavenProject.getCompileClasspath() but it doesn't seem to
have the transitive deps
Some problem with mavenProject.getDependencies()
 
I think I need mavenProject.getArtifacts() but how do I resolve this to
paths to the local repository? 
Am I missing something much simpler like a component or property I can
just use?

Re: antrun plugin - GWT - add the source directory to the classpath

[nicolas de loof]

Such a suggestion should be made to GWT development team !

As the GWT compilation process is complex (read modules XML, find client
code and referenced objets...), there is no simple way to know some modified
java source file requires a GWT recompilation...

The javac compiler is also executed on every build but is fine enough not to
recompile up-to-date classes.


The issue I was talking about is that the initial GWT Mojo did not avoid the
GWTCompiler to System.exit() during the build. Do you speak from
http://mojo.codehaus.org/gwt-maven-plugin/ ? I didn't notice this classpath
error, could you report an issue with a test project ?

Nicolas.


2008/4/1, Bernard Lupin <[EMAIL PROTECTED]>:
>
>
> Hi Nicolas,
> We're already using the gwt-maven-plugin (perhaps the issue your talking
> about is a "classpath too long problem", comming from my colleague ;-)).
>
> But an important improvement for us would be a plugin launching the GWT
> compilation only if there are changes in java source code. Is it planed ?
> Do
> I have to make this suggestion somewhere ?
> Kind regards,
> Bernard
>
>
>
>
> nicolas de loof-3 wrote:
> >
> > Can I suggest you to test the Mojo-sandbox gwt-maven-plugin ?
> >
> > I just upgrade it to fix GWTCompiler issue, and it now comes with a DTO
> > generator from JPA entities.
> >
> > Some dependencies are not yet available in central, but the MAVENUPLOAD
> > request is created for them.
> >
> > Nicolas.
> >
> > 2008/3/31, Bernard Lupin <[EMAIL PROTECTED]>:
> >>
> >>
> >> Hi all,
> >> Using the antrun plugin, I'm trying to call an ant task which is
> >> launching
> >> the GWT compiler. This ant task is based on the Joachim work at
> >> http://braindump.dk/tech/gwt-task-for-ant/.
> >>
> >> Something specific with GWT is that you must include the java source
> >> directory in your classpath before calling the compiler.
> Unfortunatelly,
> >> I
> >> can add all the needed jars in my classpath (gwt-user.jar,
> >> gwt-dev-windows.jar, my ant-compile.jar ) using dependencies, but I
> don't
> >> know how to add my source directory.
> >>
> >> I tried to build an ant reference classpath with the
> >> maven.plugin.classpath
> >> reference and the ${project.build.sourceDirectory} variable, but in all
> >> cases my java task tells me "Unable to find
> >> 'com/company/gwt/MyModule.gwt.xml'.
> >>
> >> I also tried to put all my java source files inside a jar and add the
> >> corresponding dependency, in that case the GWT compilation works ! (but
> >> it
> >> can't be a workarround, you agree ?).
> >>
> >> So my question is : Does Maven provide a solution to add a directory to
> >> the
> >> maven.plugin.classpath ?
> >>
> >> Below is my pom.xml
> >>
> >> 
> >> 
> >>   4.0.0
> >>   com.company.exemple
> >>   gwt-maven
> >>   war
> >>   GWT Maven example
> >>   1.0-SNAPSHOT
> >>   http://maven.apache.org
> >>
> >>   
> >> 
> >>   
> >> org.apache.maven.plugins
> >> maven-compiler-plugin
> >> 
> >>   1.5
> >>   1.5
> >> 
> >>   
> >>
> >>   
> >> org.apache.maven.plugins
> >> maven-antrun-plugin
> >> 
> >>   
> >> com.google.gwt
> >> gwt-dev-windows
> >> 1.4.61
> >> compile
> >>   
> >>   
> >> com.company.gwt
> >> ant-compile
> >> 1.0-SNAPSHOT
> >> compile
> >>   
> >> 
> >> 
> >>   
> >> process-classes
> >> 
> >>   run
> >> 
> >> 
> >>   
> >>  >>   value="${project.build.sourceDirectory}" />
> >>  >> />
> >>  >> refid="maven.plugin.classpath" />
> >> 
> >> 
> >>/>
> >>   
> >>     
> >>
> >>  >>
> >> classnam

Re: antrun plugin - GWT - add the source directory to the classpath

[Bernard Lupin]

Hi Nicolas,
We're already using the gwt-maven-plugin (perhaps the issue your talking
about is a "classpath too long problem", comming from my colleague ;-)). 

But an important improvement for us would be a plugin launching the GWT
compilation only if there are changes in java source code. Is it planed ? Do
I have to make this suggestion somewhere ?
Kind regards,
Bernard



nicolas de loof-3 wrote:
> 
> Can I suggest you to test the Mojo-sandbox gwt-maven-plugin ?
> 
> I just upgrade it to fix GWTCompiler issue, and it now comes with a DTO
> generator from JPA entities.
> 
> Some dependencies are not yet available in central, but the MAVENUPLOAD
> request is created for them.
> 
> Nicolas.
> 
> 2008/3/31, Bernard Lupin <[EMAIL PROTECTED]>:
>>
>>
>> Hi all,
>> Using the antrun plugin, I'm trying to call an ant task which is
>> launching
>> the GWT compiler. This ant task is based on the Joachim work at
>> http://braindump.dk/tech/gwt-task-for-ant/.
>>
>> Something specific with GWT is that you must include the java source
>> directory in your classpath before calling the compiler. Unfortunatelly,
>> I
>> can add all the needed jars in my classpath (gwt-user.jar,
>> gwt-dev-windows.jar, my ant-compile.jar ) using dependencies, but I don't
>> know how to add my source directory.
>>
>> I tried to build an ant reference classpath with the
>> maven.plugin.classpath
>> reference and the ${project.build.sourceDirectory} variable, but in all
>> cases my java task tells me "Unable to find
>> 'com/company/gwt/MyModule.gwt.xml'.
>>
>> I also tried to put all my java source files inside a jar and add the
>> corresponding dependency, in that case the GWT compilation works ! (but
>> it
>> can't be a workarround, you agree ?).
>>
>> So my question is : Does Maven provide a solution to add a directory to
>> the
>> maven.plugin.classpath ?
>>
>> Below is my pom.xml
>>
>> 
>> 
>>   4.0.0
>>   com.company.exemple
>>   gwt-maven
>>   war
>>   GWT Maven example
>>   1.0-SNAPSHOT
>>   http://maven.apache.org
>>
>>   
>> 
>>   
>> org.apache.maven.plugins
>> maven-compiler-plugin
>> 
>>   1.5
>>   1.5
>> 
>>   
>>
>>   
>> org.apache.maven.plugins
>> maven-antrun-plugin
>> 
>>   
>> com.google.gwt
>> gwt-dev-windows
>> 1.4.61
>> compile
>>   
>>   
>> com.company.gwt
>> ant-compile
>> 1.0-SNAPSHOT
>> compile
>>   
>> 
>> 
>>   
>> process-classes
>> 
>>   run
>> 
>> 
>>   
>> >   value="${project.build.sourceDirectory}" />
>> > />
>> > refid="maven.plugin.classpath" />
>> 
>> 
>>   
>>   
>> 
>>
>> >
>> classname="com.francetelecom.clara.tool.gwt.GWTCompileTask"
>>   classpathref="my.classpath" />
>> > style="obfuscated">
>>   
>> 
>>   
>> 
>>   
>> 
>>   
>> 
>>   
>> 
>>   
>>
>>   
>>
>> 
>> 
>>   com.google.gwt
>>   gwt-user
>>   1.4.61
>>   compile
>> 
>>
>> 
>>   com.google.gwt
>>   gwt-servlet
>>   1.4.61
>>   runtime
>> 
>>
>> 
>> 
>>   javax.servlet
>>   servlet-api
>>   2.4
>>   provided
>> 
>>
>> 
>>   javax.servlet.jsp
>>   jsp-api
>>   2.1
>>   provided
>> 
>>
>>   
>>
>> 
>>
> 

-- 
View this message in context: 
http://www.nabble.com/antrun-plugin---GWT---add-the-source-directory-to-the-classpath-tp16396056s177p16418428.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]

Classpath issues for mvn:exec

[Thomas Larsson]

Hello,

This is probably most related to how to specify the classpath to the
mvn:exec plugin.

I have a project that needs to do some setup before its test are run.
These setup tasks are doing use the mvn exec plugin that is configured to
run during the test-compile phase.

However, I also want to run cobertura and then I run into problems.

It seems that I have to declare a compile time dependency on cobertura to
have the mvn:exec plugin find
the cobertura classes. I use the  configuration option.
Isnt there anyway to do this without having to declare a compile time
dependency on cobertura?

Best Regards
-Thomas

Re: antrun plugin - GWT - add the source directory to the classpath

[nicolas de loof]

Can I suggest you to test the Mojo-sandbox gwt-maven-plugin ?

I just upgrade it to fix GWTCompiler issue, and it now comes with a DTO
generator from JPA entities.

Some dependencies are not yet available in central, but the MAVENUPLOAD
request is created for them.

Nicolas.

2008/3/31, Bernard Lupin <[EMAIL PROTECTED]>:
>
>
> Hi all,
> Using the antrun plugin, I'm trying to call an ant task which is launching
> the GWT compiler. This ant task is based on the Joachim work at
> http://braindump.dk/tech/gwt-task-for-ant/.
>
> Something specific with GWT is that you must include the java source
> directory in your classpath before calling the compiler. Unfortunatelly, I
> can add all the needed jars in my classpath (gwt-user.jar,
> gwt-dev-windows.jar, my ant-compile.jar ) using dependencies, but I don't
> know how to add my source directory.
>
> I tried to build an ant reference classpath with the
> maven.plugin.classpath
> reference and the ${project.build.sourceDirectory} variable, but in all
> cases my java task tells me "Unable to find
> 'com/company/gwt/MyModule.gwt.xml'.
>
> I also tried to put all my java source files inside a jar and add the
> corresponding dependency, in that case the GWT compilation works ! (but it
> can't be a workarround, you agree ?).
>
> So my question is : Does Maven provide a solution to add a directory to
> the
> maven.plugin.classpath ?
>
> Below is my pom.xml
>
> 
> 
>   4.0.0
>   com.company.exemple
>   gwt-maven
>   war
>   GWT Maven example
>   1.0-SNAPSHOT
>   http://maven.apache.org
>
>   
> 
>   
> org.apache.maven.plugins
> maven-compiler-plugin
> 
>   1.5
>   1.5
> 
>   
>
>   
> org.apache.maven.plugins
> maven-antrun-plugin
> 
>   
> com.google.gwt
> gwt-dev-windows
> 1.4.61
> compile
>   
>   
> com.company.gwt
> ant-compile
> 1.0-SNAPSHOT
> compile
>   
> 
> 
>   
> process-classes
> 
>   run
> 
> 
>   
>value="${project.build.sourceDirectory}" />
>  />
>  refid="maven.plugin.classpath" />
> 
> 
>   
>   
> 
>
> 
> classname="com.francetelecom.clara.tool.gwt.GWTCompileTask"
>   classpathref="my.classpath" />
>  style="obfuscated">
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
>
>   
>
> 
> 
>   com.google.gwt
>   gwt-user
>   1.4.61
>   compile
> 
>
> 
>   com.google.gwt
>   gwt-servlet
>   1.4.61
>   runtime
> 
>
> 
> 
>   javax.servlet
>   servlet-api
>   2.4
>   provided
> 
>
> 
>   javax.servlet.jsp
>   jsp-api
>   2.1
>   provided
> 
>
>   
>
> 
>
> --
> View this message in context:
> http://www.nabble.com/antrun-plugin---GWT---add-the-source-directory-to-the-classpath-tp16396056s177p16396056.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]
>
>

antrun plugin - GWT - add the source directory to the classpath

[Bernard Lupin]

Hi all,
Using the antrun plugin, I'm trying to call an ant task which is launching
the GWT compiler. This ant task is based on the Joachim work at
http://braindump.dk/tech/gwt-task-for-ant/.

Something specific with GWT is that you must include the java source
directory in your classpath before calling the compiler. Unfortunatelly, I
can add all the needed jars in my classpath (gwt-user.jar,
gwt-dev-windows.jar, my ant-compile.jar ) using dependencies, but I don't
know how to add my source directory.

I tried to build an ant reference classpath with the maven.plugin.classpath
reference and the ${project.build.sourceDirectory} variable, but in all
cases my java task tells me "Unable to find
'com/company/gwt/MyModule.gwt.xml'.

I also tried to put all my java source files inside a jar and add the
corresponding dependency, in that case the GWT compilation works ! (but it
can't be a workarround, you agree ?).

So my question is : Does Maven provide a solution to add a directory to the
maven.plugin.classpath ?

Below is my pom.xml



  4.0.0
  com.company.exemple
  gwt-maven
  war
  GWT Maven example
  1.0-SNAPSHOT
  http://maven.apache.org

  

  
org.apache.maven.plugins
maven-compiler-plugin

  1.5
  1.5

  

  
org.apache.maven.plugins
maven-antrun-plugin

  
com.google.gwt
gwt-dev-windows
1.4.61
compile
  
  
com.company.gwt
ant-compile
1.0-SNAPSHOT
compile
  


  
process-classes

  run


  





  
  




  

  

  

  

  

  

  



  com.google.gwt
  gwt-user
  1.4.61
  compile



  com.google.gwt
  gwt-servlet
  1.4.61
  runtime




  javax.servlet
  servlet-api
  2.4
  provided



  javax.servlet.jsp
  jsp-api
  2.1
  provided


  


-- 
View this message in context: 
http://www.nabble.com/antrun-plugin---GWT---add-the-source-directory-to-the-classpath-tp16396056s177p16396056.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]

eclipse classpath

[James Clinton]

I'd like to change the output directory of the eclipse classpath.

 

mvn eclipse:eclipse defaults to /target/classes

 

Is this possible?

DISCLAIMER: This e-mail is confidential and may also be legally privileged. If 
you are not the intended recipient, use of the information contained in this 
e-mail (including disclosure, copying or distribution) is prohibited and may be 
unlawful.  Please inform the sender and delete the message immediately from 
your system.  This e-mail is attributed to the sender and may not necessarily 
reflect the views of the Patsystems Group and no member of the Patsystems Group 
accepts any liability for any action taken in reliance on the contents of this 
e-mail (other than where it has a legalor regulatory obligation to do so) or 
for the consequences of any computer viruses which may have been transmitted by 
this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary 
group of companies. Thank You For your Co Opeation

Problems to include test-jar in the classpath

[Oznix80]

Hello,

 

 

When I try to create a test-jar that depends of another test-jar
I can’t  include this second test-jar in the first.

I put the second test-jar in the pom.xml of the first as
test-jartest but the manifest built by maven do
not include this jar (of course in the manifest appear all the others ¡ars
needed).

I’m starting to work with maven, I appreciate your help and your
time.

 

Regards,

Re: Add .classes to compilation classpath

[dynnamitt]

Hi 

I managed alter the classpath like this:


./src/main/webapp/WEB-INF/lib/cocoon-2.1.11.jar${path.separator}./src/main/webapp/WEB-INF/lib/avalon-framework-api-4.3.jar

BIG ISSUE: Now maven cannot find the test-scope jars added as "normal"
dependencies.

Regards,
Dynnamitt


Georges Ravel wrote:
> 
> 
> Hi everybody,
> 
> I'm new to maven. I have a simple question that I can't find an answer
> anywhere:
> I want to include additional classes in the classpath while compiling my
> project
> but I can't find any
> obvious solution for this.
> 
> - The classes I want to include can not be installed in a maven repository
> - I tried the compiler plugin by adding
>true
> 
> myDic/classes
> 
> but this doesn't seem to work.
> 
> Any suggestions?
> Thanks
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Add-.classes-to-compilation-classpath-tp15824912s177p16090932.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]

Re: M2 Classpath issue

[ben short]

Wayne,

Thanks for pointing this out.

Regards

Ben Short

On Thu, Mar 13, 2008 at 2:39 PM, Wayne Fay <[EMAIL PROTECTED]> wrote:
> This has come up several times on this list, as recently as a week
>  ago, and people have discussed strategies for dealing with it etc. One
>  thread in particular you will want to read is:
>  date  Mar 5, 2008 5:07 PM
>  subject  java.class.path and the surefire-plugin
>
>  For more info, go to Nabble.com and search the list archives for
>  java.class.path.
>
>  Wayne
>
>
>
>  On 3/13/08, ben short <[EMAIL PROTECTED]> wrote:
>  > Hi,
>  >
>  > I am adding some Unit tests to a legacy application before I make any 
> changes.
>  >
>  > As part of the tests I start the application. When the application
>  > starts it scans all the classes on the classpath. Unfortunately the
>  > only jar on the classpath is the classworlds.jar due to the way maven
>  > handles dependencies. The application will use a system property
>  > called java.class.path if present. So I have configured the surefire
>  > plugin as shown below.
>  >
>  > 
>  >org.apache.maven.plugins
>  >maven-surefire-plugin
>  >2.3
>  >
>  >
>  > ${basedir}\target\test-classes
>  >
>  >
>  >java.class.path
>  >${project.testClasspathElements}
>  >
>  >
>  >
>  >nexusalpha/**/*Tests*
>  >
>  >
>  >
>  > 
> nexusalpha/jaf2/services/webservice/AlertServerWebServiceTests*.java
>  >
>  >brief
>  >false
>  >false
>  >
>  >
>  >
>  > Unfortunately when i run the tests the application prints that the
>  > value for the system property java.class.path is
>  > ${project.testClasspathElements}. So it seems that maven is not
>  > filtering this property correctly.
>  >
>  > As a quick test i added ${project.testClasspathElements} to the
>  > workingDirectory element I see that maven complains that the
>  > workingDirectory is not valid and on inspection i see that the
>  > projects dependencies are listed correctly.
>  >
>  > Can anyone help me out with this? I'm using maven 2.0.8.
>  >
>  > Regards
>  >
>  > Ben Short
>  >
>  > -
>  > 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]
>
>

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

Re: M2 Classpath issue

[Wayne Fay]

This has come up several times on this list, as recently as a week
ago, and people have discussed strategies for dealing with it etc. One
thread in particular you will want to read is:
date  Mar 5, 2008 5:07 PM
subject  java.class.path and the surefire-plugin

For more info, go to Nabble.com and search the list archives for
java.class.path.

Wayne

On 3/13/08, ben short <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am adding some Unit tests to a legacy application before I make any changes.
>
> As part of the tests I start the application. When the application
> starts it scans all the classes on the classpath. Unfortunately the
> only jar on the classpath is the classworlds.jar due to the way maven
> handles dependencies. The application will use a system property
> called java.class.path if present. So I have configured the surefire
> plugin as shown below.
>
> 
>org.apache.maven.plugins
>maven-surefire-plugin
>2.3
>
>
> ${basedir}\target\test-classes
>
>
>java.class.path
>${project.testClasspathElements}
>
>
>
>nexusalpha/**/*Tests*
>
>
>
> nexusalpha/jaf2/services/webservice/AlertServerWebServiceTests*.java
>
>brief
>false
>false
>
>
>
> Unfortunately when i run the tests the application prints that the
> value for the system property java.class.path is
> ${project.testClasspathElements}. So it seems that maven is not
> filtering this property correctly.
>
> As a quick test i added ${project.testClasspathElements} to the
> workingDirectory element I see that maven complains that the
> workingDirectory is not valid and on inspection i see that the
> projects dependencies are listed correctly.
>
> Can anyone help me out with this? I'm using maven 2.0.8.
>
> Regards
>
> Ben Short
>
> -
> 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]

M2 Classpath issue

[ben short]

Hi,

I am adding some Unit tests to a legacy application before I make any changes.

As part of the tests I start the application. When the application
starts it scans all the classes on the classpath. Unfortunately the
only jar on the classpath is the classworlds.jar due to the way maven
handles dependencies. The application will use a system property
called java.class.path if present. So I have configured the surefire
plugin as shown below.


org.apache.maven.plugins
maven-surefire-plugin
2.3


${basedir}\target\test-classes


java.class.path
${project.testClasspathElements}



nexusalpha/**/*Tests*



nexusalpha/jaf2/services/webservice/AlertServerWebServiceTests*.java

brief
false
false



Unfortunately when i run the tests the application prints that the
value for the system property java.class.path is
${project.testClasspathElements}. So it seems that maven is not
filtering this property correctly.

As a quick test i added ${project.testClasspathElements} to the
workingDirectory element I see that maven complains that the
workingDirectory is not valid and on inspection i see that the
projects dependencies are listed correctly.

Can anyone help me out with this? I'm using maven 2.0.8.

Regards

Ben Short

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

Re: Add .classes to compilation classpath

[amit kumar]

Okay. Then you can jar up the classes as told by Simon and
install/deploy(look for command mvn install:install-file... or mvn
deploy:deploy-file...) them to your repository. There are few jar files
which are not outcome of maven projects but yet we are using at out place.
This seems to be the simplest of the options.

On Tue, Mar 4, 2008 at 4:58 PM, <[EMAIL PROTECTED]> wrote:

> Oh sorry,
>
> I meant to include some .class files from some other projects
> which are not maven projects and they can not be easily installed
> as maven packages. I think it would be possible to use ant plugin but it
> should
> be something much simpler I guess?
>
> Thanks
>
>
> Quoting amit kumar <[EMAIL PROTECTED]>:
>
> > I had concept/misconception that target/classes gets added to the
> classpath
> > by maven as default?
> >
> > Are you dealing with generated sources?
> >
> > Regards,
> > Amit
> >
> > On Tue, Mar 4, 2008 at 4:34 PM, <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Hi everybody,
> > >
> > > I'm new to maven. I have a simple question that I can't find an answer
> > > anywhere:
> > > I want to include additional classes in the classpath while compiling
> my
> > > project
> > > but I can't find any
> > > obvious solution for this.
> > >
> > > - The classes I want to include can not be installed in a maven
> repository
> > > - I tried the compiler plugin by adding
> > >   true
> > >
> > >myDic/classes
> > >
> > > but this doesn't seem to work.
> > >
> > > Any suggestions?
> > > Thanks
> > >
> > > -
> > > 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: Add .classes to compilation classpath

[georges . ravel]

Oh sorry,

I meant to include some .class files from some other projects
which are not maven projects and they can not be easily installed
as maven packages. I think it would be possible to use ant plugin but it should
be something much simpler I guess?

Thanks


Quoting amit kumar <[EMAIL PROTECTED]>:

> I had concept/misconception that target/classes gets added to the classpath
> by maven as default?
>
> Are you dealing with generated sources?
>
> Regards,
> Amit
>
> On Tue, Mar 4, 2008 at 4:34 PM, <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi everybody,
> >
> > I'm new to maven. I have a simple question that I can't find an answer
> > anywhere:
> > I want to include additional classes in the classpath while compiling my
> > project
> > but I can't find any
> > obvious solution for this.
> >
> > - The classes I want to include can not be installed in a maven repository
> > - I tried the compiler plugin by adding
> >   true
> >
> >myDic/classes
> >
> > but this doesn't seem to work.
> >
> > Any suggestions?
> > Thanks
> >
> > -
> > 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: Add .classes to compilation classpath

[[EMAIL PROTECTED]]

[EMAIL PROTECTED] schrieb:
> Hi everybody,
>
> I'm new to maven. I have a simple question that I can't find an answer 
> anywhere:
> I want to include additional classes in the classpath while compiling my 
> project
> but I can't find any
> obvious solution for this.
>
> - The classes I want to include can not be installed in a maven repository
> - I tried the compiler plugin by adding
>true
> 
> myDic/classes
> 
> but this doesn't seem to work.
>   
Normally, you put classes into a jarfile, install it in a repository
with a suitable groupId and artifactId, then declare that jar as a
dependency in your pom. Why can't the classes be put into a maven
repository in your case?

Regards, Simon


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

Re: Add .classes to compilation classpath

[amit kumar]

I had concept/misconception that target/classes gets added to the classpath
by maven as default?

Are you dealing with generated sources?

Regards,
Amit

On Tue, Mar 4, 2008 at 4:34 PM, <[EMAIL PROTECTED]> wrote:

>
> Hi everybody,
>
> I'm new to maven. I have a simple question that I can't find an answer
> anywhere:
> I want to include additional classes in the classpath while compiling my
> project
> but I can't find any
> obvious solution for this.
>
> - The classes I want to include can not be installed in a maven repository
> - I tried the compiler plugin by adding
>   true
>
>myDic/classes
>
> but this doesn't seem to work.
>
> Any suggestions?
> Thanks
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Add .classes to compilation classpath

[georges . ravel]

Hi everybody,

I'm new to maven. I have a simple question that I can't find an answer anywhere:
I want to include additional classes in the classpath while compiling my project
but I can't find any
obvious solution for this.

- The classes I want to include can not be installed in a maven repository
- I tried the compiler plugin by adding
   true

myDic/classes

but this doesn't seem to work.

Any suggestions?
Thanks

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

Re: Test classpath problem in multi module project

[VUB Stefan Seidel]

Hi Petr,

I have a default.persistence.properties in the artifact with the EJB3 
abstract test case. There I can specify whatever I like. Also, in the 
jboss in deploy/ejb3.deployer/META-INF there is another 
persistence.properties where I specify the production properties.


Stefan

Petr Nejedly wrote:

Thanks Stefan,

 


Very helpful. Just a question:

 


You said you're using only one persistence.xml for both, testing and
live deployment. How do you specify different Hibernate properties for
those, eg dialect (Oracle vs HSQLDB), auto create schema (on vs off),
etc?

 


Cheers, Petr



The information contained in this email and its attachments is confidential and may be the subject of legal, professional or other privileged information. It is intended only for the named addressees and may not be disclosed to anyone else without consent from On Demand. If you are not the named addressee you must not use, disclose, distribute, copy, print or rely on the contents of this email and should destroy it immediately. Whilst On Demand takes care to protect its systems from electronic virus attack or other harmful event, the firm gives no warranty that this email message (including any attachments to it) is free of any virus or other harmful matter and accepts no responsibility for any loss or damage resulting from the recipient receiving, opening or using it. If you need any further information, please contact the originator of this message on +44 (0)20 7131 6700. Website: www.ondemand.co.uk. Registered Office: 1 Stephen Street, London, W1T 1AL. Registered in the 

UK No.4094951.


This message has been scanned for viruses by BlackSpider MailControl - 
www.blackspider.com




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

Re: Test classpath problem in multi module project

[Petr Nejedly]

Thanks Stefan,

 

Very helpful. Just a question:

 

You said you're using only one persistence.xml for both, testing and
live deployment. How do you specify different Hibernate properties for
those, eg dialect (Oracle vs HSQLDB), auto create schema (on vs off),
etc?

 

Cheers, Petr



The information contained in this email and its attachments is confidential and 
may be the subject of legal, professional or other privileged information. It 
is intended only for the named addressees and may not be disclosed to anyone 
else without consent from On Demand. If you are not the named addressee you 
must not use, disclose, distribute, copy, print or rely on the contents of this 
email and should destroy it immediately. Whilst On Demand takes care to protect 
its systems from electronic virus attack or other harmful event, the firm gives 
no warranty that this email message (including any attachments to it) is free 
of any virus or other harmful matter and accepts no responsibility for any loss 
or damage resulting from the recipient receiving, opening or using it. If you 
need any further information, please contact the originator of this message on 
+44 (0)20 7131 6700. Website: www.ondemand.co.uk. Registered Office: 1 Stephen 
Street, London, W1T 1AL. Registered in the UK No.4094951.

This message has been scanned for viruses by BlackSpider MailControl - 
www.blackspider.com

Re: Retrieving surefire classpath from a test class

[VUB Stefan Seidel]

Yes, that client was just because from within an Maven execution the 
classpath would give me the -client.jar first, but I needed the jar 
without client.


Stefan

Alexander Klimetschek wrote:
Thanks Stefan, nice hack ;-) I didn't know that you can get the Jar file 
via the class resource URL, but it makes sense.


FYI, I made a useful method out of this (I removed the special 
-client.jar replacement):


/**
 * Returns the path to the JAR file that a certain class is located in. 
This only works

 * if the classloader loaded this class from a JAR file.
 */
public static final String getJarFileForClass(Class clazz) {
// eg. /org/apache/derby/drda/NetworkServerControl.class
String classResource = "/" + clazz.getCanonicalName().replace(".", 
"/") + ".class";
// eg. 
jar:file:/Users/alex/.m2/repository/org/apache/derby/derbynet/10.2.1.6/derbynet-10.2.1.6.jar!/org/apache/derby/drda/NetworkServerControl.class 


String fullResourceURL = clazz.getResource(classResource).toString();
// eg. 
/Users/alex/.m2/repository/org/apache/derby/derbynet/10.2.1.6/derbynet-10.2.1.6.jar 


return fullResourceURL.replaceFirst("jar:file:([^!]+).*", "$1");
}

Regards,
Alex

Am 26.02.2008 um 12:11 schrieb VUB Stefan Seidel:

I am looking for a solution to that too. My workaround was until now 
to pick specific classes whose JAR files I needed and do


_class.getResource("/" + _class.getCanonicalName().replace(".", "/") + 
".class").toString().replaceAll("-client.jar!", 
".jar!").replaceFirst("jar:file:([^!]+).*", "$1")


and append this to java.class.path. Kindofa hack though ...

Stefan

Alexander Klimetschek wrote:
I forgot to mention that the unit test runs perfect in Eclipse, 
because the project created by "mvn eclipse:eclipse" includes all 
test dependencies as well and the Eclipse jUnit runner puts all of 
them in the class path for the test. Would be cool to have the 
Eclipse project and mvn test behave the same without two different 
configurations.

Alex
Am 25.02.2008 um 20:58 schrieb Alexander Klimetschek:

Hi all,

I have a test case which starts another JVM (a derby database server 
in network mode). The classpath for the new JVM needs jar files 
which are defined as test dependencies (derby is available in the 
form of maven artifacts, and I want to test it against the same 
derby version against which the actual code is written). The problem 
is that due to the surefire boot mechanism, it's not sufficient to 
read the classpath of the JVM in which test is running via 
System.getProperty("java.class.path").


How can I get access to the classpath of surefire?

Or is there another way to retrieve the path of the jar files 
defined in the pom from my junit test class?


Regards,
Alex

--
Alexander Klimetschek
[EMAIL PROTECTED]





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


--
best regards,

Stefan Seidel
software developer

VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel.+49 (341) 9 60 50 07
fax.+49 (341) 9 60 50 92
mail.   [EMAIL PROTECTED]
web.www.vub.de

HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf

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



--
Alexander Klimetschek
[EMAIL PROTECTED]





-
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: Retrieving surefire classpath from a test class

[Alexander Klimetschek]

Thanks Stefan, nice hack ;-) I didn't know that you can get the Jar  
file via the class resource URL, but it makes sense.


FYI, I made a useful method out of this (I removed the special - 
client.jar replacement):


/**
 * Returns the path to the JAR file that a certain class is located  
in. This only works

 * if the classloader loaded this class from a JAR file.
 */
public static final String getJarFileForClass(Class clazz) {
// eg. /org/apache/derby/drda/NetworkServerControl.class
	String classResource = "/" + clazz.getCanonicalName().replace(".",  
"/") + ".class";
	// eg. jar:file:/Users/alex/.m2/repository/org/apache/derby/derbynet/ 
10.2.1.6/derbynet-10.2.1.6.jar!/org/apache/derby/drda/ 
NetworkServerControl.class

String fullResourceURL = clazz.getResource(classResource).toString();
	// eg. /Users/alex/.m2/repository/org/apache/derby/derbynet/10.2.1.6/ 
derbynet-10.2.1.6.jar

return fullResourceURL.replaceFirst("jar:file:([^!]+).*", "$1");
}

Regards,
Alex

Am 26.02.2008 um 12:11 schrieb VUB Stefan Seidel:

I am looking for a solution to that too. My workaround was until now  
to pick specific classes whose JAR files I needed and do


_class.getResource("/" + _class.getCanonicalName().replace(".", "/")  
+ ".class").toString().replaceAll("-client.jar!",  
".jar!").replaceFirst("jar:file:([^!]+).*", "$1")


and append this to java.class.path. Kindofa hack though ...

Stefan

Alexander Klimetschek wrote:
I forgot to mention that the unit test runs perfect in Eclipse,  
because the project created by "mvn eclipse:eclipse" includes all  
test dependencies as well and the Eclipse jUnit runner puts all of  
them in the class path for the test. Would be cool to have the  
Eclipse project and mvn test behave the same without two different  
configurations.

Alex
Am 25.02.2008 um 20:58 schrieb Alexander Klimetschek:

Hi all,

I have a test case which starts another JVM (a derby database  
server in network mode). The classpath for the new JVM needs jar  
files which are defined as test dependencies (derby is available  
in the form of maven artifacts, and I want to test it against the  
same derby version against which the actual code is written). The  
problem is that due to the surefire boot mechanism, it's not  
sufficient to read the classpath of the JVM in which test is  
running via System.getProperty("java.class.path").


How can I get access to the classpath of surefire?

Or is there another way to retrieve the path of the jar files  
defined in the pom from my junit test class?


Regards,
Alex

--
Alexander Klimetschek
[EMAIL PROTECTED]





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


--
best regards,

Stefan Seidel
software developer

VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel.+49 (341) 9 60 50 07
fax.+49 (341) 9 60 50 92
mail.   [EMAIL PROTECTED]
web.www.vub.de

HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf

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



--
Alexander Klimetschek
[EMAIL PROTECTED]





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

Re: Retrieving surefire classpath from a test class

[VUB Stefan Seidel]

I am looking for a solution to that too. My workaround was until now to 
pick specific classes whose JAR files I needed and do


_class.getResource("/" + _class.getCanonicalName().replace(".", "/") + 
".class").toString().replaceAll("-client.jar!", 
".jar!").replaceFirst("jar:file:([^!]+).*", "$1")


and append this to java.class.path. Kindofa hack though ...

Stefan

Alexander Klimetschek wrote:
I forgot to mention that the unit test runs perfect in Eclipse, because 
the project created by "mvn eclipse:eclipse" includes all test 
dependencies as well and the Eclipse jUnit runner puts all of them in 
the class path for the test. Would be cool to have the Eclipse project 
and mvn test behave the same without two different configurations.


Alex

Am 25.02.2008 um 20:58 schrieb Alexander Klimetschek:


Hi all,

I have a test case which starts another JVM (a derby database server 
in network mode). The classpath for the new JVM needs jar files which 
are defined as test dependencies (derby is available in the form of 
maven artifacts, and I want to test it against the same derby version 
against which the actual code is written). The problem is that due to 
the surefire boot mechanism, it's not sufficient to read the classpath 
of the JVM in which test is running via 
System.getProperty("java.class.path").


How can I get access to the classpath of surefire?

Or is there another way to retrieve the path of the jar files defined 
in the pom from my junit test class?


Regards,
Alex

--
Alexander Klimetschek
[EMAIL PROTECTED]






--
Alexander Klimetschek
[EMAIL PROTECTED]





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



--
best regards,

Stefan Seidel
software developer

VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel.+49 (341) 9 60 50 07
fax.+49 (341) 9 60 50 92
mail.   [EMAIL PROTECTED]
web.www.vub.de

HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf

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

Re: Test classpath problem in multi module project

[VUB Stefan Seidel]

Hi Petr,

is seems to me that you're trying to work around maven mechanisms, which 
is usually not a good idea. In this case, although I haven't completely 
understood what you are trying to do, I can share some experience about 
EJB3 and Testing.
I have one artifact P where the JBoss embedded container xml files are 
in P/src/test/resources:

-- default.persistence.properties
-- ejb3-interceptors-aop.xml
-- embedded-jboss-beans.xml

Of P I build a test-jar. P has dependencies to
 -- jboss-ejb3-all
 -- thirdparty-all
 -- hibernate-all
JARs as system.

The artifacts A...O contain EJB3 beans, with only a persistence.xml in
A/src/main/resources/META-INF
which is the production persistence.xml and usually only contains the 
jta-data-source. The artifacts also contain a test-scope dependency to 
the test-jar of P.


There is no other persistence.xml in the projects.

Then I changed embedded-jboss-beans.xml so that our own datasources are 
being created as HSQLDB instances.


For testing EJB3 within their own build cycle, a trick is needed: in 
 I declare that the normal tests should not be run in 
the "test" phase, but rather in the "integration-test" phase:

  
maven-surefire-plugin

  true


  
integration-test

  test


  ${maven.test.skip.exec}

  

  

This has two advantages: Firstly, the built jar is available during the 
tests, secondly, the other dependencies are available as JAR files, not 
as directories.


Then, I have created an Abstract Test Case in P/src/test/java/...:
--- SNIP
import java.io.File;
import java.net.URISyntaxException;

import junit.framework.TestCase;

import org.jboss.ejb3.embedded.EJB3StandaloneBootstrap;

public abstract class AbstractEJB3TestCase extends TestCase {

public AbstractEJB3TestCase() {
super();
}

public AbstractEJB3TestCase(String _name) {
super(_name);
}

public void addEJB3BeanJar(Class _class) {
appendPathToClasspath(_class.getResource(
"/" + _class.getCanonicalName().replace(".", "/") + 
".class").toString().replaceAll(
"-client.jar!", ".jar!").replaceFirst("jar:file:([^!]+).*", 
"$1"));

}

@Override
protected void setUp() throws Exception {
System.setProperty("java.naming.factory.initial",
"org.jnp.interfaces.LocalOnlyContextFactory");
System.setProperty("java.naming.factory.url.pkgs", 
"org.jboss.naming:org.jnp.interfaces");


addBuildJarToClasspath();

EJB3StandaloneBootstrap.boot(null);
EJB3StandaloneBootstrap.scanClasspath();
}

protected void addBuildJarToClasspath() throws URISyntaxException {
final File targetDir = new 
File(this.getClass().getResource("/").toURI()).getParentFile();

File myJar = null;
for (File f : targetDir.listFiles()) {
final String name = f.getName();
if (name.endsWith(".jar") && !name.contains("-test") && 
!name.contains("-client")) {

myJar = f;
break;
    }
}
if (myJar != null) {
appendPathToClasspath(myJar.getAbsolutePath());
} else {
System.err.println("WARNING: JAR could not be found in the 
classpath.");

System.err.println("Make sure that surefire runs in phase "
+ "\u00bbintegration-test\u00ab, not in the default 
phase \u00bbtest\u00ab.");

}
}

protected void appendPathToClasspath(final String _ap) {
final String oldCP = System.getProperty("java.class.path");
if (oldCP.contains(_ap) || !_ap.endsWith(".jar")) {
return;
}
System.setProperty("java.class.path", oldCP + 
File.pathSeparatorChar + _ap);

}

@Override
protected void tearDown() throws Exception {
EJB3StandaloneBootstrap.shutdown();
}
}
--- SNIP

This will do several things: Firstly, it searches for the jar that has 
just been built by accessing "/" through the classloader, secondly, it 
will modify java.class.path in order that the JBoss embedded deployer 
will find the JARs and deploy them, thirdly, it allows you to specify 
any EJB3 bean class in addEJB3BeanJar and will search for the 
appropriate JAR file in the classpath and will add it to java.class.path.


The in the EJB3 modules, your test cases just need to extend the 
abstract test case, and your EJB3 beans will be deployed just like in 
production environment, but to a local in-memory HSQLDB. You can insert 
test data after the 

Test classpath problem in multi module project

[Petr Nejedly]

Hi guys,

 

I'm trying to solve this issue for a few days and haven't been able to
crack it so far. The scenario is following:

 

I have a parent project that includes sub-modules, each having their own
pom.xml. Each of these modules produces an ejb3 package. I want to be
able to run unit/integration tests using the JBoss embedded container on
those modules from the parent project (so that it builds all modules).
The resources are different for the test phase from the ones to be
deployed (obviously). Normally it could all be achieved using
src/main/resources and src/test/tesources but in this case SureFire can
see all the resource files on its classpath and tries to use them (eg
persistence.xml -> tries to deploy test AND live persistence units which
fails the tests).

 

I kind of hacked it so that I'm able to run tests in one module and
package it. I end up with the following structure:

 

A

--target

classes

--META-INF (incl resources for tests, dependent modules can use
these, when deploying this module's EJBs in the embedded JBoss for
example)

test-classes

--A.jar (includes META-INF with resources for deployment)

 

When I run the build from the parent project though, it builds the first
one properly (eg A.jar) and when testing project B (which depends on A)
it can see on its classpath A/target/classes + A/target/test-classes
(this includes the proper resources for passing the tests) AND the built
A.jar (deployment - ready, including resources that fail the tests).

 

Dependency in B pom.xml is:

 



foo

A

ejb

provided



 

Is there a way how to exclude built A.jar from classpath when two
modules are dependent?

 

Hope this makes sense,

 

Petr 



The information contained in this email and its attachments is confidential and 
may be the subject of legal, professional or other privileged information. It 
is intended only for the named addressees and may not be disclosed to anyone 
else without consent from On Demand. If you are not the named addressee you 
must not use, disclose, distribute, copy, print or rely on the contents of this 
email and should destroy it immediately. Whilst On Demand takes care to protect 
its systems from electronic virus attack or other harmful event, the firm gives 
no warranty that this email message (including any attachments to it) is free 
of any virus or other harmful matter and accepts no responsibility for any loss 
or damage resulting from the recipient receiving, opening or using it. If you 
need any further information, please contact the originator of this message on 
+44 (0)20 7131 6700. Website: www.ondemand.co.uk. Registered Office: 1 Stephen 
Street, London, W1T 1AL. Registered in the UK No.4094951.

This message has been scanned for viruses by BlackSpider MailControl - 
www.blackspider.com

Re: Retrieving surefire classpath from a test class

[Alexander Klimetschek]

I forgot to mention that the unit test runs perfect in Eclipse,  
because the project created by "mvn eclipse:eclipse" includes all test  
dependencies as well and the Eclipse jUnit runner puts all of them in  
the class path for the test. Would be cool to have the Eclipse project  
and mvn test behave the same without two different configurations.


Alex

Am 25.02.2008 um 20:58 schrieb Alexander Klimetschek:


Hi all,

I have a test case which starts another JVM (a derby database server  
in network mode). The classpath for the new JVM needs jar files  
which are defined as test dependencies (derby is available in the  
form of maven artifacts, and I want to test it against the same  
derby version against which the actual code is written). The problem  
is that due to the surefire boot mechanism, it's not sufficient to  
read the classpath of the JVM in which test is running via  
System.getProperty("java.class.path").


How can I get access to the classpath of surefire?

Or is there another way to retrieve the path of the jar files  
defined in the pom from my junit test class?


Regards,
Alex

--
Alexander Klimetschek
[EMAIL PROTECTED]






--
Alexander Klimetschek
[EMAIL PROTECTED]





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

Retrieving surefire classpath from a test class

[Alexander Klimetschek]

Hi all,

I have a test case which starts another JVM (a derby database server  
in network mode). The classpath for the new JVM needs jar files which  
are defined as test dependencies (derby is available in the form of  
maven artifacts, and I want to test it against the same derby version  
against which the actual code is written). The problem is that due to  
the surefire boot mechanism, it's not sufficient to read the classpath  
of the JVM in which test is running via  
System.getProperty("java.class.path").


How can I get access to the classpath of surefire?

Or is there another way to retrieve the path of the jar files defined  
in the pom from my junit test class?


Regards,
Alex

--
Alexander Klimetschek
[EMAIL PROTECTED]





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

RE: Surefire 2.4.1 classpath order

[Dan Fabulich]

Ben Lidgey wrote:

Made the tests pass. I've no idea why. Do you want me to raise this as a 
bug?


Yes... nice work! That sounds like a Core bug and not a Surefire bug, so 
file it against "Maven 2" (MNG) in JIRA.


Thanks!

-Dan

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

Adding a folder to classpath at runtime

[amit kumar]

Hi,
Is it possible to add a newly created folder(and its contents) to the
classpath at the runtime(on the fly) using maven.
I am using this pde-maven-plugin where I am copying the dependencies to the
lib folder inside the ${basedir} and wants it to be available while
compiling the source code.

Any help?

Regards,
Amit

RE: Surefire 2.4.1 classpath order

[Ben Lidgey]

I took a copy of the project POM and put it in the surefire-integration-tests 
directory. The tests failed. I then trawled through the project POM and then 
its parent POM commenting out plugins, reporting, dependencies, and other bits 
until the test passed.

The thing that was causing the test to fail was that in the parent POM:

package
target
${pom.artifactId}-${pom.version}
${basedir}/src/main/java
${basedir}/src/test/java
${basedir}/target/test-classes
${basedir}/target/classes


Changing just testOutputDirectory to

target/test-classes

Made the tests pass. I've no idea why. Do you want me to raise this as a bug?

Ben


This e-mail is confidential and intended solely for the use of the 
individual(s) to whom it is addressed. Any views or opinions expressed are 
those of the author. If you are not the intended recipient, please be advised 
that any use, dissemination, printing or copying of this email is strictly 
prohibited.


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

RE: Surefire 2.4.1 classpath order

[Ben Lidgey]

> -Original Message-
> From: Dan Fabulich [mailto:[EMAIL PROTECTED]
> Sent: 18 February 2008 22:23
> To: Maven Users List
> Subject: RE: Surefire 2.4.1 classpath order
> [snip]

> Looks like we'll need to try some more debugging. :-)
>
> 1) If you run mvn -X you'll see lots of useful debugging
> information, including the command line we used to launch
> Surefire.  It looks something like this:
>
>Forking command line: cmd.exe /X /C
> '"C:\jdk1.5.0_12\jre\bin\java -jar
>  C:\DOCUME~1\dan\LOCALS~1\Temp\surefirebooter61534.jar
>  C:\DOCUME~1\dan\LOCALS~1\Temp\surefire61532tmp
>  C:\DOCUME~1\dan\LOCALS~1\Temp\surefire61533tmp"'
>
> You may notice that none of your jars appear on this list;
> that's by design.  Go take a look at the jar file and you'll
> see that it's a "manifest-only" jar; it contains only a
> META-INF/MANIFEST.MF file, specifying a Main-Class and a
> Class-Path to run the code.  Make sure that the manifest
> looks correct and that the jars/dirs appear in the correct order.

I get

Forking command line: cmd.exe /X /C '""c:\Program 
Files\Java\jdk1.5.0_14\jre\bin\java" -jar 
c:\DOCUME~1\benl\LOCALS~1\Temp\surefirebooter53271.jar 
c:\DOCUME~1\benl\LOCALS~1\Temp\surefire53269tmp 
c:\DOCUME~1\benl\LOCALS~1\Temp\surefire53270tmp"'

The MANIFEST.MF in the jar shows:

Class-Path: 
file:/C:/Documents%20and%20Settings/benl/.m2/repository/org/apache/maven/surefire/surefirebooter/2.4.1/surefire-booter-2.4.1.jar
 
file:/C:/Documents%20and%20Settings/benl/.m2/repository/org/apache/maven/surefire/surefire-api/2.4.1/surefire-api-2.4.1.jar
 
file:/C:/Documents%20and%20Settings/benl/.m2/repository/junit/junit/4.2/junit-4.2.jar
 [snip] file:/c:/Development/Projects/Inuk/MyProject/target/classes/ 
file:/c:/Development/Projects/Inuk/MyProject/target/test-classes/

Main-Class: org.apache.maven.surefire.booter.SurefireBooter

And in one of the tmp files included

classPathUrl.41=c\:\\Development\\Projects\\Inuk\\MyProject\\target\\test-classes
classPathUrl.40=c\:\\Development\\Projects\\Inuk\\MyProject\\target\\classes

Which when ordered in ascending order would put target/classes before 
target/test-classes

The effective-pom shows


maven-surefire-plugin
2.4.1

  true
  true
  

  log4j.configuration
  log4j.xml

  

  

Weird.

Ben


This e-mail is confidential and intended solely for the use of the 
individual(s) to whom it is addressed. Any views or opinions expressed are 
those of the author. If you are not the intended recipient, please be advised 
that any use, dissemination, printing or copying of this email is strictly 
prohibited.


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

RE: Surefire 2.4.1 classpath order

[Ben Lidgey]

> From: Dan Fabulich [mailto:[EMAIL PROTECTED]
> 2) Try pulling down our "classpath-order" test project here:
>
> http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-
> integration-tests/src/test/resources/classpath-order
> http://tinyurl.com/3csqca
>
> Run "mvn test" and confirm that you see the same thing I do
> in
> classpath-order/target/surefire-reports/TEST-it.BasicTest.xml.
>  I get test-classes first, classes second, and then a whole
> bunch of jars.  If the classpath order is incorrect, the test
> should fail.
>

Well, no need to panic as the classpath order test passed. Now I need to trawl 
through our (effective) pom for the project that was failing and see what the 
classpath is and if anything else is mucking about with the classpath. I'll 
report on any relevant findings.

Ben


This e-mail is confidential and intended solely for the use of the 
individual(s) to whom it is addressed. Any views or opinions expressed are 
those of the author. If you are not the intended recipient, please be advised 
that any use, dissemination, printing or copying of this email is strictly 
prohibited.


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

Re: Surefire 2.4.1 classpath order

[Dan Fabulich]

Ken Liu wrote:

Do you know if that bug was introduced in 2.0.7 (or some other earlier 
release)?


I talked about two JIRA issues; their interactions are complex.

SUREFIRE-61 is listed as affecting "2.0 (2.2 plugin)"; that means it has 
probably been around for a long time.  MNG-3118 is an "Improvement" and 
not a "Bug"; it was filed in July of 2007, but for all I know Maven has 
been behaving the old bad way since 2.0.0.


What's complex about this problem is that the two issues obfuscate each 
other.  For many users, Maven was trying to use the "wrong" classpath, but 
Surefire was accidentally reversing it, resulting in the "right" classpath 
for some users.  Since both bugs have been fixed in the latest versions of 
the software, people who get only one fix and not the other will suffer. 
:-(


My team is using 2.0.4 and we encountered a problem with the classpath 
ordering recently that caused builds to that were previously working to 
suddenly start failing.


If your project doesn't explicitly declare a version of Surefire, it will 
be automatically upgraded to the latest version (currently 2.4.1).  The 
developers who designed that feature are very sorry about it. ;-)


Based on what I think I know about this problem, you're probably being 
auto-upgraded to 2.4.1; Surefire 2.4.1 + Maven 2.0.4 = bad classpath 
ordering.


-Dan

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

Re: Surefire 2.4.1 classpath order

[Ken Liu]

Dan -

Do you know if that bug was introduced in 2.0.7 (or some other earlier
release)?  My team is using 2.0.4 and we encountered a problem with the
classpath ordering recently that caused builds to that were previously
working to suddenly start failing.

Thanks,

Ken

On 2/15/08, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> Ben Lidgey wrote:
>
> > We are running tests using Surefire 2.4.1 and Maven 2.0.8.
> [...]
>
> > Looking at the debug output shows:
> >
> > [DEBUG] Test Classpath :
> > [DEBUG]   C:\Documents and
> Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar
> >
> > [more jars]
> >
> > [DEBUG]   c:\Development\Projects\MyProject\target\classes
> > [DEBUG]   c:\Development\Projects\MyProject\target\test-classes
> >
> > Which would explain it. Is there anyway to get the test-classes before
> > classes in the classpath order? Setting childDelegation to true doesn't.
>
> I'm not 100% certain you're using the software you think you're using;
> here's some debugging/analysis tips.
>
> Take a look at http://jira.codehaus.org/browse/MNG-3118.  That bug was
> fixed in Maven 2.0.8 and called out in the release announcement as a
> backwards compatibility risk:
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00432.html
>
> As noted in MNG-3118, Surefire 2.3 had a bizarre classpath ordering bug
> that made the test classpath appear to be correct (test-classes first)
> under Maven 2.0.7 for some users with large classpaths:
>
> http://jira.codehaus.org/browse/SUREFIRE-61
>
> SUREFIRE-61 was fixed in Surefire 2.3.1.  Notably, it would make the "Test
> Classpath" output in -X look correct, while secretly under the hood it
> would munge the classpath incorrectly!
>
> As a result, for at least one project here at my work, we've seen:
>
> Maven 2.0.7 + Surefire 2.3: test-classes before classes
> Maven 2.0.8 + Surefire 2.3: classes before test-classes
> Maven 2.0.7 + Surefire 2.3.1 or higher: classes before test-classes
> Maven 2.0.8 + Surefire 2.3.1 or higher: test-classes before classes
>
> Benjamin checked in a classpath ordering test in the Surefire trunk that
> we now run with every release.  It's currently passing for me with
> Surefire 2.4.1 (and 2.4.2-SNAPSHOT) and Maven 2.0.8, and failing with
> Maven 2.0.7.
>
> Finally, note that your "real" classpath is being output in your
> target/surefire-reports/*.xml files as the "surefire.test.classpath"
> property; that may be useful for debugging purposes.
>
> -Dan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

RE: Surefire 2.4.1 classpath order

[Dan Fabulich]

Ben Lidgey wrote:




With target/classes before targe/test-classes.


This is the reverse order from what it's supposed to be.  Not only are 
test-classes supposed to appear before classes, but both of those are 
supposed to appear before your dependency jars.


Looks like we'll need to try some more debugging. :-)

1) If you run mvn -X you'll see lots of useful debugging information, 
including the command line we used to launch Surefire.  It looks something 
like this:


  Forking command line: cmd.exe /X /C '"C:\jdk1.5.0_12\jre\bin\java -jar
C:\DOCUME~1\dan\LOCALS~1\Temp\surefirebooter61534.jar
C:\DOCUME~1\dan\LOCALS~1\Temp\surefire61532tmp
C:\DOCUME~1\dan\LOCALS~1\Temp\surefire61533tmp"'

You may notice that none of your jars appear on this list; that's by 
design.  Go take a look at the jar file and you'll see that it's a 
"manifest-only" jar; it contains only a META-INF/MANIFEST.MF file, 
specifying a Main-Class and a Class-Path to run the code.  Make sure that 
the manifest looks correct and that the jars/dirs appear in the correct 
order.


2) Try pulling down our "classpath-order" test project here:

http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/classpath-order
http://tinyurl.com/3csqca

Run "mvn test" and confirm that you see the same thing I do in 
classpath-order/target/surefire-reports/TEST-it.BasicTest.xml. I get 
test-classes first, classes second, and then a whole bunch of jars.  If 
the classpath order is incorrect, the test should fail.


Hopefully, classpath-order will pass on your machine.  If that's the case, 
then the next thing to do will be to investigate what's different between 
your Inuk projects and our classpath-order test.


If classpath-order doesn't work on your machine, then I'll be surprised; 
I'm not exactly certain how to investigate that.  You could try filing a 
bug in that case and attaching debugging information for the 
classpath-order test.  To debug, we'd want: -X logs, a copy of your 
surefirebooter#.jar, and the two surefire#tmp files that are 
passed in as arguments.


Good luck!

-Dan

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

RE: Surefire 2.4.1 classpath order

[Ben Lidgey]

> -Original Message-
> From: Dan Fabulich [mailto:[EMAIL PROTECTED]
> Sent: 15 February 2008 22:52
> To: Maven Users List
> Subject: Re: Surefire 2.4.1 classpath order
>
> Ben Lidgey wrote:
>
> > We are running tests using Surefire 2.4.1 and Maven 2.0.8.
> [...]
>
[snip]
>
> I'm not 100% certain you're using the software you think
> you're using; here's some debugging/analysis tips.
>

Thanks for the tips. I've gone through the steps below.

> Take a look at http://jira.codehaus.org/browse/MNG-3118.
> That bug was fixed in Maven 2.0.8 and called out in the
> release announcement as a backwards compatibility risk:
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00432.html
>
> As noted in MNG-3118, Surefire 2.3 had a bizarre classpath
> ordering bug that made the test classpath appear to be
> correct (test-classes first) under Maven 2.0.7 for some users
> with large classpaths:
>
> http://jira.codehaus.org/browse/SUREFIRE-61
>
> SUREFIRE-61 was fixed in Surefire 2.3.1.  Notably, it would
> make the "Test Classpath" output in -X look correct, while
> secretly under the hood it would munge the classpath incorrectly!

Doing "mvn help:effective-pom" showed


maven-surefire-plugin
2.4.1

  true
  true
  

  log4j.configuration
  log4j.xml

  

  

> As a result, for at least one project here at my work, we've seen:
>
> Maven 2.0.7 + Surefire 2.3: test-classes before classes Maven
> 2.0.8 + Surefire 2.3: classes before test-classes Maven 2.0.7
> + Surefire 2.3.1 or higher: classes before test-classes Maven
> 2.0.8 + Surefire 2.3.1 or higher: test-classes before classes

And "mvn --version" shows

$ mvn --version
Maven version: 2.0.8
Java version: 1.5.0_14
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

> Finally, note that your "real" classpath is being output in
> your target/surefire-reports/*.xml files as the
> "surefire.test.classpath"
> property; that may be useful for debugging purposes.

The surefire-reports/*.xm files showed



With target/classes before targe/test-classes.

So, to summarise:

Maven 2.0.8, Surefire 2.4.1, target/classes before target/test-classes

This is reinforced as the test is failing because the src/main/resources 
properties file does not have an entry whereas the src/test/resources 
properties file does, and the test fails as it cannot find that entry 
(therefore is looking at the one from src/main/resources).

Ben


This e-mail is confidential and intended solely for the use of the 
individual(s) to whom it is addressed. Any views or opinions expressed are 
those of the author. If you are not the intended recipient, please be advised 
that any use, dissemination, printing or copying of this email is strictly 
prohibited.


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

Re: Surefire 2.4.1 classpath order

[Dan Fabulich]

Ben Lidgey wrote:


We are running tests using Surefire 2.4.1 and Maven 2.0.8.

[...]


Looking at the debug output shows:

[DEBUG] Test Classpath :
[DEBUG]   C:\Documents and 
Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar

[more jars]

[DEBUG]   c:\Development\Projects\MyProject\target\classes
[DEBUG]   c:\Development\Projects\MyProject\target\test-classes

Which would explain it. Is there anyway to get the test-classes before 
classes in the classpath order? Setting childDelegation to true doesn't.


I'm not 100% certain you're using the software you think you're using; 
here's some debugging/analysis tips.


Take a look at http://jira.codehaus.org/browse/MNG-3118.  That bug was 
fixed in Maven 2.0.8 and called out in the release announcement as a 
backwards compatibility risk:


http://www.mail-archive.com/[EMAIL PROTECTED]/msg00432.html

As noted in MNG-3118, Surefire 2.3 had a bizarre classpath ordering bug 
that made the test classpath appear to be correct (test-classes first) 
under Maven 2.0.7 for some users with large classpaths:


http://jira.codehaus.org/browse/SUREFIRE-61

SUREFIRE-61 was fixed in Surefire 2.3.1.  Notably, it would make the "Test 
Classpath" output in -X look correct, while secretly under the hood it 
would munge the classpath incorrectly!


As a result, for at least one project here at my work, we've seen:

Maven 2.0.7 + Surefire 2.3: test-classes before classes
Maven 2.0.8 + Surefire 2.3: classes before test-classes
Maven 2.0.7 + Surefire 2.3.1 or higher: classes before test-classes
Maven 2.0.8 + Surefire 2.3.1 or higher: test-classes before classes

Benjamin checked in a classpath ordering test in the Surefire trunk that 
we now run with every release.  It's currently passing for me with 
Surefire 2.4.1 (and 2.4.2-SNAPSHOT) and Maven 2.0.8, and failing with 
Maven 2.0.7.


Finally, note that your "real" classpath is being output in your 
target/surefire-reports/*.xml files as the "surefire.test.classpath" 
property; that may be useful for debugging purposes.


-Dan

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

Re: eclipse/wtp/maven classpath issues

[Darren Salomons]

I can also confirm that in the org.eclipse.wst.common.component file
generated by the eclipse-plugin that there is no reference to test-classes
in that file.

However in the server.xml generated by WTP/eclipse to launch tomcat it
contains:

http://www.nabble.com/eclipse-wtp-maven-classpath-issues-tp15502968s177p15502980.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]

eclipse/wtp/maven classpath issues

[Darren Salomons]

Not sure if this is an eclipse question or a side effect of how maven sets up
a WTP project.

What's happening is when I deploy my project to tomcat under WTP the
target/test-classes folder is being put on the classpath before my
target/classes folder.   My log4j properties and other properties files in
my src/test/resources get moved into the target/test-classes and take
precedence on the classpath.

I really don't even want the test-classes on the classpath at all.

Any thoughts?
-- 
View this message in context: 
http://www.nabble.com/eclipse-wtp-maven-classpath-issues-tp15502968s177p15502968.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]

surefire-booter manifest issue (was Re: Surefire 2.4.1 classpath order)

[Haroon Rafique]

On Today at 4:50pm, ak=>amit kumar <[EMAIL PROTECTED]> wrote:

ak> Hi,
ak> I have another related query regarding surefire, all of a sudden from 
ak> today we started getting this error while executing JUnit tasks, the 
ak> compilation of source file happens fine and the when compiling the 
ak> test source files, the maven gives build failure telling that it was 
ak> not able
ak> 

Its not exactly related but you might be running into:
http://jira.codehaus.org/browse/SUREFIRE-451

Its been fixed and should be in 2.4.2 (I have no idea when it will be 
released. I am not a committer).

You can read the last comment on the jira which points you to a previous 
thread on the mailing list:
http://jira.codehaus.org/browse/SUREFIRE-451#action_122858

ak> 
ak> to load main class from
ak> C:\WINDOWS\TEMP\surefirebooter59557.jar
ak> 
ak> What is going wrong here?
ak> Could someone please help on this?
ak> 
ak> Regards,
ak> Amit
ak> 

Cheers,
--
Haroon Rafique
<[EMAIL PROTECTED]>


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

Re: Surefire 2.4.1 classpath order

[amit kumar]

Hi,
I have another related query regarding surefire, all of a sudden from today
we started getting this error while executing JUnit tasks, the compilation
of source file happens fine and the when compiling the test source files,
the maven gives build failure telling that it was not able

to load main class from
C:\WINDOWS\TEMP\surefirebooter59557.jar

What is going wrong here?
Could someone please help on this?

Regards,
Amit

On Fri, Feb 15, 2008 at 4:16 PM, Ben Lidgey <[EMAIL PROTECTED]>
wrote:

> Hi
>
> We are running tests using Surefire 2.4.1 and Maven 2.0.8. The Junit test
> classes are expecting to load a properties file from src/test/resources with
> the same name as a properties file in src/main/resources to load test data
> etc. However the src/main/resources properties file is being loaded.
>
> Looking at the debug output shows:
>
> [DEBUG] Test Classpath :
> [DEBUG]   C:\Documents and
> Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar
>
> [more jars]
>
> [DEBUG]   c:\Development\Projects\MyProject\target\classes
> [DEBUG]   c:\Development\Projects\MyProject\target\test-classes
>
> Which would explain it. Is there anyway to get the test-classes before
> classes in the classpath order? Setting childDelegation to true doesn't.
>
> Ben Lidgey
> Senior Software Engineer
> e: [EMAIL PROTECTED]
>
> Inuk Networks Limited
> Enterprise House
> Navigation Park
> Abercynon
> CF45 4SN
> t: +44 (0)844 546 0100
> f: +44 (0)844 546 0200
> w: www.inuknetworks.com
>
>
> This e-mail is confidential and intended solely for the use of the
> individual(s) to whom it is addressed. Any views or opinions expressed are
> those of the author. If you are not the intended recipient, please be
> advised that any use, dissemination, printing or copying of this email is
> strictly prohibited.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Surefire 2.4.1 classpath order

[Ben Lidgey]

Hi

We are running tests using Surefire 2.4.1 and Maven 2.0.8. The Junit test 
classes are expecting to load a properties file from src/test/resources with 
the same name as a properties file in src/main/resources to load test data etc. 
However the src/main/resources properties file is being loaded.

Looking at the debug output shows:

[DEBUG] Test Classpath :
[DEBUG]   C:\Documents and 
Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar

[more jars]

[DEBUG]   c:\Development\Projects\MyProject\target\classes
[DEBUG]   c:\Development\Projects\MyProject\target\test-classes

Which would explain it. Is there anyway to get the test-classes before classes 
in the classpath order? Setting childDelegation to true doesn't.

Ben Lidgey
Senior Software Engineer
e: [EMAIL PROTECTED]

Inuk Networks Limited
Enterprise House
Navigation Park
Abercynon
CF45 4SN
t: +44 (0)844 546 0100
f: +44 (0)844 546 0200
w: www.inuknetworks.com


This e-mail is confidential and intended solely for the use of the 
individual(s) to whom it is addressed. Any views or opinions expressed are 
those of the author. If you are not the intended recipient, please be advised 
that any use, dissemination, printing or copying of this email is strictly 
prohibited.


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

Re: Javadoc:jar error: Not executing Javadoc as the project is not a Java classpath-capable package

[Ryan H.]

I understand that. Unfortunetaly, we have such need for the customers on the
legacy ground.

If it's not recommended, how come maven javadoc plug-in page advocates this
usage. Please see:
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html


On 2/12/08, VUB Stefan Seidel <[EMAIL PROTECTED]> wrote:
>
> Hi Ryan,
>
> the thing is: in maven philosophy, it does not make sense to create an
> aggregate javadoc jar. A javadoc jar contains the sources for _one_
> artifact, so that for that specific artifact an IDE could for example
> download this javadoc jar in order to have the javadoc available for all
> the classes in this artifact. I understand that you want all the
> aggregated javadoc in one file, but to do that you cannot use standard
> maven procedures. Just package the aggregate javadoc yourself.
>
> HTH,
>
> Stefan
>
> Ryan H. wrote:
> > Has anyone successfully used "mvn javadoc:jar -Daggregate=true" for
> multiple
> > projects?
> >
> > Here is the directory structure for my multiple projects:
> >
> > Project
> > |-- pom.xml
> > |-- Module1
> > |   `-- pom.xml
> > |-- Module2
> > |   `-- pom.xml
> > `-- Module3
> > `-- pom.xml
> >
> > Now, when I run "mvn javadoc:jar -Daggregate=true" under "Project", it
> > always throws me this info without doing anything:
> >
> > *[INFO] Not executing Javadoc as the project is not a Java
> classpath-capable
> > package*
> >
> > I downloaded the source code of maven-javadoc-plugin and added the debug
> > statement before the above line is printed in this block of code
> snippet:
> >
> >
> > ArtifactHandler artifactHandler = project
> > .getArtifact().getArtifactHandler();
> >
> > *if* ( !"java".equals( artifactHandler.getLanguage() ) )
> >
> > {
> >
> > getLog().info("problematic artifact is: " + project.getArtifactId() + ",
> > language: " + artifactHandler.getLanguage());
> >
> > getLog().info( "Not executing Javadoc as the project is not a Java
> > classpath-capable package" );
> >
> > }
> >
> > And it turned out to be complaining about "Project", whose "packing
> type" is
> > "pom" and "language" is "none":
> >
> > [INFO] [javadoc:jar]
> > [INFO] problematic artifact is: Project, language: none
> > [INFO] Not executing Javadoc as the project is not a Java
> classpath-capable
> > package
> >
> >
> > Am I missing something? Anyone has a clue?
> >
> > Thanks
> >
> > On 1/29/08, Ryan H. <[EMAIL PROTECTED]> wrote:
> >
> >> I stripped out all modules and run it again. It still complains as
> shown
> >> below:
> >>
> >> D:\maven1\test>mvn javadoc:jar -Daggregate=true
> >> [INFO] Scanning for projects...
> >> [INFO] Searching repository for plugin with prefix: 'javadoc'.
> >> WAGON_VERSION: 1.0-beta-2
> >> [INFO]
> >>
> ----
> >> [INFO] Building Foundations POM
> >> [INFO]task-segment: [javadoc:jar] (aggregator-style)
> >> [INFO]
> >>
> 
> >> [INFO] Preparing javadoc:jar
> >> [INFO]
> >>
> 
> >> [INFO] Building MyProjects POM
> >> [INFO]
> >>
> 
> >> [INFO] No goals needed for project - skipping
> >> *[INFO] [javadoc:jar]
> >> [INFO] Not executing Javadoc as the project is not a Java
> >> classpath-capable package
> >> *[INFO]
> >>
> 
> >> [INFO] BUILD SUCCESSFUL
> >> [INFO]
> >>
> 
> >> [INFO] Total time: 1 second
> >> [INFO] Finished at: Tue Jan 29 17:42:20 PST 2008
> >> [INFO] Final Memory: 7M/508M
> >> [INFO]
> >>
> 
> >>
> >>
> >>
> >> On 1/29/08, Ryan H. <[EMAIL PROTECTED]> wrote:
> >>> Hi Vincent,
> >>>
> >>> I invoke javadoc:

Re: ejb classpath and ear plugin

[Manos Batsis]

nicolas de loof wrote:

The ejb plugin has the option to generate the EJB classpath in MANIFEST
based on the declared dependencies

Is there any support in the ear plugin to automagically package thoses
dependencies as jarModules ?



My objective in a probably similar situation was to package EJB JAR and 
WAR dependencies in a shared classpath within my EAR and point to them 
from my MANIFEST.MF files. I finally did it, but had to duplicate the 
EJB and WAR deps in the EAR POM as well. You can see all three POMs at [1].


[1] http://md4j.cvs.sourceforge.net/md4j/md4j-quickstarter-mvn/

hth,

Manos



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

[solved] ejb classpath and ear plugin

[nicolas de loof]

This is allready the case ... sorry for the noise :-/


2008/2/12, nicolas de loof <[EMAIL PROTECTED]>:
>
> Hello,
>
> The ejb plugin has the option to generate the EJB classpath in MANIFEST
> based on the declared dependencies
>
> Is there any support in the ear plugin to automagically package thoses
> dependencies as jarModules ?
>
> Nico.
>

ejb classpath and ear plugin

[nicolas de loof]

Hello,

The ejb plugin has the option to generate the EJB classpath in MANIFEST
based on the declared dependencies

Is there any support in the ear plugin to automagically package thoses
dependencies as jarModules ?

Nico.

Re: Javadoc:jar error: Not executing Javadoc as the project is not a Java classpath-capable package

[VUB Stefan Seidel]

Hi Ryan,

the thing is: in maven philosophy, it does not make sense to create an 
aggregate javadoc jar. A javadoc jar contains the sources for _one_ 
artifact, so that for that specific artifact an IDE could for example 
download this javadoc jar in order to have the javadoc available for all 
the classes in this artifact. I understand that you want all the 
aggregated javadoc in one file, but to do that you cannot use standard 
maven procedures. Just package the aggregate javadoc yourself.


HTH,

Stefan

Ryan H. wrote:

Has anyone successfully used "mvn javadoc:jar -Daggregate=true" for multiple
projects?

Here is the directory structure for my multiple projects:

Project
|-- pom.xml
|-- Module1
|   `-- pom.xml
|-- Module2
|   `-- pom.xml
`-- Module3
`-- pom.xml

Now, when I run "mvn javadoc:jar -Daggregate=true" under "Project", it
always throws me this info without doing anything:

*[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package*

I downloaded the source code of maven-javadoc-plugin and added the debug
statement before the above line is printed in this block of code snippet:


ArtifactHandler artifactHandler = project
.getArtifact().getArtifactHandler();

*if* ( !"java".equals( artifactHandler.getLanguage() ) )

{

getLog().info("problematic artifact is: " + project.getArtifactId() + ",
language: " + artifactHandler.getLanguage());

getLog().info( "Not executing Javadoc as the project is not a Java
classpath-capable package" );

}

And it turned out to be complaining about "Project", whose "packing type" is
"pom" and "language" is "none":

[INFO] [javadoc:jar]
[INFO] problematic artifact is: Project, language: none
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package


Am I missing something? Anyone has a clue?

Thanks

On 1/29/08, Ryan H. <[EMAIL PROTECTED]> wrote:


I stripped out all modules and run it again. It still complains as shown
below:

D:\maven1\test>mvn javadoc:jar -Daggregate=true
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'javadoc'.
WAGON_VERSION: 1.0-beta-2
[INFO]

[INFO] Building Foundations POM
[INFO]task-segment: [javadoc:jar] (aggregator-style)
[INFO]

[INFO] Preparing javadoc:jar
[INFO]

[INFO] Building MyProjects POM
[INFO]
----
[INFO] No goals needed for project - skipping
*[INFO] [javadoc:jar]
[INFO] Not executing Javadoc as the project is not a Java
classpath-capable package
*[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 1 second
[INFO] Finished at: Tue Jan 29 17:42:20 PST 2008
[INFO] Final Memory: 7M/508M
[INFO]




On 1/29/08, Ryan H. <[EMAIL PROTECTED]> wrote:

Hi Vincent,

I invoke javadoc:jar from my top level POM whose package type is "pom".
All modules included are java projects and their packaging types are "jar"
across the board ...


 On 1/29/08, Vincent Siveton <[EMAIL PROTECTED]> wrote:

Hi Ryan,

What is your packaging type of your project (or subprojects)? It seems
it is not a java one.

Cheers,

Vincent

2008/1/29, Ryan H. <[EMAIL PROTECTED]>:

Hello,

Anyone knows what this javadoc:jar complains about? I'm able to run
javadoc:javadoc in "aggregate" mode (ie. generate only one report

for

all multiple projects). However, when I run javadoc:jar, it starts
complaining it ...

[INFO] [javadoc:jar]
[INFO] Not executing Javadoc as the project is not a Java

classpath-capable

package

Thanks
Ryan


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






--
best regards,

Stefan Seidel
software developer

VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel.+49 (341) 9 60 50 07
fax.+49 (341) 9 60 50 92
mail.   [EMAIL PROTECTED]
web.www.vub.de

HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf

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

Re: Javadoc:jar error: Not executing Javadoc as the project is not a Java classpath-capable package

[Ryan H.]

Has anyone successfully used "mvn javadoc:jar -Daggregate=true" for multiple
projects?

Here is the directory structure for my multiple projects:

Project
|-- pom.xml
|-- Module1
|   `-- pom.xml
|-- Module2
|   `-- pom.xml
`-- Module3
`-- pom.xml

Now, when I run "mvn javadoc:jar -Daggregate=true" under "Project", it
always throws me this info without doing anything:

*[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package*

I downloaded the source code of maven-javadoc-plugin and added the debug
statement before the above line is printed in this block of code snippet:


ArtifactHandler artifactHandler = project
.getArtifact().getArtifactHandler();

*if* ( !"java".equals( artifactHandler.getLanguage() ) )

{

getLog().info("problematic artifact is: " + project.getArtifactId() + ",
language: " + artifactHandler.getLanguage());

getLog().info( "Not executing Javadoc as the project is not a Java
classpath-capable package" );

}

And it turned out to be complaining about "Project", whose "packing type" is
"pom" and "language" is "none":

[INFO] [javadoc:jar]
[INFO] problematic artifact is: Project, language: none
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package


Am I missing something? Anyone has a clue?

Thanks

On 1/29/08, Ryan H. <[EMAIL PROTECTED]> wrote:

> I stripped out all modules and run it again. It still complains as shown
> below:
>
> D:\maven1\test>mvn javadoc:jar -Daggregate=true
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'javadoc'.
> WAGON_VERSION: 1.0-beta-2
> [INFO]
> 
> [INFO] Building Foundations POM
> [INFO]task-segment: [javadoc:jar] (aggregator-style)
> [INFO]
> 
> [INFO] Preparing javadoc:jar
> [INFO]
> 
> [INFO] Building MyProjects POM
> [INFO]
> ----
> [INFO] No goals needed for project - skipping
> *[INFO] [javadoc:jar]
> [INFO] Not executing Javadoc as the project is not a Java
> classpath-capable package
> *[INFO]
> 
> [INFO] BUILD SUCCESSFUL
> [INFO]
> 
> [INFO] Total time: 1 second
> [INFO] Finished at: Tue Jan 29 17:42:20 PST 2008
> [INFO] Final Memory: 7M/508M
> [INFO]
> 
>
>
>
> On 1/29/08, Ryan H. <[EMAIL PROTECTED]> wrote:
> >
> > Hi Vincent,
> >
> > I invoke javadoc:jar from my top level POM whose package type is "pom".
> > All modules included are java projects and their packaging types are "jar"
> > across the board ...
> >
> >
> >  On 1/29/08, Vincent Siveton <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Ryan,
> > >
> > > What is your packaging type of your project (or subprojects)? It seems
> > > it is not a java one.
> > >
> > > Cheers,
> > >
> > > Vincent
> > >
> > > 2008/1/29, Ryan H. <[EMAIL PROTECTED]>:
> > > > Hello,
> > > >
> > > > Anyone knows what this javadoc:jar complains about? I'm able to run
> > > > javadoc:javadoc in "aggregate" mode (ie. generate only one report
> > > for
> > > > all multiple projects). However, when I run javadoc:jar, it starts
> > > > complaining it ...
> > > >
> > > > [INFO] [javadoc:jar]
> > > > [INFO] Not executing Javadoc as the project is not a Java
> > > classpath-capable
> > > > package
> > > >
> > > > Thanks
> > > > Ryan
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>

maven classpath help

[ståle pedersen]

hi, im trying to add loadtime weaving with jboss aop to my unit tests.
to achieve this i need to add the jvm option:
-javaagent:/path/to/jboss-aop.jar, and a option to specify where the
xml file that contains the pointcuts etc is.

the problem ive had is that the jboss-aop.jar depends on a few other jars and
when SurefireBooter starts a new jvm it do not add these to the
classpath. just a few surefire jars are added afaik.
here is the output when i run in debug mode:

Forking command line: java
-javaagent:/home/stalep/.m2/repository/org/jboss/aop/jboss-aop/2.0.0.CR3/jboss-aop-2.0.0.CR3.jar
-Djboss.aop.path=src/test/conf/jboss-aop.xml -classpath
/home/stalep/.m2/repository/org/apache/maven/surefire/surefire-api/2.0/surefire-api-2.0.jar:/home/stalep/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar:/home/stalep/.m2/repository/org/apache/maven/surefire/surefire-booter/2.0/surefire-booter-2.0.jar
org.apache.maven.surefire.booter.SurefireBooter /tmp/surefire12863tmp
/tmp/surefire12864tmp
Exception in thread "main" java.lang.NoClassDefFoundError:
javassist/scopedpool/ScopedClassPoolFactory
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
at java.lang.Class.getMethod0(Class.java:2642)
FATAL ERROR in native method: processing of -javaagent failed

here is the surefire-plugin options ive set:

  org.apache.maven.plugins
  maven-surefire-plugin
  
always
true

-javaagent:/home/stalep/.m2/repository/org/jboss/aop/jboss-aop/2.0.0.CR3/jboss-aop-2.0.0.CR3.jar
-Djboss.aop.path=src/test/conf/jboss-aop.xml
  


from what ive seen in the source (just looked a bit at
SurefireBooter.java and SurefirePlugin.java) it seems that setting
useSystemClassLoader=true should add all the dependent jars to the
classpath when the jvm starts.
SurefireBooter.java, fork():
[snip]
bootClasspath.addAll( surefireBootClassPathUrls );
if ( useSystemClassLoader() )
{
  bootClasspath.addAll( classPathUrls );
}

Commandline cli = forkConfiguration.createCommandLine( bootClasspath,
useSystemClassLoader() );
[/snip]

ive set this option in the plugin configuration, but it do not add the
other jars to the bootClassPath.
is there something ive missed? any tip/info is highly appreciated

ståle

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

Re: can maven run java program using dependence artifact information as classpath?

[Ryan H.]

java.class.path under maven2 won't give you the path for the project
dependencies ... it's different from under maven1

On 1/30/08, Rex Huang <[EMAIL PROTECTED]> wrote:
>
> the application use System.getProperty("java.class.path") to get
> classpath.
>
> Rex
>
> On Jan 30, 2008 10:46 AM, Rex Huang <[EMAIL PROTECTED]> wrote:
>
> > exec-maven-plugin is good, but in my case, the application also run
> javac
> > to generate jar file, and it use its classpath instead of dependency
> > information.
> > I use java to run it with classpath is ok.
> >
> > BR//Rex
> >
> >
> > On Jan 29, 2008 7:53 PM, Wayne Fay <[EMAIL PROTECTED]> wrote:
> >
> > > The exec-maven-plugin should interest you:
> > > http://mojo.codehaus.org/exec-maven-plugin/usage.html
> > >
> > > Wayne
> > >
> > > On 1/29/08, Rex Huang <[EMAIL PROTECTED]> wrote:
> > > > I just give mainclass and parameters information,
> > > > then maven runs the mainclass and use dependence artifact
> information
> > > as
> > > > classpath.
> > > >
> > > > Can this work?
> > > >
> > > > BR//Rex
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>

RE: Dependency:build-classpath

[John Coleman]

Hi,

Somehow I managed to get an alpha version in my repos, once I changed
version to specify 2.0, was fine!

Regards,
John 

> -Original Message-
> From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
> Sent: 01 February 2008 14:41
> To: Maven Users List
> Subject: RE: Dependency:build-classpath
> 
> Is it just printing the classpath instead, or is it not doing 
> anything?
> 
> -Original Message-
> From: John Coleman [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 01, 2008 7:09 AM
> To: Maven Users List
> Subject: Dependency:build-classpath
> 
> I'm trying to use the dependency plugin to record classpaths, 
> but it doesn't seem to write to a file as documented. What 
> have I done wrong?
> 
> TIA,
> John
> 
> 
>   org.apache.maven.plugins
>   maven-dependency-plugin
> 
> 
>   classpath
>   
> build-classpath
>   
>   
> 
> com.eurobase
> .classpath
>   
> 
> 
> 
> 
> Eurobase International Limited and its subsidiaries 
> (Eurobase) are unable to exercise control over the content of 
> information in E-Mails.
> Any views and opinions expressed may be personal to the 
> sender and are not necessarily those of Eurobase. Eurobase 
> will not enter into any contractual obligations in respect of 
> any part of its business in any E-mail. 
> 
> Privileged / confidential information may be contained in 
> this message and /or any attachments. This E-mail is intended 
> for the use of the
> addressee(s) only and may contain confidential information. 
> If you are not the / an intended recipient, you are hereby 
> notified that any use or dissemination of this communication 
> is strictly prohibited.  If you receive this transmission in 
> error, please notify us immediately, and then delete this E-mail. 
> 
> Neither the sender nor Eurobase accepts any liability 
> whatsoever for any defects of any kind either in or arising 
> from this E-mail transmission.
> E-Mail transmission cannot be guaranteed to be secure or 
> error-free, as messages can be intercepted, lost, corrupted, 
> destroyed, contain viruses, or arrive late or incomplete. 
> Eurobase does not accept any responsibility for viruses and 
> it is your responsibility to scan any attachments.
> 
> Eurobase Systems Limited is the main trading company in the 
> Eurobase International Group; registered in England and Wales 
> as company number 02251162; registered address: Essex House, 
> 2 County Place, Chelmsford, Essex CM2 0RE, UK.
> 
> 
> -
> 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]
> 
> 

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

RE: Dependency:build-classpath

[Brian E. Fox]

Is it just printing the classpath instead, or is it not doing anything?

-Original Message-
From: John Coleman [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 01, 2008 7:09 AM
To: Maven Users List
Subject: Dependency:build-classpath

I'm trying to use the dependency plugin to record classpaths, but it
doesn't seem to write to a file as documented. What have I done wrong?

TIA,
John


  org.apache.maven.plugins
  maven-dependency-plugin


  classpath
  
build-classpath
  
  
com.eurobase
    .classpath
  




Eurobase International Limited and its subsidiaries (Eurobase) are
unable to exercise control over the content of information in E-Mails.
Any views and opinions expressed may be personal to the sender and are
not necessarily those of Eurobase. Eurobase will not enter into any
contractual obligations in respect of any part of its business in any
E-mail. 

Privileged / confidential information may be contained in this message
and /or any attachments. This E-mail is intended for the use of the
addressee(s) only and may contain confidential information. If you are
not the / an intended recipient, you are hereby notified that any use or
dissemination of this communication is strictly prohibited.  If you
receive this transmission in error, please notify us immediately, and
then delete this E-mail. 

Neither the sender nor Eurobase accepts any liability whatsoever for any
defects of any kind either in or arising from this E-mail transmission.
E-Mail transmission cannot be guaranteed to be secure or error-free, as
messages can be intercepted, lost, corrupted, destroyed, contain
viruses, or arrive late or incomplete. Eurobase does not accept any
responsibility for viruses and it is your responsibility to scan any
attachments.

Eurobase Systems Limited is the main trading company in the Eurobase
International Group; registered in England and Wales as company number
02251162; registered address: Essex House, 2 County Place, Chelmsford,
Essex CM2 0RE, UK.


-
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]

Dependency:build-classpath

[John Coleman]

I'm trying to use the dependency plugin to record classpaths, but it
doesn't seem to write to a file as documented. What have I done wrong?

TIA,
John


  org.apache.maven.plugins
  maven-dependency-plugin


  classpath
  
build-classpath
  
  
com.eurobase
    .classpath
  




Eurobase International Limited and its subsidiaries (Eurobase) are unable to 
exercise control over the content of information in E-Mails. Any views and 
opinions expressed may be personal to the sender and are not necessarily those 
of Eurobase. Eurobase will not enter into any contractual obligations in 
respect of any part of its business in any E-mail. 

Privileged / confidential information may be contained in this message and /or 
any attachments. This E-mail is intended for the use of the addressee(s) only 
and may contain confidential information. If you are not the / an intended 
recipient, you are hereby notified that any use or dissemination of this 
communication is strictly prohibited.  If you receive this transmission in 
error, please notify us immediately, and then delete this E-mail. 

Neither the sender nor Eurobase accepts any liability whatsoever for any 
defects of any kind either in or arising from this E-mail transmission. E-Mail 
transmission cannot be guaranteed to be secure or error-free, as messages can 
be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or 
incomplete. Eurobase does not accept any responsibility for viruses and it is 
your responsibility to scan any attachments.

Eurobase Systems Limited is the main trading company in the Eurobase 
International Group; registered in England and Wales as company number 
02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex 
CM2 0RE, UK.


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

Re: can maven run java program using dependence artifact information as classpath?

[Rex Huang]

the application use System.getProperty("java.class.path") to get classpath.

Rex

On Jan 30, 2008 10:46 AM, Rex Huang <[EMAIL PROTECTED]> wrote:

> exec-maven-plugin is good, but in my case, the application also run javac
> to generate jar file, and it use its classpath instead of dependency
> information.
> I use java to run it with classpath is ok.
>
> BR//Rex
>
>
> On Jan 29, 2008 7:53 PM, Wayne Fay <[EMAIL PROTECTED]> wrote:
>
> > The exec-maven-plugin should interest you:
> > http://mojo.codehaus.org/exec-maven-plugin/usage.html
> >
> > Wayne
> >
> > On 1/29/08, Rex Huang <[EMAIL PROTECTED]> wrote:
> > > I just give mainclass and parameters information,
> > > then maven runs the mainclass and use dependence artifact information
> > as
> > > classpath.
> > >
> > > Can this work?
> > >
> > > BR//Rex
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Re: can maven run java program using dependence artifact information as classpath?

[Rex Huang]

exec-maven-plugin is good, but in my case, the application also run javac to
generate jar file, and it use its classpath instead of dependency
information.
I use java to run it with classpath is ok.

BR//Rex

On Jan 29, 2008 7:53 PM, Wayne Fay <[EMAIL PROTECTED]> wrote:

> The exec-maven-plugin should interest you:
> http://mojo.codehaus.org/exec-maven-plugin/usage.html
>
> Wayne
>
> On 1/29/08, Rex Huang <[EMAIL PROTECTED]> wrote:
> > I just give mainclass and parameters information,
> > then maven runs the mainclass and use dependence artifact information as
> > classpath.
> >
> > Can this work?
> >
> > BR//Rex
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: can maven run java program using dependence artifact information as classpath?

[Rex Huang]

your plugin is interesting, but how to add argument to run application?

BR//Rex

On Jan 29, 2008 11:16 PM, Nick Stolwijk <[EMAIL PROTECTED]> wrote:

> I worked with the Application Assembler Plugin [1] which generates a
> directory under target, with a startup script, a lib directory with all
> the dependencies and some other files.
>
> Maybe that is what you're looking for.
>
> Hth,
>
> Nick Stolwijk
>
>
> [1] http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/
>
> Rex Huang wrote:
> > I just give mainclass and parameters information,
> > then maven runs the mainclass and use dependence artifact information as
> > classpath.
> >
> > Can this work?
> >
> > BR//Rex
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Javadoc:jar error: Not executing Javadoc as the project is not a Java classpath-capable package

[Ryan H.]

I stripped out all modules and run it again. It still complains as shown
below:

D:\maven1\test>mvn javadoc:jar -Daggregate=true
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'javadoc'.
WAGON_VERSION: 1.0-beta-2
[INFO]

[INFO] Building Foundations POM
[INFO]task-segment: [javadoc:jar] (aggregator-style)
[INFO]

[INFO] Preparing javadoc:jar
[INFO]

[INFO] Building MyProjects POM
[INFO]

[INFO] No goals needed for project - skipping
*[INFO] [javadoc:jar]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package
*[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 1 second
[INFO] Finished at: Tue Jan 29 17:42:20 PST 2008
[INFO] Final Memory: 7M/508M
[INFO]




On 1/29/08, Ryan H. <[EMAIL PROTECTED]> wrote:
>
> Hi Vincent,
>
> I invoke javadoc:jar from my top level POM whose package type is "pom".
> All modules included are java projects and their packaging types are "jar"
> across the board ...
>
>
>  On 1/29/08, Vincent Siveton <[EMAIL PROTECTED]> wrote:
> >
> > Hi Ryan,
> >
> > What is your packaging type of your project (or subprojects)? It seems
> > it is not a java one.
> >
> > Cheers,
> >
> > Vincent
> >
> > 2008/1/29, Ryan H. <[EMAIL PROTECTED]>:
> > > Hello,
> > >
> > > Anyone knows what this javadoc:jar complains about? I'm able to run
> > > javadoc:javadoc in "aggregate" mode (ie. generate only one report for
> > > all multiple projects). However, when I run javadoc:jar, it starts
> > > complaining it ...
> > >
> > > [INFO] [javadoc:jar]
> > > [INFO] Not executing Javadoc as the project is not a Java
> > classpath-capable
> > > package
> > >
> > > Thanks
> > > Ryan
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Re: Javadoc:jar error: Not executing Javadoc as the project is not a Java classpath-capable package

[Ryan H.]

Hi Vincent,

I invoke javadoc:jar from my top level POM whose package type is "pom". All
modules included are java projects and their packaging types are "jar"
across the board ...


On 1/29/08, Vincent Siveton <[EMAIL PROTECTED]> wrote:
>
> Hi Ryan,
>
> What is your packaging type of your project (or subprojects)? It seems
> it is not a java one.
>
> Cheers,
>
> Vincent
>
> 2008/1/29, Ryan H. <[EMAIL PROTECTED]>:
> > Hello,
> >
> > Anyone knows what this javadoc:jar complains about? I'm able to run
> > javadoc:javadoc in "aggregate" mode (ie. generate only one report for
> > all multiple projects). However, when I run javadoc:jar, it starts
> > complaining it ...
> >
> > [INFO] [javadoc:jar]
> > [INFO] Not executing Javadoc as the project is not a Java
> classpath-capable
> > package
> >
> > Thanks
> > Ryan
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Javadoc:jar error: Not executing Javadoc as the project is not a Java classpath-capable package

[Vincent Siveton]

Hi Ryan,

What is your packaging type of your project (or subprojects)? It seems
it is not a java one.

Cheers,

Vincent

2008/1/29, Ryan H. <[EMAIL PROTECTED]>:
> Hello,
>
> Anyone knows what this javadoc:jar complains about? I'm able to run
> javadoc:javadoc in "aggregate" mode (ie. generate only one report for
> all multiple projects). However, when I run javadoc:jar, it starts
> complaining it ...
>
> [INFO] [javadoc:jar]
> [INFO] Not executing Javadoc as the project is not a Java classpath-capable
> package
>
> Thanks
> Ryan
>

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

Re: can maven run java program using dependence artifact information as classpath?

[Nick Stolwijk]

I worked with the Application Assembler Plugin [1] which generates a 
directory under target, with a startup script, a lib directory with all 
the dependencies and some other files.


Maybe that is what you're looking for.

Hth,

Nick Stolwijk


[1] http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/

Rex Huang wrote:

I just give mainclass and parameters information,
then maven runs the mainclass and use dependence artifact information as
classpath.

Can this work?

BR//Rex

  


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