Re: Install/deploy a project with a single file
Hi, Just wrap it up as a jar-packaged module, put the xml in src/main/resources and you should be fine. Remember to lookup the xml file via the classpath. Cheers Jo On 6/10/07, Rahamim, Zvi (Zvi) <[EMAIL PROTECTED]> wrote: Hi, I have a project with only a single xml file. What should I define in the pom.xml file so that it will be installed and deployed? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: War plugin transitive dependency
On 6/8/07, Váry Péter <[EMAIL PROTECTED]> wrote: Unfortunately it does not help me in this situation: I do not have ear-s (working with tomcat), just war-s. One portal - one war. Every module is one war, or jar. Modules depend on each other like news.war (with jsp, html etc) depends on HTML editor war (with other jsp, html etc), and the product depends on news.war, with its own html-s, and jsp-s. AFAIK, dependencies of wars are not resolved transitively. If a war depends on another one, the contents of both are merged (overlayed). Nothing else to do than installing B first, to make the changes in C appear in A with the standard maven-war-plugin. However, appfuse's maven-warpath-plugin might be of interest. http://static.appfuse.org/maven-warpath-plugin/index.html It allows the dependencies of a war to be resolved transitively. Anyway, running your build from the common parent directory will guarantee a correct build reactor sequence. So there is always a last resort.. Cheers Jo
Re: Classpath issues with maven 2.0.6
On 6/8/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED] >
wrote:
I can not use the parent class loader since that would render the whole
exercise useless. The whole point is not using the standard classloader
otherwise it is impossible to unload classes. Remember, I want to test
static blocks ( static { some code } ) . So I need fresh copies of my
class for every single test. That's why I use the ReloadableClassLoader.
Hi Minto
Whether you like it or not, every ClassLoader has a parent, except for the
system class loader.
If you don't specify a parent ClassLoader, the default parent will be the
system class loader.
But this class loader is not always what we want.
And that's the reason why I adviced you to use the correct parent class
loader, i.c. the class loader that was used to load the definition of your
custom classloader (ReloadableClassLoader).
Every Class knows its ClassLoader, so you could get yours by calling
"getClass().getClassLoader()".
That is the correct parent loader and will introduce the desired class path
to your custom class loader.
Make sure that one is used when the custom class loader is created. It has
to be passed in the construcor.
Fiddling with the "java.class.path" system property in this context smells
too much like hacking to me.
Cheers
Jo
This custom classloader does not use the normal commandline but the
'java.class.path' system property to determine the classpath. Retrieving
this system property reveals only one classpath entry.
K:\DevTools\maven\maven- 2.0.6\boot\classworlds-1.1.jar
Thus all entries in the classpath reported by 'mvn -X' do not show up
here.
An alternative to using 'java.class.path' is fine with me, but from
where can I programmatically retrieve the classpath to feed to the
custom classloader. Is it possible to get the classpath from the active
classloader?
Regards,
Minto
-Oorspronkelijk bericht-----
Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens
Vandermeeren, Jo
Verzonden: vrijdag 8 juni 2007 14:49
Aan: Maven Users List
Onderwerp: Re: Classpath issues with maven 2.0.6
On 6/8/07, [EMAIL PROTECTED] <
[EMAIL PROTECTED] > wrote:
>
> Snippet of the "mvn test -X" ouput:
> ==
>
> [DEBUG] Test Classpath :
> [DEBUG] K:\Sources\Prefs\memoryprefs\target\test-classes
> [DEBUG] K:\Sources\Prefs\memoryprefs\target\classes
> [DEBUG] K:\Sources\Prefs\memoryprefs\target\classes
> [DEBUG] K:\Sources\Prefs\memoryprefs\target\test-classes
> [DEBUG]
> K:\Repositories\maven2\.m2\repository\junit\junit\4.3.1\junit- 4.3.1.ja
> r
> [DEBUG]
> K:\Repositories\maven2\.m2\repository\org\slf4j\slf4j-simple\1.4.0\slf
> 4j
> -simple-1.4.0.jar
> [DEBUG]
> K:\Repositories\maven2\.m2\repository\org\slf4j\slf4j-api\1.4.0\slf4j-
> ap
> i-1.4.0.jar
>
>
Hi Minto
I have reduced your output to show nothing but the test classpath that
is defined by your project.
As you can see, both target/classes and target/test-classes are
included.
(Twice, it seems.. kind of strange..)
Also your dependencies are listed.
The only stuff that is appended by Eclipse are the eclipse jars..
Note that compilation and running tests in Eclipse is done by Eclipse
itself, not by Maven.
If your custom classloader uses the system classloader for delegation,
there is no way to catch the additional libararies.
Since the sourceode of the classloader is already in your project, you
might as well adjust it.
Try using the context classloader as a parent instead.
Cheers
Jo
DISCLAIMER
De informatie in deze e-mail is vertrouwelijk en uitsluitend bestemd voor
de geadresseerde. Indien u niet de geadresseerde bent, wordt u er hierbij op
gewezen, dat u geen recht heeft kennis te nemen van de rest van deze e-mail,
deze te gebruiken, te kopieren of te verstrekken aan andere personen dan de
geadresseerde. Indien u deze e-mail abusievelijk hebt ontvangen, brengt u
dan alstublieft de afzender op de hoogte, waarbij u bij deze gevraagd wordt
het originele bericht te vernietigen. Politie Amsterdam-Amstelland is niet
verantwoordelijk voor de inhoud van deze e-mail en wijst iedere
aansprakelijkheid af voor en/of in verband met alle gevolgen en/of schade
van een onjuiste of onvolledige verzending ervan. Tenzij uitdrukkelijk het
tegendeel blijkt, kunnen aan dit bericht geen rechten worden ontleend. Het
gebruik van Internet e-mail brengt zekere risicos met zich. Daarom wordt
iedere aansprakelijkheid voor het gebruik van dit medium door de Politie
Amsterdam-Amstelland van de hand gewezen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Multi-project dependency issue
On 6/8/07, Orford, Ian <[EMAIL PROTECTED]> wrote: P is the parent POM that has modules A, B, C and D. P defines A, B, C and D in A has P as a parent and no dependencies at all. B has P as a parent and defines A in C has P as a parent and defines A and B in D has P as a parent and defines C in Mvn install compiles A, then B. The trouble starts because it then moves onto D. Since C hasn't been installed, it fails. Hi Ian, Are you building from the directory that contains the parent pom.xml? Are modules A,B,C,D listed as modules in the parent pom.xml? Cheers Jo
Re: Classpath issues with maven 2.0.6
On 6/8/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: Snippet of the "mvn test -X" ouput: == [DEBUG] Test Classpath : [DEBUG] K:\Sources\Prefs\memoryprefs\target\test-classes [DEBUG] K:\Sources\Prefs\memoryprefs\target\classes [DEBUG] K:\Sources\Prefs\memoryprefs\target\classes [DEBUG] K:\Sources\Prefs\memoryprefs\target\test-classes [DEBUG] K:\Repositories\maven2\.m2\repository\junit\junit\4.3.1\junit-4.3.1.jar [DEBUG] K:\Repositories\maven2\.m2\repository\org\slf4j\slf4j-simple\1.4.0\slf4j -simple-1.4.0.jar [DEBUG] K:\Repositories\maven2\.m2\repository\org\slf4j\slf4j-api\1.4.0\slf4j-ap i-1.4.0.jar Hi Minto I have reduced your output to show nothing but the test classpath that is defined by your project. As you can see, both target/classes and target/test-classes are included. (Twice, it seems.. kind of strange..) Also your dependencies are listed. The only stuff that is appended by Eclipse are the eclipse jars.. Note that compilation and running tests in Eclipse is done by Eclipse itself, not by Maven. If your custom classloader uses the system classloader for delegation, there is no way to catch the additional libararies. Since the sourceode of the classloader is already in your project, you might as well adjust it. Try using the context classloader as a parent instead. Cheers Jo
Re: Classpath issues with maven 2.0.6
On 6/8/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: Hi Jo, Yes I have, look at the pom files below. Hi Minto I only see junit and 2 slf4j dependencies. The ReloadableClassLoader class you mentioned earlier.. Did you include it as source? I would expect a dependency to the library that contains it. Which class is causing the ClassNotFoundException? Also not that in the maven case the test and project classes are not part of the classpath being used by the tests. Could you paste some information about the build output when you run "mvn test -X"? Search for "classpathElements" and paste it back here. As I said earlier, you can't predict the classpath that is used to run your tests by looking at the classpath that is used to start Maven. PS. Groeten aan de flikken! ;) (Transl: Say hello to the cops) Cheers Jo
Re: [M2] List of pom configuration properties
Checkout Jason's exhaustive list at the sonatype website:
http://www.sonatype.com/book/properties.html
On 6/7/07, Jux <[EMAIL PROTECTED]> wrote:
Hi
Can anybody give me information about configuration properties that I can
use in maven2 pom.xml files. I am talking about the ${some.property} kind
of
properties :) I can't seem to find that kind on information anywhere.
Here and there I see properties like ${basedir} or ${pom.version}
mentioned
and they assume I know that already. I'd be happy to find a list of all
the
properties with explanation that I can use in pom.xml. I allso want to
know
about the logic behind it - inheritence and stuff like that. For example,
is
it possible to get the version number of my parent pom?
About filtering properties I don't need information - just the properties
that are ready for using.
Juhan.
--
View this message in context:
http://www.nabble.com/-M2--List-of-pom-configuration-properties-tf3882844s177.html#a11004932
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: assemble a huge JAR
Hi Ben, If you want to bundle all your dependencies in one jar, you could use the prefabricated "jar-with-dependencies" descriptor instead. http://maven.apache.org/plugins/maven-assembly-plugin/usage.html Check out a previous post: http://www.mail-archive.com/users@maven.apache.org/msg65381.html Cheers Jo
Re: Preflight check for 2.0.7
Jason, Nothing to report, everything works just fine. +1 for the release Cheers Jo On 6/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: I have built a snapshot for 2.0.7 and put it here: http://people.apache.org/~jvanzyl/ I figure folks are going to try and squeeze in more issues so what I plan is let people state their case for issues and I'll slot those into 2.0.8. I'll look those over and push whatever I can into 2.0.7 but I would like to call for vote on Wednesday let people mess around and release it on Monday. And you can see the roadmap here: http://jira.codehaus.org/browse/MNG? report=com.atlassian.jira.plugin.system.project:roadmap-panel Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
