Re: Proper way to build a Maven repository without Internet access
JFrog has an air-gap how-to. Do a search for "using-artifactory-with-an-air-gap” That maybe can help you? Henrik > On 14 Nov 2019, at 00:01, Stephen Connolly > wrote: > > So I know that Sonatype have or had a feature in nexus that let you approve > what dependencies could be consumed by developers from its hosted Maven > repo. If you used that you could then replicate the nexus storage back-end > to the offline network via sneaker-net (or better a dmz that only has > access to the developer nexus) > > Unclear if jfrog have a competitive feature > > On Thu 7 Nov 2019 at 23:22, Sean Horan wrote: > >> Hi all, >> >> I am tasked with ensuring that the Maven build process of a large >> government/enterprise-class system does not reach out to the Internet. Our >> Jenkins server's local maven repository has 10,000 POMs. There are many >> individual builds that are specific to our product and what we customize >> for government clients. >> >> I have a lot of devops experience but practically no experience with Maven >> and Java beyond struggling to set this up. >> >> We are using Artifactory and I'm not sure whether a generic or >> Maven-specific repository is suitable for this project. >> >> As I'm trying to understand it, I am using curl in a find/curl loop adapted >> from >> >> https://github.com/jfrog/project-examples/blob/master/bash-example/deploy-folder-by-checksum.sh >> >> to traverse the ~/.m2/repository on our existing Jenkins server and HTTP >> PUT it over to Artifactory. This script would be hardened and sent to >> internal customers to sync as part of the development process. >> >> The problem I am seeing is that the build process is looking for >> maven-metadata.xml which does not exist on our server. We do have >> -companyname and -central XML files for eg, the maven-source-plugin that >> are slightly different. >> >> I have the sense that my approach to this is off and I'm in over my head so >> I could use some help. >> >> Any pointers in the right direction would be more than welcome. >> >> We are using Maven 3.3.9 and JDK8 on Centos 7 and cannot upgrade at this >> time. >> >> Sean Horan >> > -- > Sent from my phone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn dependency:analyze fails with IllegalArgumentException
Hi Karl, That worked! Regards Henrik 2018-03-23 19:35 GMT+01:00 Karl Heinz Marbaise : > Hi Henrik, > > can you try to add the following to your pom configuration (just a try to > see if I'm on the right path): > > > > org.apache.maven.plugins > maven-dependency-plugin > > > org.ow2.asm > asm > 6.1 > > > > > and just give a try to rerun it... > > Kind regards > Karl Heinz Marbaise > > > On 21/03/18 23:02, Henrik Eriksson wrote: > >> Hello, >> >> Running mvn dependency:analyze fails with the follwing exception: >> >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze >> (default-cli) on project utils: Execution default-cli of goal >> org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed.: >> IllegalArgumentException -> [Help 1] >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute >> goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze >> (default-cli) on project utils: Execution default-cli of goal >> org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj >> oExecutor.java:213) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj >> oExecutor.java:154) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj >> oExecutor.java:146) >> at >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b >> uildProject(LifecycleModuleBuilder.java:117) >> at >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b >> uildProject(LifecycleModuleBuilder.java:81) >> at >> org.apache.maven.lifecycle.internal.builder.singlethreaded.S >> ingleThreadedBuilder.build(SingleThreadedBuilder.java:51) >> at >> org.apache.maven.lifecycle.internal.LifecycleStarter.execute >> (LifecycleStarter.java:128) >> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) >> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) >> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) >> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >> ke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >> invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnha >> nced(Launcher.java:289) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher.launch( >> Launcher.java:229) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithEx >> itCode(Launcher.java:415) >> at org.codehaus.plexus.classworlds.launcher.Launcher.main( >> Launcher.java:356) >> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution >> default-cli of goal >> org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. >> at >> org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj >> o(DefaultBuildPluginManager.java:145) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj >> oExecutor.java:208) >> ... 20 more >> Caused by: java.lang.IllegalArgumentException >> at org.objectweb.asm.ClassReader.(Unknown Source) >> at org.objectweb.asm.ClassReader.(Unknown Source) >> at org.objectweb.asm.ClassReader.(Unknown Source) >> at >> org.apache.maven.shared.dependency.analyzer.asm.DependencyCl >> assFileVisitor.visitClass(DependencyClassFileVisitor.java:65) >> at >> org.apache.maven.shared.dependency.analyzer.ClassFileVisitor >> Utils.visitClass(ClassFileVisitorUtils.java:163) >> at >> org.apache.maven.shared.dependency.analyzer.ClassFileVisitor >> Utils.acceptDirectory(ClassFileVisitorUtils.java:143) >> at >> org.apache.maven.shared.dependency.analyzer.ClassFileVisitor >> Utils.accept(ClassFileVisitorUtils.java:71) >> at >> org.apache.maven.shared.dependency.analyzer.asm.ASMDependenc >> yAnalyzer.analyze(ASMDependencyAnalyzer.java:50) >> at >> org.apache.maven.shared.dependency.analyzer.DefaultProjectDe >
mvn dependency:analyze fails with IllegalArgumentException
Hello, Running mvn dependency:analyze fails with the follwing exception: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze (default-cli) on project utils: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed.: IllegalArgumentException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze (default-cli) on project utils: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.0.2:analyze failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 20 more Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.objectweb.asm.ClassReader.(Unknown Source) at org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass(DependencyClassFileVisitor.java:65) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass(ClassFileVisitorUtils.java:163) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory(ClassFileVisitorUtils.java:143) at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept(ClassFileVisitorUtils.java:71) at org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze(ASMDependencyAnalyzer.java:50) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses(DefaultProjectDependencyAnalyzer.java:211) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses(DefaultProjectDependencyAnalyzer.java:198) at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze(DefaultProjectDependencyAnalyzer.java:74) at org.apache.maven.plugins.dependency.analyze.AbstractAnalyzeMojo.checkDependencies(AbstractAnalyzeMojo.java:298) at org.apache.maven.plugins.dependency.analyze.AbstractAnalyzeMojo.execute(AbstractAnalyzeMojo.java:250) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) ... 21 more [ERROR] [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command mvn --verison Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00) Maven home: /home/omit/bin/maven Java version: 9.0.4, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-9-oracle Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.13.0-37-generic", arch: "amd64", family: "unix" Does anyone know what that might be? /H
Long-running shutdown hook in forked JVM
Hi guys, I have a long-running shutdown hook registered for the JVM(s) forked by Surefire (org.apache.maven.plugins:maven-surefire-plugin:2.14). The hook uploads all kinds of analysis results (collected during JUnit tests) to a remote backend. All this upload can take up to a couple of minutes. Now the problem is that the forked JVM is terminated before the shutdown hook is finished, i.e., not all analysis data is uploaded. Reading through [1], I played with the configuration option "forkedProcessTimeoutInSeconds", however, it did not change anything. Any ideas on how to prevent the shutdown of forked JVMs until such (long-running) shutdown hooks are properly terminated? Thank you in advance, Cheers, Henrik [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html
Re: properties that are not being resolved
Thanks for the link. It was quite informative, but I'm again a little
confused because it is stated in your explanation,
the sections will have mojo-injected properties evaluated,
but that isn't the case in my example. I was trying to have such
properties evaluated in a element inside a
element for the ear plugin, but it would not work until I modified the
plugin to do an extra substitution itself.
Regards,
Henrik Gram
On Mon, Mar 24, 2014 at 10:38 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Please read my answer to a similar question on Stack Overflow:
>
> http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
>
>
> On 23 March 2014 21:36, Henrik Østerlund Gram
> wrote:
>
> > I stumbled over some rather strange behaviour regarding properties. It
> > seems properties generated by one plugin are not always resolved for
> other
> > plugins and I can't figure out why.
> >
> > I use a plugin to make info about the git branch available in the
> > properties so it can be passed to other plugins. The particular plugin
> > does not seem important, but I've included it here for sake of
> > completeness:
> >
> >
> > com.code54.mojo
> > buildversion-plugin
> > 1.0.3
> >
> > .MM.dd HH:mm
> >
> >
> >
> >
> > set-properties
> >
> >
> >
> >
> >
> > But when I referenced the properties set by the plugin in an env entry
> for
> > the maven ear plugin, the properties were not resolved at all:
> >
> >
> >
> > Middleware build information
> > java:app/env/sw-version
> > java.lang.String
> > ${build-commit} @ ${build-tstamp} built on
> > ${maven.build.timestamp}
> >
> >
> >
> > Just to be sure, I used the latest maven and tried both version 2.9 of
> the
> > plugin and the latest from the repo with the same result.
> >
> > The only way I managed to fix this was to patch the maven-ear-plugin
> > itself, adding the following code in
> GenerateApplicationXmlMojo.execute():
> >
> > // Fix env variable substitutions
> > Properties props = project.getProperties();
> > PlexusConfiguration[] entries = envEntries.getChildren();
> > if (entries != null) {
> > for (PlexusConfiguration entry : entries) {
> > if ("env-entry".equals(entry.getName())) {
> > PlexusConfiguration[] envEntryChildren = entry.getChildren();
> > if (envEntryChildren != null) {
> > for (PlexusConfiguration envEntryChild :
> envEntryChildren)
> > {
> >
> > envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> > props));
> > }
> > }
> > }
> > }
> > }
> >
> > Then it worked just fine, but I don't understand why this is necessary.
> I
> > thought whatever called the plugin was supposed to have done the variable
> > substitution already. So clearly the properties were present at the time
> > of executing the plugin, but they werent being automaticly substituted.
> >
> > To add to the confusion, using ${project.version} in the env-entry-value
> > was resolved just fine, but just not the properties coming from another
> > plugin despite the plugins being run in the correct order.
> >
> > To further add to the confusion, I then used maven ant-run plugin,
> echoing
> > the values of properties which worked just fine (!)
> >
> > While I solved the problem for me by making a locally patched version of
> > the ear plugin, it's not really a solution I favour, so I hope someone
> can
> > provide a better and more permanent fix.
> >
> > Regards,
> > Henrik Gram
> >
>
Re: properties that are not being resolved
Ok, I see.
Any chance of such a change making it into the official ear-plugin? I
think it would be generally useful to be able to reference properties in
the env-entry values. Could post a pull request if desired, but judging by
the months old ones at https://github.com/apache/maven-plugins/pulls it
doesn't appear those are being processed by anyone. Is there another way
to suggest that change be implemented?
Regards,
Henrik Gram
On Mon, Mar 24, 2014 at 9:13 AM, Anders Hammar wrote:
> It doesn't matter which plugin you use to set the property. What does
> matter is when the property substitution takes place. It normally happens
> in the very beginning of the Maven build when the pom is read, before the
> build lifecycle is executed and way before your plugin is executed. So you
> need the plugin (where you use the created property) to do an "extra"
> property substition step as you describe in your code.
>
> /Anders
>
>
> On Mon, Mar 24, 2014 at 9:04 AM, Henrik Østerlund Gram <
> henrik.g...@gmail.com> wrote:
>
> > The one at
> > http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ? It
> > states in the first couple of lines that it only works with subversion
> and
> > I'm using git.
> >
> > Aside from that, I can't really see why it would make a difference; how
> > many ways are there to set properties? I did establish that the
> properties
> > are indeed set as I can print them via the ant-run plugin and via the a
> > modified ear-plugin.
> >
> >
> >
> > On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus
> > wrote:
> >
> > > Hi,
> > > Out of curiosity, why don't you use the seemingly equivalent mojo
> > > buildnumber maven plugin? May not be your issue, but may be the plugin
> > > you're using doesn't create properties in the right way (no offense,
> just
> > > trying to guess)?
> > > My 2 cents
> > > Le 23 mars 2014 22:37, "Henrik Østerlund Gram"
> a
> > > écrit :
> > >
> > > > I stumbled over some rather strange behaviour regarding properties.
> It
> > > > seems properties generated by one plugin are not always resolved for
> > > other
> > > > plugins and I can't figure out why.
> > > >
> > > > I use a plugin to make info about the git branch available in the
> > > > properties so it can be passed to other plugins. The particular
> plugin
> > > > does not seem important, but I've included it here for sake of
> > > > completeness:
> > > >
> > > >
> > > > com.code54.mojo
> > > > buildversion-plugin
> > > > 1.0.3
> > > >
> > > > .MM.dd HH:mm
> > > >
> > > >
> > > >
> > > >
> > > > set-properties
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > But when I referenced the properties set by the plugin in an env
> entry
> > > for
> > > > the maven ear plugin, the properties were not resolved at all:
> > > >
> > > >
> > > >
> > > > Middleware build information
> > > > java:app/env/sw-version
> > > > java.lang.String
> > > > ${build-commit} @ ${build-tstamp} built on
> > > > ${maven.build.timestamp}
> > > >
> > > >
> > > >
> > > > Just to be sure, I used the latest maven and tried both version 2.9
> of
> > > the
> > > > plugin and the latest from the repo with the same result.
> > > >
> > > > The only way I managed to fix this was to patch the maven-ear-plugin
> > > > itself, adding the following code in
> > > GenerateApplicationXmlMojo.execute():
> > > >
> > > > // Fix env variable substitutions
> > > > Properties props = project.getProperties();
> > > > PlexusConfiguration[] entries = envEntries.getChildren();
> > > > if (entries != null) {
> > > > for (PlexusConfiguration entry : entries) {
> > > > if ("env-entry".equals(entry.getName())) {
> > > > PlexusConfiguration[] envEntryChildren =
> > entry.getChildren();
> > > > if (envEntryChildren != null) {
> > > > for (PlexusConfiguration envEntryChild :
> > > envEntryChildren)
> > > > {
> > > >
> > > >
> envEntryChild.setValue(StrSubstit
Re: properties that are not being resolved
The one at
http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ? It
states in the first couple of lines that it only works with subversion and
I'm using git.
Aside from that, I can't really see why it would make a difference; how
many ways are there to set properties? I did establish that the properties
are indeed set as I can print them via the ant-run plugin and via the a
modified ear-plugin.
On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus wrote:
> Hi,
> Out of curiosity, why don't you use the seemingly equivalent mojo
> buildnumber maven plugin? May not be your issue, but may be the plugin
> you're using doesn't create properties in the right way (no offense, just
> trying to guess)?
> My 2 cents
> Le 23 mars 2014 22:37, "Henrik Østerlund Gram" a
> écrit :
>
> > I stumbled over some rather strange behaviour regarding properties. It
> > seems properties generated by one plugin are not always resolved for
> other
> > plugins and I can't figure out why.
> >
> > I use a plugin to make info about the git branch available in the
> > properties so it can be passed to other plugins. The particular plugin
> > does not seem important, but I've included it here for sake of
> > completeness:
> >
> >
> > com.code54.mojo
> > buildversion-plugin
> > 1.0.3
> >
> > .MM.dd HH:mm
> >
> >
> >
> >
> > set-properties
> >
> >
> >
> >
> >
> > But when I referenced the properties set by the plugin in an env entry
> for
> > the maven ear plugin, the properties were not resolved at all:
> >
> >
> >
> > Middleware build information
> > java:app/env/sw-version
> > java.lang.String
> > ${build-commit} @ ${build-tstamp} built on
> > ${maven.build.timestamp}
> >
> >
> >
> > Just to be sure, I used the latest maven and tried both version 2.9 of
> the
> > plugin and the latest from the repo with the same result.
> >
> > The only way I managed to fix this was to patch the maven-ear-plugin
> > itself, adding the following code in
> GenerateApplicationXmlMojo.execute():
> >
> > // Fix env variable substitutions
> > Properties props = project.getProperties();
> > PlexusConfiguration[] entries = envEntries.getChildren();
> > if (entries != null) {
> > for (PlexusConfiguration entry : entries) {
> > if ("env-entry".equals(entry.getName())) {
> > PlexusConfiguration[] envEntryChildren = entry.getChildren();
> > if (envEntryChildren != null) {
> > for (PlexusConfiguration envEntryChild :
> envEntryChildren)
> > {
> >
> > envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> > props));
> > }
> > }
> > }
> > }
> > }
> >
> > Then it worked just fine, but I don't understand why this is necessary.
> I
> > thought whatever called the plugin was supposed to have done the variable
> > substitution already. So clearly the properties were present at the time
> > of executing the plugin, but they werent being automaticly substituted.
> >
> > To add to the confusion, using ${project.version} in the env-entry-value
> > was resolved just fine, but just not the properties coming from another
> > plugin despite the plugins being run in the correct order.
> >
> > To further add to the confusion, I then used maven ant-run plugin,
> echoing
> > the values of properties which worked just fine (!)
> >
> > While I solved the problem for me by making a locally patched version of
> > the ear plugin, it's not really a solution I favour, so I hope someone
> can
> > provide a better and more permanent fix.
> >
> > Regards,
> > Henrik Gram
> >
>
properties that are not being resolved
I stumbled over some rather strange behaviour regarding properties. It
seems properties generated by one plugin are not always resolved for other
plugins and I can't figure out why.
I use a plugin to make info about the git branch available in the
properties so it can be passed to other plugins. The particular plugin
does not seem important, but I've included it here for sake of completeness:
com.code54.mojo
buildversion-plugin
1.0.3
.MM.dd HH:mm
set-properties
But when I referenced the properties set by the plugin in an env entry for
the maven ear plugin, the properties were not resolved at all:
Middleware build information
java:app/env/sw-version
java.lang.String
${build-commit} @ ${build-tstamp} built on
${maven.build.timestamp}
Just to be sure, I used the latest maven and tried both version 2.9 of the
plugin and the latest from the repo with the same result.
The only way I managed to fix this was to patch the maven-ear-plugin
itself, adding the following code in GenerateApplicationXmlMojo.execute():
// Fix env variable substitutions
Properties props = project.getProperties();
PlexusConfiguration[] entries = envEntries.getChildren();
if (entries != null) {
for (PlexusConfiguration entry : entries) {
if ("env-entry".equals(entry.getName())) {
PlexusConfiguration[] envEntryChildren = entry.getChildren();
if (envEntryChildren != null) {
for (PlexusConfiguration envEntryChild : envEntryChildren) {
envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
props));
}
}
}
}
}
Then it worked just fine, but I don't understand why this is necessary. I
thought whatever called the plugin was supposed to have done the variable
substitution already. So clearly the properties were present at the time
of executing the plugin, but they werent being automaticly substituted.
To add to the confusion, using ${project.version} in the env-entry-value
was resolved just fine, but just not the properties coming from another
plugin despite the plugins being run in the correct order.
To further add to the confusion, I then used maven ant-run plugin, echoing
the values of properties which worked just fine (!)
While I solved the problem for me by making a locally patched version of
the ear plugin, it's not really a solution I favour, so I hope someone can
provide a better and more permanent fix.
Regards,
Henrik Gram
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi Robert Thanks - that sounds interesting and I will look into that Monday. But what is the right way to deploy a zip file build in the project to the artifactory repository then? Is it to only use deploy? Regards Henrik Skriver Rasmussen > On Feb 16, 2014, at 14:47, "Robert Scholte" wrote: > > Hi Henrik, > > IMHO deploy-file (just like install-file) should *never* be a part of a > lifecycle, but should be run standalone and should only be used for > unavailable third party artifacts. > > Looking back at your pom-fragment, you should do the following: > * if "deploymentfile" is being created by a Maven plugin, try to make that > plugin attach that file to the project. > * Use > http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html > and remove the deploy-file asap. This plugin does it's work as part of the > build lifecycle as it should be. > > Robert > > Op Sun, 16 Feb 2014 11:20:39 +0100 schreef Henrik Skriver Rasmussen > : > >> Hi Robert >> Thank you for your answer. >> >> I would like to figure out how to simple skip the generation of the given >> extra zip file because I do not know how now. >> Any way to see during debug which goal will result in which artifact? Any >> help on finding out when running my build will be appreciated. >> I can not omit what I do not know to control nor can I not attach it when I >> do no what generates it. >> >> Not creating or attaching the artifact solves the problem - but still, as >> user of maven I still say that it is counter intuitive to have the >> deploy-file goal not only deploy the specified file. >> The deploy goal should deploy all - but not the deploy-file goal. :) >> I know that is a different discussion about meaningful naming of APIs and >> frankly I don't care now that I know. >> But maven developers should care about simplifying and make maven APIs >> intuitive since maven is not exactly gaining ground due to it's simplicity >> and transparency. ;) >> >> That being said, I have been using maven for a looong time and enjoy it >> most of the time - so keep up the good work! >> >> regards >> Henrik Skriver Rasmussen >> >> >> On Sun, Feb 16, 2014 at 2:03 PM, Robert Scholte wrote: >> >>> Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen < >>> skrive...@gmail.com>: >>> >>> >>> Thanks for the advice on how to restructure. >>>> Could you have a look at the deploy-plugin project and the file >>>> org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in >>>> version 2.8.1 ? I would really like to understand the following: >>>> 1) What controls which artifacts are attached the model for the given >>>> project? >>>> >>> >>> The plugin creating that artifact controls the attaching. For example: >>> http://maven.apache.org/plugins/maven-source-plugin/ >>> xref/org/apache/maven/plugin/source/AbstractSourceJarMojo.html#307 >>> Here the -sources.jar is attached to the project. >>> >>> >>> 2) Is it possible to state that no artifacts except explicitly stated >>>> should be created/attached? >>>> >>> >>> The plugin creating that artifact >>> >>> >>> 3) Is it really the intended behaviour of the deploy:file goal to also >>>> deploy the attached artifacts? To me that is a very non-intuitive >>>> behaviour. >>>> >>> >>> Yes. If there are attachments created and these are attached, they are >>> uploaded as well. So if you don't want this, solve it at the source, i.e >>> the plugin creating the artifact. (for the maven-source-plugin: skip it >>> (best option) or just don't attach (acceptable option) ) >>> For the same reason you won't find "delete" options in any of the plugins. >>> It is a matter of excluding the correct files. >>> >>> Robert >>> >>> >>>> I Basically have a working setup which deploys the zip file I generate to >>>> repo with the name I have specified. But the only thing that bothers me is >>>> that for some unclear reason the same zip is deployed again with the name >>>> of the project in the same deploy:file goal. To me - that is a bug. >>>> Should I open an issue instead somewhere and provide the patch which fixes >>>> this?? >>>> I already mailed the email listed in the top of the java file
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi Robert Thank you for your answer. I would like to figure out how to simple skip the generation of the given extra zip file because I do not know how now. Any way to see during debug which goal will result in which artifact? Any help on finding out when running my build will be appreciated. I can not omit what I do not know to control nor can I not attach it when I do no what generates it. Not creating or attaching the artifact solves the problem - but still, as user of maven I still say that it is counter intuitive to have the deploy-file goal not only deploy the specified file. The deploy goal should deploy all - but not the deploy-file goal. :) I know that is a different discussion about meaningful naming of APIs and frankly I don't care now that I know. But maven developers should care about simplifying and make maven APIs intuitive since maven is not exactly gaining ground due to it's simplicity and transparency. ;) That being said, I have been using maven for a looong time and enjoy it most of the time - so keep up the good work! regards Henrik Skriver Rasmussen On Sun, Feb 16, 2014 at 2:03 PM, Robert Scholte wrote: > Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen < > skrive...@gmail.com>: > > > Thanks for the advice on how to restructure. >> Could you have a look at the deploy-plugin project and the file >> org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in >> version 2.8.1 ? I would really like to understand the following: >> 1) What controls which artifacts are attached the model for the given >> project? >> > > The plugin creating that artifact controls the attaching. For example: > http://maven.apache.org/plugins/maven-source-plugin/ > xref/org/apache/maven/plugin/source/AbstractSourceJarMojo.html#307 > Here the -sources.jar is attached to the project. > > > 2) Is it possible to state that no artifacts except explicitly stated >> should be created/attached? >> > > The plugin creating that artifact > > > 3) Is it really the intended behaviour of the deploy:file goal to also >> deploy the attached artifacts? To me that is a very non-intuitive >> behaviour. >> > > Yes. If there are attachments created and these are attached, they are > uploaded as well. So if you don't want this, solve it at the source, i.e > the plugin creating the artifact. (for the maven-source-plugin: skip it > (best option) or just don't attach (acceptable option) ) > For the same reason you won't find "delete" options in any of the plugins. > It is a matter of excluding the correct files. > > Robert > > >> I Basically have a working setup which deploys the zip file I generate to >> repo with the name I have specified. But the only thing that bothers me is >> that for some unclear reason the same zip is deployed again with the name >> of the project in the same deploy:file goal. To me - that is a bug. >> Should I open an issue instead somewhere and provide the patch which fixes >> this?? >> I already mailed the email listed in the top of the java file in question >> but he does not reply. >> >> >> >> Med venlig hilsen >> Henrik Skriver Rasmussen >> >> >> On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar wrote: >> >> You should really restart with the module 2 pom. >>> >>> Your multi-module structure is good. You have a separate projekt/module >>> which creates your distro. What you should do is to create the "distro" >>> (zip or whatever) to be created as part of the normal build and then >>> deployed as the project's artifact it is. >>> This is done in many projects and you could for example have a look at >>> the >>> Maven core project where we create a zip and a tar file. >>> >>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree; >>> f=apache-maven;hb=HEAD >>> >>> So in the end, you will not use deploy:deploy-file. Also, your pom will >>> be >>> very small with pretty much only the m-assembly-p being bound to the >>> build >>> lifecycle. >>> >>> /Anders >>> >>> >>> On Thu, Feb 13, 2014 at 11:36 AM, Henrik Skriver Rasmussen < >>> skrive...@gmail.com> wrote: >>> >>> > Hi Anders >>> > >>> > I have a multi-module project with this structure: >>> > >>> > A (root and parent pom project) >>> > - module 1 - builds a jar as artifact >>> > - module 2 - uses module 1 jar artifact in assembly tries to deploy >>> the >>
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Thanks for the advice on how to restructure.
Could you have a look at the deploy-plugin project and the file
org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in
version 2.8.1 ? I would really like to understand the following:
1) What controls which artifacts are attached the model for the given
project?
2) Is it possible to state that no artifacts except explicitly stated
should be created/attached?
3) Is it really the intended behaviour of the deploy:file goal to also
deploy the attached artifacts? To me that is a very non-intuitive
behaviour.
I Basically have a working setup which deploys the zip file I generate to
repo with the name I have specified. But the only thing that bothers me is
that for some unclear reason the same zip is deployed again with the name
of the project in the same deploy:file goal. To me - that is a bug.
Should I open an issue instead somewhere and provide the patch which fixes
this??
I already mailed the email listed in the top of the java file in question
but he does not reply.
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar wrote:
> You should really restart with the module 2 pom.
>
> Your multi-module structure is good. You have a separate projekt/module
> which creates your distro. What you should do is to create the "distro"
> (zip or whatever) to be created as part of the normal build and then
> deployed as the project's artifact it is.
> This is done in many projects and you could for example have a look at the
> Maven core project where we create a zip and a tar file.
>
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=apache-maven;hb=HEAD
>
> So in the end, you will not use deploy:deploy-file. Also, your pom will be
> very small with pretty much only the m-assembly-p being bound to the build
> lifecycle.
>
> /Anders
>
>
> On Thu, Feb 13, 2014 at 11:36 AM, Henrik Skriver Rasmussen <
> skrive...@gmail.com> wrote:
>
> > Hi Anders
> >
> > I have a multi-module project with this structure:
> >
> > A (root and parent pom project)
> > - module 1 - builds a jar as artifact
> > - module 2 - uses module 1 jar artifact in assembly tries to deploy the
> > assembled zip file to artifactory.
> >
> > This is the module 2 pom file with inserted to replace project
> > specific names.
> >
> > http://maven.apache.org/POM/4.0.0";
> >
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> >
> > 4.0.0
> >
> >
> >
> >
> >
> >
> >
> > 1.1-SNAPSHOT
> >
> >
> >
> > scripts
> >
> > pom
> >
> > scripts
> >
> >
> >
> >
> >
> > UTF-8
> >
> >
> UTF-8
> >
> > ${project.parent.basedir}
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > org.apache.maven.plugins
> >
> > maven-install-plugin
> >
> > 2.5.1
> >
> >
> >
> > true
> >
> >
> >
> >
> >
> >
> >
> > org.apache.maven.plugins
> >
> > maven-assembly-plugin
> >
> > 2.4
> >
> >
> >
> > true
> >
> >
> >
> >
> >
> >
> >
> > org.apache.maven.plugins
> >
> > maven-deploy-plugin
> >
> > 2.8.1
> >
> >
> >
> > true
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > deployprofile
> >
> >
> >
> >
> >
> >
> >
> >org.codehaus.mojo
> >
> >exec-maven-plugin
> >
> >1.2.1
> >
> >
> >
> >
> >
> > Copy into target folder and copy service jar into files/default
> >
> >
> > package
> >
> >
> >
> > exec
> >
> >
> >
> >
> >
> > ${project.basedir}/build_cookbook.sh
> >
> >
> >
> > ${project.parent.artifactId}
> >
> > ${project.parent.version}
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi Anders
I have a multi-module project with this structure:
A (root and parent pom project)
- module 1 - builds a jar as artifact
- module 2 - uses module 1 jar artifact in assembly tries to deploy the
assembled zip file to artifactory.
This is the module 2 pom file with inserted to replace project
specific names.
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
1.1-SNAPSHOT
scripts
pom
scripts
UTF-8
UTF-8
${project.parent.basedir}
org.apache.maven.plugins
maven-install-plugin
2.5.1
true
org.apache.maven.plugins
maven-assembly-plugin
2.4
true
org.apache.maven.plugins
maven-deploy-plugin
2.8.1
true
deployprofile
org.codehaus.mojo
exec-maven-plugin
1.2.1
Copy into target folder and copy service jar into files/default
package
exec
${project.basedir}/build_cookbook.sh
${project.parent.artifactId}
${project.parent.version}
org.apache.maven.plugins
maven-assembly-plugin
2.4
deployprofile
package
single
${project.parent.artifactId}-${project.parent.version}
${project.build.directory}/
true
assembly/dist.xml
org.apache.maven.plugins
maven-deploy-plugin
cookbook
deploy
deploy-file
false
artifactory
zip
${project.distributionManagement.snapshotRepository.url}
false
${project.parent.artifactId}
${project.parent.groupId}
${project.parent.version}
deploymentfile
${project.build.directory}/${project.parent.artifactId}-${project.parent.version}-deploymentfile.zip
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 2:15 PM, Anders Hammar wrote:
> You need to provide more info on what you're doing! Is the
> deploy:deploy-file bound to the build lifecycle of a project? How?
>
> /Anders
>
>
> On Thu, Feb 13, 2014 at 11:06 AM, Henrik Skriver Rasmussen <
> skrive...@gmail.com> wrote:
>
> > Hi
> >
> > I have a question about the expected behaviour of the deploy:deploy-file
> > goal in the maven deploy plugin 2.8.1 which I am currently using to
> deploy
> > one file.
> >
> > It surprised me that no matter what I did I kept getting more artifacts
> > deployed that I asked for and the reason is in the
> > org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the
> > attached artifacts are also deployed.
> >
> > Is this intended behaviour and if so how can I avoid this from happening?
> >
> > The goal name deploy-file indicates that one artifact (possible incl.
> > pom/metadata) is to be deployed and not also a throng of other artifacts.
> >
> > I will be happy to provide a patch where this is aspect is removed.
> >
> > Thank you in advance
> >
> > regards
> > Henrik Skriver Rasmussen
> >
>
Fwd: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi I have a question about the expected behaviour of the deploy:deploy-file goal in the maven deploy plugin 2.8.1 which I am currently using to deploy one file. It surprised me that no matter what I did I kept getting more artifacts deployed that I asked for and the reason is in the org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the attached artifacts are also deployed. Is this intended behaviour and if so how can I avoid this from happening? The goal name deploy-file indicates that one artifact (possible incl. pom/metadata) is to be deployed and not also a throng of other artifacts. I will be happy to provide a patch where this is aspect is removed. Thank you in advance regards Henrik Skriver Rasmussen
Re: Maven compiler fails non-randomly
This issue is still haunting me. The same project could be running on one machine but run fine on another. Wiped repos, diffrent JDKs, OSs etc. It fails "randomly" since there are no apparant situation left I can think of why it should fail. But when it fails it always fails at the same place, same file, same line when telling javac to be verbose. But only when building in the same reactor order. Swapping places of modules might work, and if one use -rf :module to continue the build it compiles. It's so damn annoying. The whole project build have been building flawlessly without any problmes. The difference now is that I've added annotation processing. 2013/1/11 Henrik Eriksson > Well seems like its not solved. This time I cant trace it to usage of suns > classes, and the condition is reverse now, building the whole project > doesn't render in an error but building a part of the reactor with -rf > renders the below error which builds when building the whole project. Seems > like the whole build is unstable somehow. Notably is that all this is > building today. > > > [loading > ZipFileIndexFileObject[C:\bea12\jdk1.7.0_04_x86\lib\ct.sym(META-INF/sym/rt.jar/java/util/Comparator.class)]] > An exception has occurred in the compiler (1.7.0_04). Please file a bug at > the Java Developer Connection (http://java.sun.com/webapps/bugreport) > after checking > the Bug Parade for duplicates. Include your program and the following > diagnostic in your report. Thank you. > java.lang.IllegalAccessError: tried to access class > com.sun.tools.javac.code.Kinds$1 from class com.sun.tools.javac.code.Kinds > at com.sun.tools.javac.code.Kinds.kindName(Kinds.java:146) > at com.sun.tools.javac.comp.Attr.checkMethod(Attr.java:2794) > at com.sun.tools.javac.comp.Attr.checkId(Attr.java:2570) > at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:2354) > at > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1677) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) > at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:449) > at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1514) > at > com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1321) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) > at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:460) > at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1287) > at > com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1167) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) > at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:480) > at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:496) > at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:911) > at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:781) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) > at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:480) > at com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:829) > at > com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:669) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) > at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:480) > at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:3241) > at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:3164) > at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:3100) > at com.sun.tools.javac.comp.Attr.attrib(Attr.java:3074) > at > com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1184) > at > com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:870) > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:829) > at com.sun.tools.javac.main.Main.compile(Main.java:439) > at > com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132) > at > org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) > at > org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:170) > at > org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompiler
Re: Listing all attached artifacts for a specific GAV
Hello. Thank you for your reply. Well there is some sort of data about it in a local repository, not sure about what ends up in a remote one. I'm aware of that the artifact should declare the dependencies, and that was one of the ideas I had, though right now its pretty much impossible to do so due to other circumstances. For now I just settled to declare the main artifacts and look for them in a local repository. In our environment remote deployments are not utilized, so I don't have to look for it elsewhere . Pity though there is no "bulk" lookup feature, atleast for the same GAV. On the other hand updating a pom file during a build with new dependencies could set off the build entierly, wouldn't it? 2013/2/1 Anders Hammar > Don't think this is possible simply because the metadata about attached > artifacts doesn't exist. > > Please also note that all direct dependencies should be declared in the > pom. So if you're going to deploy to a repo your plugin needs to update the > pom-to-be-deployed and add this info. If you don't, any build declaring a > dependency to your artifact will fail because the dependency info is > missing. > > /Anders > > > On Fri, Feb 1, 2013 at 12:10 AM, Henrik Eriksson < > henrikeriksso...@gmail.com > > wrote: > > > Hello. > > > > I'm writing a plugin and I'm wondering if there is any way of retrieving > an > > artifact's attached artifacts in a repository. I know the main artifact > but > > like to get the attached ones too. There are several workarounds for > this, > > but I would like to find out if there is a better way. I have been > > searching the APIs and documentation but haven't yet found a nice way of > > doing it. The reason of doing this is because I'd like to so you don't > need > > to declare them in a pom. > > > > Example: > > com.acme.comp:artifact:ear:1.0 <-- main artifact > > com.acme.comp:artifact:attachment1:xml <-- attachment which I'd like to > get > > programmatically without knowing the classifier name. > > > > TIA > > Henrik > > >
Re: Maven compiler fails non-randomly
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] An unknown compilation problem occurred [INFO] 1 error Im going to try switching to another jdk today to see if the same error is there. 2013/1/10 Henrik Eriksson > No multithread build. > Windows 7x64 > changed to alwaysNew > changed to 3.0 > > I isolated it to there's a class using sun.misc.BASE64Decoder() and this > reference is failing the build. The other problems are a result of the same > issue with properitary usage, but easy to remove. I moved the specific code > to a test and it fails when it tries to compile the test. If I compile the > module explicit it compiles nicely or restart the reactor build with -rf it > builds. I removed the properiatary class and replaced it with apaches. But > I still want the propertiary to run with the build in the test since there > are alot of things depending on that function and I want the tests to tell > me if there's any situation where it fails. The good thing is that now I > can clean the code from these mistakes :) > > > 2013/1/10 Olivier Lamy > >> with multi thread build -T x ? >> >> which os ? >> >> Can you try with changing value of >> >> http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy >> >> to alwaysNew ? >> >> Do you have same issues using compiler plugin 3.0 ? >> >> >> >> 2013/1/10 Henrik Eriksson : >> > Hi all! >> > I'm getting a wierd error which I don't understand yet. This is the >> > following stacktrace I get from javac: >> > [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ >> > warfile-war --- >> > [INFO] Compiling 15 source files to C:\\target\classes >> > [INFO] - >> > [ERROR] COMPILATION ERROR : >> > [INFO] - >> > [ERROR] Failure executing javac, but could not parse the error: >> > An exception has occurred in the compiler (1.7.0_04). Please file a bug >> at >> > the Java Developer Connection (http://java.sun.com/webapps/bugreport) >> > after checking >> > the Bug Parade for duplicates. Include your program and the following >> > diagnostic in your report. Thank you. >> > java.lang.LinkageError: loader constraint violation: loader (instance of >> > sun/misc/Launcher$AppClassLoader) previously initiated loading for a >> > different type wit >> > h name "com/sun/tools/javac/code/Symbol" >> > at java.lang.ClassLoader.defineClass1(Native Method) >> > at java.lang.ClassLoader.defineClass(ClassLoader.java:791) >> > at >> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) >> > at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) >> > at java.net.URLClassLoader.access$100(URLClassLoader.java:71) >> > at java.net.URLClassLoader$1.run(URLClassLoader.java:361) >> > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) >> > at java.security.AccessController.doPrivileged(Native Method) >> > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:423) >> > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) >> > at com.sun.tools.javac.code.Kinds.kindName(Kinds.java:146) >> > at com.sun.tools.javac.comp.Attr.checkMethod(Attr.java:2794) >> > at com.sun.tools.javac.c
Re: Maven compiler fails non-randomly
No multithread build. Windows 7x64 changed to alwaysNew changed to 3.0 I isolated it to there's a class using sun.misc.BASE64Decoder() and this reference is failing the build. The other problems are a result of the same issue with properitary usage, but easy to remove. I moved the specific code to a test and it fails when it tries to compile the test. If I compile the module explicit it compiles nicely or restart the reactor build with -rf it builds. I removed the properiatary class and replaced it with apaches. But I still want the propertiary to run with the build in the test since there are alot of things depending on that function and I want the tests to tell me if there's any situation where it fails. The good thing is that now I can clean the code from these mistakes :) 2013/1/10 Olivier Lamy > with multi thread build -T x ? > > which os ? > > Can you try with changing value of > > http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy > > to alwaysNew ? > > Do you have same issues using compiler plugin 3.0 ? > > > > 2013/1/10 Henrik Eriksson : > > Hi all! > > I'm getting a wierd error which I don't understand yet. This is the > > following stacktrace I get from javac: > > [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ > > warfile-war --- > > [INFO] Compiling 15 source files to C:\\target\classes > > [INFO] - > > [ERROR] COMPILATION ERROR : > > [INFO] - > > [ERROR] Failure executing javac, but could not parse the error: > > An exception has occurred in the compiler (1.7.0_04). Please file a bug > at > > the Java Developer Connection (http://java.sun.com/webapps/bugreport) > > after checking > > the Bug Parade for duplicates. Include your program and the following > > diagnostic in your report. Thank you. > > java.lang.LinkageError: loader constraint violation: loader (instance of > > sun/misc/Launcher$AppClassLoader) previously initiated loading for a > > different type wit > > h name "com/sun/tools/javac/code/Symbol" > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:791) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) > > at java.net.URLClassLoader.access$100(URLClassLoader.java:71) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:361) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:423) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > > at com.sun.tools.javac.code.Kinds.kindName(Kinds.java:146) > > at com.sun.tools.javac.comp.Attr.checkMethod(Attr.java:2794) > > at com.sun.tools.javac.comp.Attr.checkId(Attr.java:2570) > > at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:2354) > > at > > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1677) > > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) > > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) > > at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:449) > > at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1514) > > at > > > com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1321) > > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) > > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) > > at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:460) > > at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1287) > > at > > > com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1167) > > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) > > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) > > at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:480) > > at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:496) > > at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:911) > > at > com.sun.tools.javac.tree.JCTree
Re: Setting a plugins configruation parameter
Solved it, works perfectly now. I was overriding the property in a pom higher up in the hirarchy. RTFM. :) 2012/12/31 Stephen Connolly > Not just you. And the worst part is that Maven gets the blame for these > shitty plugins. > > It's not Maven it's you (the shitty plugin authors). > > > On 31 December 2012 15:00, Anders Hammar wrote: > > > It might just be me, but I get tired of these crappy Maven plugins not > > doing things the Maven way and forcing the users to create even worse > > patchy solution to use them. Sticking with Ant or some other tool might > be > > a better solution than twisting Maven's arm. > > > > /Anders > > > > > > On Mon, Dec 31, 2012 at 1:41 PM, Benson Margulies > >wrote: > > > > > I think you need the invoker plugin so that you can set up and run the > > > annoying one as configured by your other stuff. > > > > > > On Mon, Dec 31, 2012 at 1:00 AM, Henrik Eriksson > > > wrote: > > > > The somcomp-maven-plugin isn't mine plugin, I've not written it and > the > > > > code isn't public, ie I can't modify it without breaking licences and > > > > patches. A solution would be to wrap it but I don't want to do that > > > either. > > > > This plugin requries that you setup a path with jars which the plugin > > > uses > > > > then it executes instead of using the maven way ie declaring it in > the > > > > pom. Also some processing needs to be done to those jars since the > > plugin > > > > doesn't agree with some of those jars because they doesn't follow > > specs. > > > My > > > > plugin preprocesses these jars, to keep the project in a "maven" > style. > > > So > > > > I need to set that plugin parameter somehow. > > > > > > > > Not sure how attaching the information would solve this propblem. > > > > > > > > //Henrik > > > > > > > > > > > > 2012/12/30 Anders Hammar > > > > > > > >> One other aspect, why two separate plugins? As they seem to be > tightly > > > >> coupled I would argue for one plugin with two goals. It makes more > > sense > > > >> having this tight coupling between two goals than between two > plugins. > > > >> You should then have a look at some plugins that does similar things > > > (one > > > >> goal preparing something for another goal). I *think* it is often > > > solved by > > > >> storing it in a file as Benson points out, but I also *think* I've > > seen > > > >> plugins putting info in system properties for the next goal to > > consume. > > > One > > > >> plugin doing the latter is Mojo's RPM plugin. One plugin doing the > > > former > > > >> is the Maven Release plugin (prepare and perform goals). > > > >> > > > >> /Anders > > > >> > > > >> > > > >> On Sun, Dec 30, 2012 at 3:33 AM, Benson Margulies < > > > bimargul...@gmail.com > > > >> >wrote: > > > >> > > > >> > On Sat, Dec 29, 2012 at 8:25 PM, Henrik Eriksson > > > >> > wrote: > > > >> > > I'm writing a plugin for bridging propertiary software with > maven. > > > So > > > >> > > making a portable project is not an option here. The project > will > > > only > > > >> be > > > >> > > used in our own development. So the problem I have. I have one > > > plugin > > > >> > > setting up a property for the other plugin. They are in the same > > > pom. > > > >> And > > > >> > > looks something like this. > > > >> > > > > > >> > > > > > >> > > ... > > > >> > > > > > >> > > com.acme > > > >> > > myplugin-maven-plugin > > > >> > > 1.0 > > > >> > > ... > > > >> > > package > > > >> > > > > > >> > > > > > >> > > com.somecomp > > > >> > > somcomp-maven-plugin > > > >> > > 1.1 > > > >> > > > > > >> > > > > > >> > > package > > > >> > > > &g
Re: Setting a plugins configruation parameter
The somcomp-maven-plugin isn't mine plugin, I've not written it and the
code isn't public, ie I can't modify it without breaking licences and
patches. A solution would be to wrap it but I don't want to do that either.
This plugin requries that you setup a path with jars which the plugin uses
then it executes instead of using the maven way ie declaring it in the
pom. Also some processing needs to be done to those jars since the plugin
doesn't agree with some of those jars because they doesn't follow specs. My
plugin preprocesses these jars, to keep the project in a "maven" style. So
I need to set that plugin parameter somehow.
Not sure how attaching the information would solve this propblem.
//Henrik
2012/12/30 Anders Hammar
> One other aspect, why two separate plugins? As they seem to be tightly
> coupled I would argue for one plugin with two goals. It makes more sense
> having this tight coupling between two goals than between two plugins.
> You should then have a look at some plugins that does similar things (one
> goal preparing something for another goal). I *think* it is often solved by
> storing it in a file as Benson points out, but I also *think* I've seen
> plugins putting info in system properties for the next goal to consume. One
> plugin doing the latter is Mojo's RPM plugin. One plugin doing the former
> is the Maven Release plugin (prepare and perform goals).
>
> /Anders
>
>
> On Sun, Dec 30, 2012 at 3:33 AM, Benson Margulies >wrote:
>
> > On Sat, Dec 29, 2012 at 8:25 PM, Henrik Eriksson
> > wrote:
> > > I'm writing a plugin for bridging propertiary software with maven. So
> > > making a portable project is not an option here. The project will only
> be
> > > used in our own development. So the problem I have. I have one plugin
> > > setting up a property for the other plugin. They are in the same pom.
> And
> > > looks something like this.
> > >
> > >
> > > ...
> > >
> > > com.acme
> > > myplugin-maven-plugin
> > > 1.0
> > > ...
> > > package
> > >
> > >
> > > com.somecomp
> > > somcomp-maven-plugin
> > > 1.1
> > >
> > >
> > > package
> > >
> > > this is the one I want to set with
> > > myplugin-maven-plugin
> > > ...
> > >
> > > ...
> > >
> > >
> > >
> > > ...
> > >
> > >
> > > I've tried with setting
> > > ${someproperty}
> > > I've tried various things but no success. Perhaps setting it before the
> > > project is being built may solve setting it but makes the project alot
> > more
> > > complex. The thing is that somcomp-maven-plugin does a lot of wierd
> > stuff,
> > > ie not mavenish but I believe its trying to isolate things from the
> > > "normal" maven flow. Though our deployment/development environment has
> a
> > > lot of legacy and presents various issues by not doing this.
> > >
> > > TIA
> >
> > I can't make sense of this. What is happening? What don't you like
> > about what's happening? What do you want to have happen instead? Is
> > the bottom line that you want some information to flow from plugin (1)
> > to plugin (2)? In that case, you might have to write out a file in
> > (1), attach it to the build, and consume it in (2).
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
Re: Maven 3.0.3 hanging / having timeouts often?
Interesting. Do you have an example of another Java application that has network connectivity problems? Then I could try it to see if it is the combination Java / network hardware that is the culprit. Just for the record, my JAVA_HOME is C:\Program Files\Java\jdk1.7.0_03, but when I run "java -version", I get "java version "1.6.0_31"". The computer in question is a Sony Vaio laptop, with an Atheros AR9285 wireless network adapter. /Henrik Arro martin.eisengardt wrote > > I got some similar problems. > https://bugs.eclipse.org/bugs/show_bug.cgi?id=362418 > Seems that java itself or maven or any other thing is not liking my aviara > firewall or my network device. There are some other java apps that > sometime > have the same connection problems resulting in timeouts. Are there any > hints what maven is doing (activate debug option) or can you simply wait > to > see if it is the same network timeout issue? > -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-0-3-hanging-having-timeouts-often-tp4388958p5664491.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Thanks for the suggestion, but unfortunately the same behavior when running Maven in a Windows command-line (cmd.exe). Running "mvn -X" does not provide much useful information, as far as I can tell, just a timeout after around 30 minutes: [DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://repo.maven.apache.org/maven2 Downloading: http://repo.maven.apache.org/maven2/org/codehaus/groovy/groovy/1.8.3/groovy-1.8.3.jar [DEBUG] Writing resolution tracking file C:\Users\Henrik Arro\.m2\repository\org\codehaus\groovy\groovy\1.8.3\groovy-1.8.3.jar.lastUpdated [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 30:02.959s [INFO] Finished at: Wed Apr 25 09:35:49 CEST 2012 [INFO] Final Memory: 10M/105M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on project standalone-pom: Execution default-cli of goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate failed: Plugin o rg.apache.maven.plugins:maven-archetype-plugin:2.2 or one of its dependencies could not be resolved: Could not transfer artifact org.codehaus.groovy:groovy:jar:1.8.3 from/to central (http://repo.maven.apache.org/maven2): GET request of: org/codehaus/groovy/groovy/1.8.3/groovy-1.8.3.jar from central failed: Read timed out -> [Help 1] ... Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:150) at java.net.SocketInputStream.read(SocketInputStream.java:121) at org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:149) at org.apache.maven.wagon.providers.http.httpclient.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:110) at org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractSessionInputBuffer.read(AbstractSessionInputBuffer.java:195) at org.apache.maven.wagon.providers.http.httpclient.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:173) at org.apache.maven.wagon.providers.http.httpclient.conn.EofSensorInputStream.read(EofSensorInputStream.java:138) at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:238) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:116) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:493) at org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:339) ... 9 more Wayne Fay wrote > > Can you try building your projects with Maven 3.0.4 in Windows (not in > the Cygwin environment) to see if there is any difference? > -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-0-3-hanging-having-timeouts-often-tp4388958p5664251.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency overriding.
Hi John, there is such a thing as dependency exclusions, that might help you in this: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html cheers, Phh On Fri, Dec 3, 2010 at 1:14 AM, asdas adasads wrote: > Hi, > > My project has two pom's. One is a called a super pom and contains basic > configuration for the whole project. Second pom declares "super pom" as its > parent. > In super pom you can find these dependency: > > > org.slf4j > slf4j-log4j12 > 1.5.6 > > > Which defines what kind of implementation all project should use for > logging. In the second pom (child) I want to declare different logging > implementation, namely: > > > org.slf4j > slf4j-nop > 1.5.6 > > > But it seems that the maven builds classpath is a way where dependency from > parent is before, dependency from child. So nop logging will not be used > during execution. > Is there any way change that ? (to use nop as logging implementation) I > cannot change "super pom" file. The behavior what I'm interested is the same > as method overriding in OOP. > > - John > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
hi
Hi , long time no seeing you ! There is good news I want to share . For a long time , I want to buy a laptop , one that is high quality but low price . This morning I got my laptop , just one week after I put the order on the site ( www.olcekn0.com ) . The site has many kinds of electric products , like mobile phones , TV , Games , and so on . All of the products are original and brand new . You can see it yourself in your spare time . I believe you won't disappoint and get some surprises . The laptop I get is really high quality and it arrives me so quickly . Hope you can get what you want on the site , too . Best regard . - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Compiler encoding on SuSE Linux
If you encode/decode one too many times you could get some weird behavior, like Ü(default)-> Ü(utf8) -> Ü(utf8)(utf8) and this one could be unreadable. Does both shell/java read that variable? As I remember those parameters, $LANG, could be used differently on different linus-dists... Cheers, Per On Mon, Oct 18, 2010 at 11:39 PM, Andreas Simon wrote: > The application is not internationalized, so I don't use property files in > the test code or tested code. > > The $LANG variable is de_DE.utf8 on both machines. > > Sorry, I didn't catch your last point. > > Am 18.10.2010 23:30, per-henrik hedman wrote: >> >> Are you using property files in resources? Those could be stored >> differently. >> >> What are your default encoding on your machines? It could be that some >> of the behavior, eg the different configurations that you are using >> aren't used and then it falls back to default behavior. >> >> Another thing can be that your are encoding an extra time, and that >> could make that kind of weird behavior... >> >> Good luck, >> Per >> >> >> On Mon, Oct 18, 2010 at 11:11 PM, Andreas Simon >> wrote: >> >>> >>> I verified the source code and the test code file with Linux' file >>> command. >>> Both are identified as "UTF-8 Unicode Java program text". I checked on >>> the >>> failing SuSE system. >>> >>> Am 18.10.2010 22:54, Anders Hammar wrote: >>> >>>> >>>> Have you verified that all Java files involved are in fact using UTF-8 >>>> char >>>> encoding (check on the machine where it fails!)? Check both source code >>>> and >>>> test code files. >>>> I don't think it's obvious that the are compiled with different >>>> encodings. >>>> The problem could maybe be that they are retrieved from your scm (or >>>> stored >>>> in the scm) with the wrong encoding. >>>> >>>> /Anders >>>> >>>> On Mon, Oct 18, 2010 at 22:30, Andreas Simon >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> Thank you for your reply! >>>>> >>>>> On my developer machine is Ubuntu 10.04. Same result when running >>>>> Oracle >>>>> JDK 1.6.0u21. >>>>> >>>>> What are you running on your developer machine? Can you run it with >>>>> Oracle >>>>> >>>>> >>>>>> >>>>>> JDK? >>>>>> >>>>>> Cheers, >>>>>> Per Hedman >>>>>> >>>>>> On Mon, Oct 18, 2010 at 8:51 PM, Andreas Simon >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I got a quite strange problem with my tests. I have 3 tests that >>>>>>> shall >>>>>>> control some messages for the user. These messages contain some >>>>>>> German >>>>>>> umlauts (ä, ö, ü and ß). On my Ubuntu developer machine the tests run >>>>>>> fine. >>>>>>> On my SuSE integration server the tests fail. The assertions fail >>>>>>> with >>>>>>> the >>>>>>> following message: >>>>>>> >>>>>>> expected:<...ü...> but was:<...??...> >>>>>>> >>>>>>> Obviously, the test files and the tested file are compiled with >>>>>>> different >>>>>>> encodings. >>>>>>> >>>>>>> I have tried several settings with UTF-8, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.maven.plugins >>>>>>> maven-compiler-plugin >>>>>>> 2.3.2 >>>>>>> >>>>>>> >>>>>>> src-compile >>>>>>> compile >>>>>>> >>>>>>> compile >>>>>>> >>>>>>> >>>>>>> 1.5 >>>>>>> 1.5 >>>>>>> UTF-8 >>>>&
Re: Compiler encoding on SuSE Linux
Are you using property files in resources? Those could be stored differently. What are your default encoding on your machines? It could be that some of the behavior, eg the different configurations that you are using aren't used and then it falls back to default behavior. Another thing can be that your are encoding an extra time, and that could make that kind of weird behavior... Good luck, Per On Mon, Oct 18, 2010 at 11:11 PM, Andreas Simon wrote: > I verified the source code and the test code file with Linux' file command. > Both are identified as "UTF-8 Unicode Java program text". I checked on the > failing SuSE system. > > Am 18.10.2010 22:54, Anders Hammar wrote: >> >> Have you verified that all Java files involved are in fact using UTF-8 >> char >> encoding (check on the machine where it fails!)? Check both source code >> and >> test code files. >> I don't think it's obvious that the are compiled with different encodings. >> The problem could maybe be that they are retrieved from your scm (or >> stored >> in the scm) with the wrong encoding. >> >> /Anders >> >> On Mon, Oct 18, 2010 at 22:30, Andreas Simon wrote: >> >> >>> >>> Thank you for your reply! >>> >>> On my developer machine is Ubuntu 10.04. Same result when running Oracle >>> JDK 1.6.0u21. >>> >>> What are you running on your developer machine? Can you run it with >>> Oracle >>> JDK? Cheers, Per Hedman On Mon, Oct 18, 2010 at 8:51 PM, Andreas Simon wrote: > > Hi all, > > I got a quite strange problem with my tests. I have 3 tests that shall > control some messages for the user. These messages contain some German > umlauts (ä, ö, ü and ß). On my Ubuntu developer machine the tests run > fine. > On my SuSE integration server the tests fail. The assertions fail with > the > following message: > > expected:<...ü...> but was:<...??...> > > Obviously, the test files and the tested file are compiled with > different > encodings. > > I have tried several settings with UTF-8, > > > > > org.apache.maven.plugins > maven-compiler-plugin > 2.3.2 > > > src-compile > compile > > compile > > > 1.5 > 1.5 > UTF-8 > true > UTF-8 > UTF-8 > -Dfile.encoding=utf8 > > > > default-compile > test-compile > > testCompile > > > 1.5 > 1.5 > UTF-8 > true > UTF-8 > UTF-8 > -Dfile.encoding=utf8 > > > > > 1.5 > 1.5 > UTF-8 > true > UTF-8 > UTF-8 > -Dfile.encoding=utf8 > > > > > > > UTF-8 > UTF-8 > > > Some settings are redundant, but two are better than one. Any way, > these > settings don't apply to the compiling of the test files. I have > searched > some hours for similar problems, but I found no other solution. To be > complete, my configuration: > > SuSE 11.1 > IBM JDK 1.5.0 > Maven 2.2.1 > > > Thanks for any idea, > Andreas > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Compiler encoding on SuSE Linux
What are you running on your developer machine? Can you run it with Oracle JDK? Cheers, Per Hedman On Mon, Oct 18, 2010 at 8:51 PM, Andreas Simon wrote: > Hi all, > > I got a quite strange problem with my tests. I have 3 tests that shall > control some messages for the user. These messages contain some German > umlauts (ä, ö, ü and ß). On my Ubuntu developer machine the tests run fine. > On my SuSE integration server the tests fail. The assertions fail with the > following message: > > expected:<...ü...> but was:<...??...> > > Obviously, the test files and the tested file are compiled with different > encodings. > > I have tried several settings with UTF-8, > > > > > org.apache.maven.plugins > maven-compiler-plugin > 2.3.2 > > > src-compile > compile > > compile > > > 1.5 > 1.5 > UTF-8 > true > UTF-8 > UTF-8 > -Dfile.encoding=utf8 > > > > default-compile > test-compile > > testCompile > > > 1.5 > 1.5 > UTF-8 > true > UTF-8 > UTF-8 > -Dfile.encoding=utf8 > > > > > 1.5 > 1.5 > UTF-8 > true > UTF-8 > UTF-8 > -Dfile.encoding=utf8 > > > > > > > UTF-8 > UTF-8 > > > Some settings are redundant, but two are better than one. Any way, these > settings don't apply to the compiling of the test files. I have searched > some hours for similar problems, but I found no other solution. To be > complete, my configuration: > > SuSE 11.1 > IBM JDK 1.5.0 > Maven 2.2.1 > > > Thanks for any idea, > Andreas > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Difference between archetype:create and archetype:generate?
The archetype:create generates an archetype once you have defined all the necessary properties for the archetype, while the archetype:generate gives you user interactive options for a number of template-archetypes. But they both generate/creates an archetype but in quite a different manner... Cheers, Per Hedman On Wed, Oct 6, 2010 at 2:28 PM, benxs wrote: > > What is the difference between these two goals? > > From my point of view both generate a project (directory structure). > > Ben > -- > View this message in context: > http://maven.40175.n5.nabble.com/Difference-between-archetype-create-and-archetype-generate-tp3201300p3201300.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: package question
Hello Daniel, you only need to define your dependency in your pom.xml and then maven will take care of it, but you will have to define it for yourself, as the version of the javamail needs to be correct, and only you know what version you are using, right? Cheers, Per-Henrik On Wed, Sep 15, 2010 at 10:11 AM, Daniel Rindt wrote: > Am Dienstag, den 14.09.2010, 21:37 +0200 schrieb per-henrik hedman: >> And given that it's within Tomcat it probably exists at Central, so >> you won't need to add a repository declaration to your pom.xml. > > Hey per, > > thanks for your reply. Yes i am talking about a jar, i mentioned as > package. So the package is always installed on all runtimes. So how can > i integrate it into my pom.xml properly? > The jar resides in /usr/share/java/javamail.jar. > > Thanks > Daniel > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Class loading issues while running tests
If you run: mvn -X test you should be able to decipher your classpath during the test-phase and see whats missing. Cheers, Per-Henrik On Tue, Sep 14, 2010 at 4:00 PM, nitingupta183 wrote: > > Hi All, > > I have got a multi-project setup in which one project is acting as a parent > project. Test classes in few of my projects are dependent upon test classes > on other projects. I have resolved the test classes dependency with the help > of maven-jar-plugin ( goal test-jar) & by importing the test classifier > dependency in test scope in the dependent project. > > Individual test cases run absolutely fine. However, when I run package, > test, install targets on my dependent project, they fail. The reason that is > coming out in logs is a test failure. Exactly those tests are failing which > have dependency on other project's test classes. No class def found. > > Please help me in solving this issue. i am using surefire plugin for running > tests. > -- > View this message in context: > http://maven.40175.n5.nabble.com/Class-loading-issues-while-running-tests-tp2839157p2839157.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: package question
I think you need to clarify.
Do you mean the jar, when you are talking about package?
If I understand you correctly you are meaning a jar, if so you should
declare a dependency to that jar. Probably you need to find it's pom
in some repository so that you can declare it correctly.
{group id for the classpathx-mail.jar}
{artifact id for the classpathx-mail.jar}
{version of the classpathx-mail.jar}
If you are talking about package as in java-package, you will have to
find where, in what jar, the package reside, and do the same for that
jar.
And given that it's within Tomcat it probably exists at Central, so
you won't need to add a repository declaration to your pom.xml.
You should also declare the as provided...
Cheers,
Per-Henrik
On Tue, Sep 14, 2010 at 2:43 PM, Daniel Rindt wrote:
> Hello,
>
> my Tomcat 5.5 is comming with the classpathx-mail package. I can use
> this package without mention it in the pom.xml. But when i want
> packaging it the compiler complains because it can't find the dependent
> classes. I guess i have to add the classpathx-mail package to my local
> m2 repository and place a in my pom.xml?
>
> TIA
> Daniel
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven *.ear build for SAP Web AS
If I understand you correctly, you are building ear-file and you want
to remove certain jars from that ear?
You could do that by:
javax.xml.soap
saaj-api
1.3
{groupId for jaxp-api}
jaxp-api.jar
1.4
Cheers,
Per-Henrik
Don't thi
On Fri, Sep 10, 2010 at 8:57 AM, wrote:
> Hi,
>
> actually we´re trying to get our *.ear built by Maven to be deployable und
> executable on SAP Web Application Server.
>
> We run into problems, caused by a classpath in (for example)
>
> javax.xml.soap
> saaj-api
> 1.3
>
> This jar has a MANIFEST.MF containing
>
> Class-Path: jaxp-api.jar jax-qname.jar activation.jar servlet.jar
>
> The application server is complaining about this classpath because Maven
> puts the *.jars with their version names into it,
> that means jaxp-api-1.4.jar (for example)
>
> => Is there a way to come around this? Do I have to customize all my
> module filenames?
>
> Torsten
>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven failing due to javac path issue -- Windows
And you can do javac -version? Per-Henrik On Tue, Sep 7, 2010 at 11:17 PM, Wayne Fay wrote: >>> I believe that the Java home path given by "mvn -version" on a Windows >>> platform points at the jre, not the jdk. Possibly someone on Windows could >> >> This is normal (also on Linux). I am also curious on "java -version" though > > This is from a Windows box... > C:\>java -version > java version "1.6.0_21" > Java(TM) SE Runtime Environment (build 1.6.0_21-b07) > Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing) > > On this box, the highest/latest JDK is 1.6.0_07, so this is definitely > reporting the JRE. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven failing due to javac path issue -- Windows
Enrique, I'm currious about the Java_home Java home: C:\IBM\ibm-java-sdk-60-win-i386\sdk\jre Does the jre have the javac -command? isn't that with the jdk-suite? Can you do "javac -version" from command line? cheers, Per-Henrik On Tue, Sep 7, 2010 at 7:35 PM, Enrique Gaona wrote: > Per-Henrik > The output from mvn -version, is showing Java Home pointing to > C:\IBM\ibm-java-sdk-60-win-i386\sdk\jre and the Java Home from echo is > pointing to C:\IBM\ibm-java-sdk-60-win-i386\sdk > > C:\RTC-data\workspace\>mvn -v > Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) > Java version: 1.6.0 > Java home: C:\IBM\ibm-java-sdk-60-win-i386\sdk\jre > Default locale: en_US, platform encoding: Cp1252 > > > C:\RTC-data\workspace>echo %JAVA_HOME% > C:\IBM\ibm-java-sdk-60-win-i386\sdk > > Thanks. > > Enrique > > > > [image: Inactive hide details for per-henrik hedman ---09/07/2010 11:59:13 > AM---what's the output from "mvn -version"? Could help deter]per-henrik > hedman ---09/07/2010 11:59:13 AM---what's the output from "mvn -version"? > Could help determine what the > > > *per-henrik hedman * > > 09/07/2010 11:58 AM > Please respond to > "Maven Users List" > > > To > > Maven Users List > cc > > > Subject > > Re: Maven failing due to javac path issue -- Windows > what's the output from "mvn -version"? Could help determine what the > actual value of JAVA_HOME according to mvn. > > What resides in the C:\IBM\ibm-java-sdk-60-win-i386\sdk\bin ? > > can you run javac -version? > > Per-Henrik > > On Tue, Sep 7, 2010 at 6:43 PM, Trevor Harmon wrote: > > On Sep 7, 2010, at 9:34 AM, Enrique Gaona wrote: > >> Can't say if it works with Oracle's JDK, since I've not tried it before. > >> > > Trying with Oracle's would help determine where the problem lies. > >> One workaround would be specify the maven-compiler-plugin in the parent > pom.xml, but I really don't want to do that. > >> > > > > Can't you just point JAVA_HOME and your PATH to the Oracle JDK? > > > > Trevor > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > >
Re: Maven failing due to javac path issue -- Windows
what's the output from "mvn -version"? Could help determine what the actual value of JAVA_HOME according to mvn. What resides in the C:\IBM\ibm-java-sdk-60-win-i386\sdk\bin ? can you run javac -version? Per-Henrik On Tue, Sep 7, 2010 at 6:43 PM, Trevor Harmon wrote: > On Sep 7, 2010, at 9:34 AM, Enrique Gaona wrote: >> Can't say if it works with Oracle's JDK, since I've not tried it before. >> > Trying with Oracle's would help determine where the problem lies. >> One workaround would be specify the maven-compiler-plugin in the parent >> pom.xml, but I really don't want to do that. >> > > Can't you just point JAVA_HOME and your PATH to the Oracle JDK? > > Trevor > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Am 15.04.2010 16:51, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 15:40, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare
a dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be
physically located in a parent directory, but is an artifact on its own),
that declares both plugins in the depMgmt section.
Could you please describe this more detailed? Which artifacts have to
have a common parent pom with depMgmt section?
Sorry, I mean in this case the pluginMgmt section.
Typically you define one parent POM for your complete project where you use
the depenencyManagement section to define the versions (and standard scopes)
of all your dependencies and a pluginManagement section with all plugins
used in this project again with versions and configuration shared everywhere
they are in use. This project POM is directly or indirectly inherited by all
your POMs within this project. Then you do not have to define anywhere a
version for a plugin (well, not for the plugins in the report sections, but
that's a different story) or dependency.
In the pluginManagement section you will also define any additional
dependency for the individual plugins (e.g. custom tasks for the antrun-
plugin or additional wagon providers) and also set the extension flag for
the plugins with custom extensions. Remember, each plugin can be loaded only
once and the first activation will also define its classpath.
- Jörg
Ok, I have tried several combinations of parent and child pom, but
nothing had an effect. I think, we have to use maven 2.2.1 for this
project.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Am 15.04.2010 15:40, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare a
dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be physically
located in a parent directory, but is an artifact on its own), that declares
both plugins in the depMgmt section.
Could you please describe this more detailed? Which artifacts have to
have a common parent pom with depMgmt section?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Am 15.04.2010 14:54, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Hi Maven users,
I'm having problems with two plugins, which both define a custom
packaging type. The packaging types are source-plugin and binary-plugin,
which are defined in a private maven plugin and warpath, which is
defined in the warpath plugin.
If I run the project with both plugins defined, only the first plugin
seems to be taken into account. E.g. if our private plugin is defined
above the warputh plugin, "source-plugin" and "binary-plugin" can be
resolved and "warpath" cannot be resolved. Same thing vice versa, if the
warputh plugin is defined above out plugin, "warpath" can be resolved,
"source-plugin" and "binary-plugin" not.
Plugins are defined this way:
com.company
maven-rcpbuild-plugin
1.0.3
true
org.appfuse
maven-warpath-plugin
2.0.2
true
add-classes
Running the project with our plugin and without the warpath plugin works
and vice versa.
If I run the same configuration with maven 2.2.1, it works as expected.
Also the plugin order is irrelevant.
Is this a limitation of maven 2.0.*, or a bug or am I doing something
wrong? I'm lost with this problem. Any hints are appreciated.
Let me know, if some relevant information is missing.
Please look into the POMs of the plugins and tell whether they declare a
dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Maven 2.0.10 with two plugins with custom packaging types
Hi Maven users, I'm having problems with two plugins, which both define a custom packaging type. The packaging types are source-plugin and binary-plugin, which are defined in a private maven plugin and warpath, which is defined in the warpath plugin. If I run the project with both plugins defined, only the first plugin seems to be taken into account. E.g. if our private plugin is defined above the warputh plugin, "source-plugin" and "binary-plugin" can be resolved and "warpath" cannot be resolved. Same thing vice versa, if the warputh plugin is defined above out plugin, "warpath" can be resolved, "source-plugin" and "binary-plugin" not. Plugins are defined this way: com.company maven-rcpbuild-plugin 1.0.3 true org.appfuse maven-warpath-plugin 2.0.2 true add-classes Running the project with our plugin and without the warpath plugin works and vice versa. If I run the same configuration with maven 2.2.1, it works as expected. Also the plugin order is irrelevant. Is this a limitation of maven 2.0.*, or a bug or am I doing something wrong? I'm lost with this problem. Any hints are appreciated. Let me know, if some relevant information is missing. Thanks in advance, Henrik - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Newbie-Problem: Wicket/Maven/Jetty: FileNotFoundException?
I am very new to the Java-World and want to make a web project using
Java/Maven2/Wicket.
I tried to install Wicket with these instructions:
http://cwiki.apache.org/WICKET/windows-guide-to-installing-wicket-on-eclipse-with-maven.html
Everything went fine up to the point of running a project. I tried
Wicket version 1.4 rc4 and 1.3.6.
Trying to reach localhost:8080 displays an 503-Error...
The console told me the following:
INFO - log- Logging to
org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via
org.mortbay.log.Slf4jLog
>>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
INFO - log- jetty-6.1.4
INFO - log- NO JSP Support for /, did not
find org.apache.jasper.servlet.JspServlet
WARN - log- Failed startup of context
org.mortbay.jetty.webapp.webappcont...@137c60d{/,src/main/webapp}
java.io.FileNotFoundException:
\\ROSSV01\ROSSV01\Users\mypersonalusername\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.jar
(Access denied)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:133)
[...]
ROSSV01 is the name of the networkserver where my userdata is stored.
I have no clue
why Maven(?) chose that directory... However the URL is false:
Right URL:
\\ROSSV01\Users\mypersonalusername\.m2\...
Wrong URL:
\\ROSSV01\ROSSV01\Users\mypersonalusername\.m2\...
So I'm pretty stuck here. Is it a Wicket error? Is it a Maven error?
Jetty error? Where could I change the URL using eclipse?
Right now I am pretty confused here...
Would be great if somebody can help me out...
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Exclude dependency from scope runtime test classpath
The jar file in question is a 3:de part jar that we can't and should not change. The application depends on the jar for a certain specific operation, but not for the building and testing of the module itself. Don't ask me why, not my idea :) We use the jar only to Acceptance test the application. The problem is that the jar (dependency) is loaded in a separate classloader when you are running the application and are using the specific operation. I use runtime scope for now and see if I can solve it some other way later. Thanks for all help. Keep up the good work on Maven. Henrik Cummings,Steven skrev: Can the tests be in a separate jar? If so they could include the original jar with the code to test but exclude dependencies as needed. Steven -Original Message----- From: Henrik [mailto:hen...@team11.org] Sent: Thursday, May 07, 2009 6:04 AM To: users@maven.apache.org Subject: Exclude dependency from scope runtime test classpath Hi, I was wondering if there is a way to remove a dependency from the test classpath when using runtime I want to make sure that the jar file is only used when running the application and not when testing it. So it really comes down to, I want to have the dependency (jar file) but i don't want to add it to compile or test classpath. Thanks, Henrik - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Exclude dependency from scope runtime test classpath
Hi, I was wondering if there is a way to remove a dependency from the test classpath when using runtime I want to make sure that the jar file is only used when running the application and not when testing it. So it really comes down to, I want to have the dependency (jar file) but i don't want to add it to compile or test classpath. Thanks, Henrik - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Trouble with "ejbs" folder and maven1 proxy
OK, thanks. nicolas de loof skrev: I've created MRM-659 for this issue, so that we don't forget it and create ejb dedicated testcase. 2008/1/18, Henrik Brautaset Aronsen <[EMAIL PROTECTED]>: nicolas de loof skrev: Rename the "type" folder in your repository to the "jars" expected by archiva or build/install the ejb on the same computer that requires it Mixing jars and ejbs in the same folder is not an option for us, I'm afraid. We are in a large project with hundreds of artifacts. I guess I'll stick to maven-proxy for our maven1 repo until this is solved. Is http://jira.codehaus.org/browse/MRM-268 the issue that is tracking this problem? Henrik
Re: Trouble with "ejbs" folder and maven1 proxy
nicolas de loof skrev: Rename the "type" folder in your repository to the "jars" expected by archiva or build/install the ejb on the same computer that requires it Mixing jars and ejbs in the same folder is not an option for us, I'm afraid. We are in a large project with hundreds of artifacts. I guess I'll stick to maven-proxy for our maven1 repo until this is solved. Is http://jira.codehaus.org/browse/MRM-268 the issue that is tracking this problem? Henrik
Re: Trouble with "ejbs" folder and maven1 proxy
OK, thanks for the swift answer. Is there a workaround available? Henrik nicolas de loof skrev: This issue has been reported recently. It requires a fix in archiva code to enhance the "type" folder used by maven1. The current code use the file extension to select the folder, with few exceptions, but "ejb" type is not correctly supported. Nico. 2008/1/18, Henrik Brautaset Aronsen <[EMAIL PROTECTED]>: I recently tried switching from maven-proxy to archiva. I have installed archiva in http://myhost:9876/archiva/ and my maven1 repo is accessible from http://myhost:9876/archiva/repository/my-maven1/ Everything seems to work OK, except for one weird thing: If I try accessing e.g. ... http://myhost:9876/archiva/repository/my-maven1/myproject/ejbs/accounting-ejb-0.2.jar .. I receive a 404 Not Found with a link to ... http://myhost:9876/repository/myproject/jars/accounting-ejb-0.2.jar This only happens when accessing something in the "ejbs" folder. E.g. http://myhost:9876/archiva/repository/my-maven1/myproject/jars/backend-dao-0.11.jar works fine. The file permissions are the same all over the repo. If I switch back to use maven-proxy, access to files in the ejbs folder works again. Henrik mvh, Henrik -- Utvikler, Nordic Lottery Systems AS +47 908 89 864
Continuum freezes after checkout
Hi. We have a maven2 project, with several sub projects. I installed Continuum 1.1 on a Debian Etch machine (cvs v1.12.13, mvn v2.0.8, java v1.5.0_10). I added the Maven our projects using "Add Maven 2.x project" with a file:/// URL. All the projects are listed as they should. As Continuum starts working on the root project, it just hangs at the checkout (with the checkout icon next to the project). I cannot build another project, and I cannot cancel the build. INFO | jvm 1| 2008/01/03 10:19:40 | 2008-01-03 10:19:40,667 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action checkout-project INFO | jvm 1| 2008/01/03 10:19:40 | 2008-01-03 10:19:40,686 [pool-1-thread-1] INFO org.apache.maven.continuum.scm.ContinuumScm:default - Checking out project: 'Entire Project source', id: '31' to '/usr/local/continuum-1.1/apps/continuum/webapp/WEB-INF/working-directory/31'. INFO | jvm 1| 2008/01/03 10:19:40 | 2008-01-03 10:19:40,712 [pool-1-thread-1] INFO org.apache.maven.scm.manager.ScmManager:default - Executing: /bin/sh -c "cd /usr/local/continuum-1.1/apps/continuum/webapp/WEB-INF/working-directory && cvs -z3 -f -d :ext:[EMAIL PROTECTED]:/home/project/cvs -q checkout -d 31 project" INFO | jvm 1| 2008/01/03 10:19:40 | 2008-01-03 10:19:40,712 [pool-1-thread-1] INFO org.apache.maven.scm.manager.ScmManager:default - Working directory: /usr/local/continuum-1.1/apps/continuum/webapp/WEB-INF/working-directory INFO | jvm 1| 2008/01/03 10:19:41 | #65188 warning C/S protocol error (section 5.10). It's regurarly observed with cvs 1.12.xx servers. INFO | jvm 1| 2008/01/03 10:19:41 | unexpected pathname=project/ missing root prefix=/home/project/cvs INFO | jvm 1| 2008/01/03 10:19:41 | relaxing, but who knows all consequences [...] INFO | jvm 1| 2008/01/03 11:00:00 | 2008-01-03 11:00:00,016 [defaultScheduler_Worker-12] INFO org.apache.maven.continuum.build.settings.SchedulesActivator:default - >>>>>>>>>>>>>>>>>>>>> Executing build job (Every five minutes)... INFO | jvm 1| 2008/01/03 11:00:00 | 2008-01-03 11:00:00,139 [defaultScheduler_Worker-12] INFO org.apache.maven.continuum.Continuum:default - Project 'Entire Project Source' already being built. The files are actually checked out into the .../working-directory/31 folder. If I try issuing the cvs checkout command above manually, it checks out just fine, without any errors. This behaviour is identical on another linux box. On my Macbook, however, continuum builds all projects as it should (cvs v1.12.13, mvn v2.0.7, java v1.5.0_13). I added this as an issue as well: http://jira.codehaus.org/browse/CONTINUUM-1615 Best regards, Henrik
Re: Support for CM Synergy?
Great! Thanks alot. /Henrik Emmanuel Venisse <[EMAIL PROTECTED]> 2007-04-02 14:27 Please respond to continuum-users@maven.apache.org To continuum-users@maven.apache.org cc Subject Re: Support for CM Synergy? Continuum support it too. We'll include it in the distrib in few days. Emmanuel [EMAIL PROTECTED] a écrit : > Hi, > > I read on the SCM website that the SCM Plugin now has support for CM > Synergy. But Continuum does not seem to support CM Synergy yet. > > Are there any plans for this? > > /Henrik > ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Please note that in order to protect the security of our information systems an AntiSPAM solution is in use and will browse through incoming emails. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Veuillez prendre note qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la sécurité de nos systems d'information et qu'elle furètera les courriels entrant. Merci. _
Support for CM Synergy?
Hi, I read on the SCM website that the SCM Plugin now has support for CM Synergy. But Continuum does not seem to support CM Synergy yet. Are there any plans for this? /Henrik ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Please note that in order to protect the security of our information systems an AntiSPAM solution is in use and will browse through incoming emails. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Veuillez prendre note qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la sécurité de nos systems d'information et qu'elle furètera les courriels entrant. Merci. _
Get offline status from within a mojo?
Hi, Is it possible to detect wheter Maven is working offline (with -o option) from within a Mojo? Regards, Henrik
Re: Profiles for sub-projects
Why not use:
However, this bit is not working:
${basedir}\plugin.xml
/Henrik
On 6/12/06, Boden, David <[EMAIL PROTECTED]> wrote:
I've managed to track this down. The profiles work correctly.
However, this bit is not working:
plugin.xml
It is not looking for plugin.xml at ${basedir}/plugin.xml for each
sub-project as I'd expect. Instead, for each subproject it's just
evaluating the same multi-project-base/plugin.xml. I'm going to come up
with a simple scenario and raise a Jira.
Regards,
Dave
-Original Message-
From: Boden, David
Sent: Monday, June 12, 2006 11:26 AM
To: 'users@maven.apache.org'
Subject: Profiles for sub-projects
As part of a multi-project build, I have defined a in my
*parent* pom. I would like this profile to be switched on for some of
the sub-projects (my GUI components), and off for other subprojects (my
shared and server components).
In the example I've given, I want the profile to be activated on a
per-sub-project basis when the file "plugin.xml" is located in the root
directory of the sub-project.
At the moment, Maven decides *once* for the multi-project whether to
activate the profile depending on whether a plugin.xml file is present
in the *aggregator* pom's root directory (multi-project pom). Is this
behaviour a bug? If so, I'll raise a Jira. Is there some other way that
I can get around this other than copying the plugin configurations to
every single one of my sub-projects?
Many thanks,
Dave
Configuration in the *parent* pom:
guibundle
plugin.xml
maven-assembly-plugin
package
single
META-INF/MANIFEST.MF
../SSBuild/bundle-assembly.xml
--
This message is intended only for the personal and confidential use of the
designated recipient(s) named above. If you are not the intended recipient
of this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited. This
communication is for information purposes only and should not be regarded as
an offer to sell or as a solicitation of an offer to buy any financial
product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be
secure or error-free. Therefore, we do not represent that this information
is complete or accurate and it should not be relied upon as such. All
information is subject to change without notice.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Fatal bug in dependency mediation (2.0.4)?
Hi, This might need to be put in JIRA, but I need to hear if others have had the same problem first. When building an EAR-file, I get two different versions of dom4j depending on the version number of my server-ejb!!! If I use eg. 1.7.1, I get one version of dom4j (1.6) - setting the version number of my multi project to 1.7.1-SNAPSHOT, I get version 1.4 of dom4j on the EXACT same code and poms!!! When I output debug info (-X), I can see that the order of which dependencies are traversed is different for the two builds - giving rise to another version being selected. This is a totally unacceptable behavior as it makes it impossible to make reproducible builds Any opinions? Henrik
maven-changes-plugin ????
From the plugins documentation, the configuration of the maven-changes-plugin should be: <...> org.apache.maven.plugins maven-changes-plugin <...> This is not found in (deployed to ) any respository. Could anyone please update the documentation with the right configuration? Regards, Henrik
Re: Hammurapi plugin?
I'm planning to create a Hammurapi-plugin. Let's see what the future brings. /Henrik On 5/30/06, Wayne Fay <[EMAIL PROTECTED]> wrote: Never seen/heard of any such plugin for M2, but if you get inspired, please contribute it back for the benefit of others! Wayne On 5/30/06, Henrik Mejlgaard <[EMAIL PROTECTED]> wrote: > Does anyone have a Hammurapi plugin for Maven 2? > > Regards, > > Henrik > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hammurapi plugin?
Does anyone have a Hammurapi plugin for Maven 2? Regards, Henrik
Re: Re: m2: How do I expand the clean-goal?
Syntax is something like this (from top of my head):
org.apache.maven.plugins
maven-clean-plugin
${basedir}/src/main/java
**/generated/**
**/generated
/Henrik
On 5/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Good Idea, but how?
I found only three parameters in the plugin-documentation, each can handle
only a single directory and are read only!
mvn clean
...
[INFO] Error configuring: org.apache.maven.plugins:maven-clean-plugin.
Reason: E
RROR: Cannot override read-only parameter: directory in goal: clean:clean
...
But I need somethink like the folloing Ant-Task-Part:
Can you tell me the configure-syntax, to do that?
thanks
Rainer
"Henrik Mejlgaard" <[EMAIL PROTECTED]> schrieb am 09.05.2006 16:39:18:
> Use the maven-clean-plugin and configure it to delete the generated
source
> folders you want.
> /Henrik
> On 5/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > we have bound a source-generator on the generate-sources-phase with
the
> > maven-antrun-plugin.
> > I wan't to clean the generated sources with the clean-goal, but clean
is
> > not a Build-Lifeycle-Phase, so I can not do it at the same way.
> > In Maven 1 I had the pre-goal. How do I resolve my problem in maven 2
(I
> > have an Ant-Srcipt ready)?
> >
> > Thanks
> > Rainer
> >
> >
> > -
> > 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: How do I expand the clean-goal?
Use the maven-clean-plugin and configure it to delete the generated source folders you want. /Henrik On 5/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi, we have bound a source-generator on the generate-sources-phase with the maven-antrun-plugin. I wan't to clean the generated sources with the clean-goal, but clean is not a Build-Lifeycle-Phase, so I can not do it at the same way. In Maven 1 I had the pre-goal. How do I resolve my problem in maven 2 (I have an Ant-Srcipt ready)? Thanks Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependencies in parent pom's
Hello, I'm using maven2 ant tasks and trying to figure out why it does not fetch the dependencies I think it should fetch... in this example I'm trying to fetch spring 1.2.6 with it. Here's what I have in my build.xml: http://www.ibiblio.org/maven2"/> It fetches spring-1.2.6.jar and commons-logging-1.0.4 - that's it. But from studying the spring-1.2.6 pom, it includes spring-full and spring-parent pom's and the spring-full pom specifies several more artifacts that are not declared optional.. such as aopalliance and oro. Why are these not downloaded? I can't find any explanation why... as far as I have understood the what's in the xml schema, I think it should download those too.. For reference: http://www.ibiblio.org/maven2/org/springframework/spring/1.2.6/spring-1.2.6.pom http://www.ibiblio.org/maven2/org/springframework/spring-full/1.2.6/spring-full-1.2.6.pom http://www.ibiblio.org/maven2/org/springframework/spring-parent/1.2.6/spring-parent-1.2.6.pom Hope someone can help shed some light on this. Thanks. Henrik Gram - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to use the local scm provider with Continuum?
Now it works better, thanks for the info. However, now I get "java.lang.OutOfMemoryError: Java heap space" when I run my bat file. How can I increase the java memory limit for the build? /Henrik Emmanuel Venisse <[EMAIL PROTECTED]> 2006-03-24 10:56 Please respond to continuum-users@maven.apache.org To continuum-users@maven.apache.org cc Subject Re: Is it possible to use the local scm provider with Continuum? ok, your scm url is wrong. buildEBITool.cmd must not be in scm url Your scm url must be scm:local|D:/|EBITool (not sure you need "/" after "D:") buildEBITool.cmd must be add to a build definition (in edit project page) of your project when it will be add to continuum Emmanuel [EMAIL PROTECTED] a écrit : > Ok, maybe I have missed something. I'm a newbie on both Maven and > Continuum. I have decided to start with Continuum and then move my project > into Maven as well. I will also try to add support for CM Synergy in SCM. > So I have plenty of things to do. > > I have a bat file called buildEBITool.cmd in the directory d:\EBITool. I > have tried to use the following SCM url: > scm:local|D:/EBITool|buildEBITool.cmd > > (and a couple of variations on that. But I get "You must provide an scm > url" error when I click on the Submit button. > > /Henrik > > > > > > > > > Emmanuel Venisse <[EMAIL PROTECTED]> > 2006-03-23 17:24 > > Please respond to > continuum-users@maven.apache.org > > > To > continuum-users@maven.apache.org > cc > > Subject > Re: Is it possible to use the local scm provider with Continuum? > > > > > > > Yes, it works fine for me. > What is your problem? > > Emmanuel > > [EMAIL PROTECTED] a écrit : > >>Hi! >> >>Is it possible to use the local scm provider with Continuum? >>I have tried to add a local scm url to the Add Projects (Shell script) >>dialog. But it wont accept the url. >>I'm using Windows by the way. >> >>/Henrik >> >> > > ___ > >>This e-mail communication (and any attachment/s) may contain > > confidential > >>or privileged information and is intended only for the individual(s) or >>entity named above and to others who have been specifically authorized > > to > >>receive it. If you are not the intended recipient, please do not read, >>copy, use or disclose the contents of this communication to others. > > Please > >>notify the sender that you have received this e-mail in error by reply >>e-mail, and delete the e-mail subsequently. >>Thank you. >> > > _ > >> >>Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut >>contenir des renseignements confidentiels ou protégés et est destiné à >>l?usage exclusif du destinataire ci-dessus. Toute autre personne est par >>les présentes avisée qu?il est strictement interdit de le diffuser, le >>distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, >>veuillez nous en aviser et détruire ce message. >>Merci. >> > > _ > >> >> > > > > > > ___ > > This e-mail communication (and any attachment/s) may contain confidential > or privileged information and is intended only for the individual(s) or > entity named above and to others who have been specifically authorized to > receive it. If you are not the intended recipient, please do not read, > copy, use or disclose the contents of this communication to others. Please > notify the sender that you have received this e-mail in error by reply > e-mail, and delete the e-mail subsequently. > Thank you. > _ > > > Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut > contenir des renseignements confidentiels ou protégés et est destiné à > l?usage exclusif du destinataire ci-dessus. Toute autre personne est par > les présentes avisée qu?il est strictement interdit de le diffuser, le > distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, > veuillez nous en aviser et détruire ce message. > Merci. >
Is it possible to use the local scm provider with Continuum?
Hi! Is it possible to use the local scm provider with Continuum? I have tried to add a local scm url to the Add Projects (Shell script) dialog. But it wont accept the url. I'm using Windows by the way. /Henrik ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _
APT format
The APT guide states: *A short APT document is contained in a single text file. A longer document may be contained in a ordered list of text files. For instance, first text file contains section 1, second text file contains section 2, and so on.* *Note: * *Splitting the APT document in several text files on a section boundary is not mandatory. The split may occur anywhere. However doing so is recommended because a text file containing a section is by itself a valid APT document.* ** My question is: How do I split up an APT document in several files. I don't see the syntax for importing them into the containing document anywhere. TIA, Henrik
Re: Handling Eclipse plugin development in Maven?
This looks very interesting. Thanks! Is the M2 headless eclipse plugin also available in some source repository? /Henrik Sachin Patel <[EMAIL PROTECTED]> 2006-03-22 16:02 Please respond to "Maven Users List" To "Maven Users List" cc Subject Re: Handling Eclipse plugin development in Maven? I've have built a custom solution for the Geronimo eclipse plugin using M1 and almost done with migrating it over to M2. I wouldn't say the project structure is necessarily the issue. The issue is encapsulating the function of the PDE builder in a reusable way. The other issue is handling eclipse dependencies. I currently have a plugin that essentaially allows you to compile against a given distribution of eclipse or a set of eclipse projects mimicking the concept of the "target workbench" in eclipse. This I'm sure you could reuse/enhance. Then the only thing left is to create reusable plugins that create the distributions. If you want to take a look at what I currently have for M2 take a look at.. https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/trunk/ I also have a M2 plugin that allows you to run any headless eclipse application, for example in the Geronimo case, using the EMF headless applications to generate EMF models. - sachin On Mar 22, 2006, at 6:41 AM, [EMAIL PROTECTED] wrote: > Hi, > > Does anyone have any tips or best practices for handling Eclipse > plugin > development in maven? > > We are developing an product in Eclipse consiting of multiple > plugins and > features. The maven directory structure is not the same as the > struture > created by Eclipse PDE. I know maven's structure can be changed, but I > don't know if that is the "right" solution. > > Regards > > Henrik > > __ > _ > > This e-mail communication (and any attachment/s) may contain > confidential > or privileged information and is intended only for the individual > (s) or > entity named above and to others who have been specifically > authorized to > receive it. If you are not the intended recipient, please do not read, > copy, use or disclose the contents of this communication to others. > Please > notify the sender that you have received this e-mail in error by reply > e-mail, and delete the e-mail subsequently. > Thank you. > __ > ___ > > > Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut > contenir des renseignements confidentiels ou protégés et est destiné à > l?usage exclusif du destinataire ci-dessus. Toute autre personne > est par > les présentes avisée qu?il est strictement interdit de le diffuser, le > distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, > veuillez nous en aviser et détruire ce message. > Merci. > __ > ___ > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _
Handling Eclipse plugin development in Maven?
Hi, Does anyone have any tips or best practices for handling Eclipse plugin development in maven? We are developing an product in Eclipse consiting of multiple plugins and features. The maven directory structure is not the same as the struture created by Eclipse PDE. I know maven's structure can be changed, but I don't know if that is the "right" solution. Regards Henrik ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _
POM clean-up tool?
I was wondering if anyone knows of a Maven2 plugin that is able to check whether the dependencies specified in the pom.xml is actually used during compilation. I would be nice if such a plugin could give the following kind of info: [WARN] Dependency X:Y:Z is never used It's our experience that POMs gets polluted with stale dependencies as time goes by. TIA, Henrik
Re: import statements in Eclipse and maven2
Does anyone know of ETA for a new release of the embedder? In particular, I'm interested in the multi-modules build functionality. /Henrik On 2/28/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote: > > Yes, it's not the plugin, it's the embedder. And yes, it's very annoying, > but I tend to use external tools to build rather than the embedded > version. > I use the plugin to make Eclipse compile my code correctly based on > artifacts I have already downloaded. > > It would be nice if the embedder could be fixed, though. Really nice. > > -K > > > On 2/28/06 10:58 AM, "Yann Le Du" <[EMAIL PROTECTED]> wrote: > > > The problem is in Maven embedder : > > http://jira.codehaus.org/browse/MNG-1070 > > > > 2006/2/28, KC Baltz <[EMAIL PROTECTED]>: > >> > >> Don't you need to install the M2 Eclipse plugin to get this to > >> work? That's here: http://maven.apache.org/eclipse-plugin.html > >> > >> Note: the last I checked, the M2 Eclipse plugin still had a major bug > >> whereby it ignores your settings.xml file. > >> > >> K.C. > >> > >> -Original Message- > >> From: Kathryn Huxtable [mailto:[EMAIL PROTECTED] > >> Sent: Monday, February 27, 2006 9:06 PM > >> To: Maven Users List > >> Subject: Re: import statements in Eclipse and maven2 > >> > >> > >> That's a link to one approach. Another approach is to enable the Maven2 > >> nature for your project, which should make it use the dependencies in > your > >> pom.xml file without needing to regenerate the .classpath file every > time > >> you add a dependency. > >> > >> -K > >> > >> -- > >> Kathryn Huxtable > >> Middleware Architect > >> Core Middleware > >> Information Technology, a division of Information Services > >> The University of Kansas > >> > >> > >> On 2/27/06 6:41 PM, "KC Baltz" <[EMAIL PROTECTED]> wrote: > >> > >>> http://maven.apache.org/guides/mini/guide-ide-eclipse.html > >>> > >>> > >>> > >>> -Original Message- > >>> From: Ashish Srivastava [mailto:[EMAIL PROTECTED] > >>> Sent: Monday, February 27, 2006 4:24 PM > >>> To: users@maven.apache.org > >>> Subject: import statements in Eclipse and maven2 > >>> > >>> > >>> Hi, > >>> I am using maven2 plugin on Eclipse and working on a > >>> project which uses maven2. In the eclipse' Java editor > >>> all the import statements (and the classes) are > >>> underlined red as if it could not find the jars. How > >>> can I configure the project to read the pom.xml and > >>> work out all the dependencies? > >>> > >>> -Ashish > >>> > >>> __ > >>> Do You Yahoo!? > >>> Tired of spam? Yahoo! Mail has the best spam protection around > >>> http://mail.yahoo.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] > >>> > >> > >> > >> - > >> 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] > >> > >> > > -- > Kathryn Huxtable > Middleware Architect > Core Middleware > Information Technology, a division of Information Services > The University of Kansas > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Specifying -Xmx in surefire plugin?
OK, I found the answer myself. The trick is to use the argline-tag. I now specify: org.apache.maven.plugins maven-surefire-plugin -Xmx512m pertest true true /Henrik On 2/19/06, Henrik Mejlgaard <[EMAIL PROTECTED]> wrote: > > How do I specify a -Xmx property in the surefire plugin? > I know of the system properties tag, but don't know the exact syntax for > properties like this. > > TIA, > > Henrik >
Specifying -Xmx in surefire plugin?
How do I specify a -Xmx property in the surefire plugin? I know of the system properties tag, but don't know the exact syntax for properties like this. TIA, Henrik
Re: [m2]Guide to Developing Ant Plugins error
Hi Alexandre, I had the same problem. It seems there is a problem in the transitive dependencies somewhere. My very ugly hack to get past this error was to copy the 2.0.1 versions into the 2.0 versions of maven-plugin-tools-api in my local repository - renaming the version of the file of course. I then created new sha1's for the files as well. Ugly, ugly, ugly :( The path is \.m2\repository\org\apache\maven\maven-plugin-tools-api /Henrik On 1/20/06, Alexandre Russel <[EMAIL PROTECTED]> wrote: > Hi, > I am following the Guide to Developing Ant Plugins, first example hello > world plugin: > here is the error and at the end of the mail the exact file I > used(cut/paste from the guide): > > > mvn install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Hello Plugin > [INFO]task-segment: [install] > [INFO] > > [WARNING] >Artifact org.apache.maven:maven-plugin-descriptor:jar:2.0-beta-3 > retains local scope 'runtime' overriding broader scope 'compile' >given by a dependency. If this is not intended, modify or remove > the local scope. > > [WARNING] >Artifact > org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-7 retains > local scope 'runtime' overriding broader scope 'compile' >given by a dependency. If this is not intended, modify or remove > the local scope. > > [WARNING] >Artifact org.apache.maven:maven-plugin-tools-api:jar:2.0-beta-3 > retains local scope 'runtime' overriding broader scope 'compile' >given by a dependency. If this is not intended, modify or remove > the local scope. > > [INFO] [plugin:descriptor] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] > org.apache.maven.tools.plugin.extractor.AbstractScriptedMojoDescriptorExtractor.extractMojoDescriptors(Ljava/util/Map;Lorg/apache/maven/plugin/descriptor/PluginDescriptor;)Ljava/util/List; > [INFO] > > [INFO] Trace > java.lang.AbstractMethodError: > org.apache.maven.tools.plugin.extractor.AbstractScriptedMojoDescriptorExtractor.extractMojoDescriptors(Ljava/util/Map;Lorg/apache/maven/plugin/descriptor/PluginDescriptor;)Ljava/util/List; >at > org.apache.maven.tools.plugin.extractor.AbstractScriptedMojoDescriptorExtractor.execute(AbstractScriptedMojoDescriptorExtractor.java:34) >at > org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) >at > org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:95) >at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:585) >at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 3 seconds > [I
[m2] Ant driven plugins and classpath refid's
Hi, >From the documentation in http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html, I have successfully created the Hello World Ant based plugin. My problem is now to implement a more advanced ant-based mojo. Specifically, I have troubles finding out how to get a ant classpath refid to be used in a taskdef in the *.build.xml. My taskdef looks as follows: .. How do I inject the plugin.dependency.classpath from the *.mojos.xml? Regards, Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Ant driven plugins and classpath refid's
Thank you for your answers, but they doesn't help me a lot. I am not using the antrun plugin, but using the strategy documented in http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html where it is outlined how you through a mapping file and a build.xml file is able to wrap ant functionality in an 'automatically' generated mojo. The whole idea is to wrap our ant functionality in a plugin which can be used from a variety of projects with an ease. If I was to use the antrun plugin, I would have my ant functionality copied around multiple poms. So...I still need to get a classpath refid from the mappings file to the build.xml Any other ideas? /Henrik On 1/17/06, Scokart Gilles <[EMAIL PROTECTED]> wrote: > If you launch a separated ant script ( using the "ant" task into the pom), > you should not forget the inheritRef attributes. Otherwise, you don't have > the reference into your xxx-build.xml. > > Regards, > Gilles > > > -Original Message- > > From: Chris Berry [mailto:[EMAIL PROTECTED] > > Sent: 17 January 2006 15:14 > > To: Maven Users List > > Subject: Re: [m2] Ant driven plugins and classpath refid's > > > > Did you follow this doc; > > http://maven.apache.org/plugins/maven-antrun-plugin/classpaths.html > > Cheers, > > -- Chris > > > > On 1/17/06, Henrik Mejlgaard <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > From the documentation in > > > http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html, > > > I have successfully created the Hello World Ant based plugin. > > > > > > My problem is now to implement a more advanced ant-based mojo. > > > Specifically, I have troubles finding out how to get a ant classpath > > > refid to be used in a taskdef in the *.build.xml. > > > My taskdef looks as follows: > > > > > > > > > > > > > classname="xdoclet.modules.ejb.EjbDocletTask"> > > > > > > > > > > > > > > > .. > > > > > > > > > How do I inject the plugin.dependency.classpath from the *.mojos.xml? > > > > > > Regards, > > > > > > Henrik > > > > > > - > > > 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]
[m2] Ant driven plugins and classpath refid's
Hi, >From the documentation in http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html, I have successfully created the Hello World Ant based plugin. My problem is now to implement a more advanced ant-based mojo. Specifically, I have troubles finding out how to get a ant classpath refid to be used in a taskdef in the *.build.xml. My taskdef looks as follows: .. How do I inject the plugin.dependency.classpath from the *.mojos.xml? Regards, Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
including multiproject in a multiproject
Hi all In order to keep a nice structure of my project i would like to include a multiproject in a multiproject. Often you have a util, ejb and web subproject. What if the web project is a multiproject contaning 2 or more other webapplications. But I cant seem to get multiproject:install or multiproject:site to work for included multiprojects. I would like to do something like: maven.multiproject.type=multiproject Is that possible? /Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
