AW: maven archetype
Thx you, or is there a possibility by using this command to integrate source/projects report information? Mvn archetype:create -DarchetpeGroupId=org.apache.maven.archetypes \ -DarchetypeArtifactId=maven-archetype-site \ -DgroupId=com.mycompany \ -DartifactId=my-site It creates a dedicated site project where I can customize the layout and the html output stuff. How can I integrate my java sources and reports (e.g. from checkstyle, pmd, xref...) to this site? Regards, Matthias -Ursprüngliche Nachricht- Von: Thor [mailto:[EMAIL PROTECTED] Gesendet: Montag, 29. September 2008 03:46 An: Maven Users List; [EMAIL PROTECTED] Betreff: Re: maven archetype The only thing I can come up with it's to add each file as a resource on the archetpe.xml of your archetype (wich is a real pain). Or you could try the mvn archetype:create-from-project, it'll generate an archetype from your current project (though, I haven't used it for that kind configuration) hope it helps... My regards... On Sun, Sep 28, 2008 at 2:07 PM, Matthias Dorfner [EMAIL PROTECTED]wrote: Sorry for that maybe stupid question, but I didn't find an answer consulting the maven website and google. I created an archetype quickstart skeleton, as well as a dedicated site skeleton with the archetype plugin (with the goals create and generate). What I'm looking for is a skeleton that combines both. So I can put my already existing java files in the src/java folder, configure my site templates, apt, faq files etc. within the src/site folder and use the site plugin to generate a customized project page with javadoc, project reports information… for my source code. How can I set this up easily? Thanks in advance! Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven schemaspy plugin with MSSql
Hi all, Has anyone used before maven schemaspy plugin to generate DB schema site from MSSql? I'm trying to configure schemaspy plugin as described in http://maven.wakaleo.com/mojo/maven-schemaspy-plugin/usage.html http://maven.wakaleo.com/mojo/maven-schemaspy-plugin/usage.html as folows reporting plugins plugin groupIdcom.wakaleo.schemaspy/groupId artifactIdmaven-schemaspy-plugin/artifactId version1.0/version configuration databaseTypemssql/databaseType database[DbName]/database host[Host]/host user[Login]/user password[Password]/password /configuration plugin . plugins /reporting But during build of my site I'm getting this error Parameter '-port' (database port on host) missing. It is required for the specified database type. Why maven schemaspy plugin didn't trying to connect to MSSql with defaul port? Or how can I pass port to maven schemaspy plugin? Plz help, Thanks -- View this message in context: http://www.nabble.com/Maven-schemaspy-plugin-with-MSSql-tp19719190p19719190.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
repository for youtube api
Hi, I need to use youtube api in my 'mavenized' app, is there a youtube dependency somewhere? thanks. A.C. -- View this message in context: http://www.nabble.com/repository-for-youtube-api-tp19719346p19719346.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reactor plugin Embedded error: Roots differ
Hi, I'm trying to get the reactor plugin to work for our project structure (simplified version): project-root/ /modules pom.xml /A /api /impl /B /api /impl /root-pom/pom.xml The root-pom/pom.xml contains a modules section that just references the project modules modules module../modules/module /modules Now, from the root-pom directory I do mvn reactor-make -Dmake.artifacts=A-api which should normally trigger B-api,A-api to be built. Instead i get [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Problem generating dependency tree Embedded error: Roots differ [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Problem generating dependency tree at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:701) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:551) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:521) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:369) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:302) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Problem generating dependency tree at org.apache.maven.plugin.reactor.MakeMojo.execute(MakeMojo.java:168) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:676) ... 16 more Caused by: org.apache.maven.plugin.reactor.RelativePather$DifferentRootsException: Roots differ at org.apache.maven.plugin.reactor.RelativePather.getRelativePath(RelativePather.java:41) at org.apache.maven.plugin.reactor.MakeMojo.execute(MakeMojo.java:159) ... 18 more [INFO] Any ideas ? Jorg
Multi module Setup / release:prepare
Hi there, i have a little problem with the release:prepare running in Maven. I have a mutli module setup which seemed to be ok parent +--- Module A (depends on C) (result in tar.gz) +--- Module B +--- Module C +--- Module WAR +--- Module D (Tomcat with .war from Module WAR as a .tar.gz) +--- Module E (only multiple tar.gz with config files; no java code) +--- Module project (which comprise of the above as .tar.gz) after running mvn release:prepare i allway get an Failed to resolve artifact. message... What i have observed is, if i delete the contents of my local repository and try to do an mvn package this will fail the first time If i do a mvn install before everything is fine I'm not sure but it seemed to me there is something wrong in my dependencies...but i'm not sure where to search for Does some has a hint ? Thanks in advance.. Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi module Setup / release:prepare
Hi Karl Heinz! On 29 Sep 2008, Karl Heinz Marbaise wrote: i have a little problem with the release:prepare running in Maven. I have a mutli module setup which seemed to be ok parent +--- Module A (depends on C) (result in tar.gz) +--- Module B +--- Module C +--- Module WAR +--- Module D (Tomcat with .war from Module WAR as a .tar.gz) +--- Module E (only multiple tar.gz with config files; no java code) +--- Module project (which comprise of the above as .tar.gz) after running mvn release:prepare i allway get an Failed to resolve artifact. message... In which module do you get the error message? What i have observed is, if i delete the contents of my local repository and try to do an mvn package this will fail the first time If i do a mvn install before everything is fine We are having the same problem here with EARs and skinny WARs. It's been a while since I last looked what the problem is but our problem is definitely related to the skinny WAR problem [0] and your's might be too. The workaround we are using is to run mvn install whenever such a problem occurs. I'm not sure but it seemed to me there is something wrong in my dependencies...but i'm not sure where to search for Try running mvn -X to see where your dependencies come from. Search the output for selected for runtime and from the repository. This might lead you on the right track. hth, - martin [0] http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem signature.asc Description: PGP signature
Cobertura plugin doesn't generate XML
Hi I'm trying to generate an XML report using the Cobertura plugin (2.2 apparently). I configured the plugin according to the documentation: plugin groupIdorg.apache.maven.plugins/groupId artifactIdcobertura-maven-plugin/artifactId configuration formats formatxml/format /formats /configuration /plugin Then I start Maven (mvn clean install cobertura:cobertura), but the plugin generates the HTML reports under .../target/site/cobertura/ (which I tell it not to do), but doesn't create any XML files. What am I doing wrong? Best regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cobertura plugin doesn't generate XML
I can think of two things, that could go wrong: 1. Did you configure this under the reporting section or under the build section of your pom file? It should be under the build section afaik. 2. Otherwise, what version of the cobertura plugin are you using? Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Sep 29, 2008 at 12:04 PM, Lewis, Eric [EMAIL PROTECTED] wrote: Hi I'm trying to generate an XML report using the Cobertura plugin (2.2 apparently). I configured the plugin according to the documentation: plugin groupIdorg.apache.maven.plugins/groupId artifactIdcobertura-maven-plugin/artifactId configuration formats formatxml/format /formats /configuration /plugin Then I start Maven (mvn clean install cobertura:cobertura), but the plugin generates the HTML reports under .../target/site/cobertura/ (which I tell it not to do), but doesn't create any XML files. What am I doing wrong? Best regards, Eric - 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: Cobertura plugin doesn't generate XML
Hello, may you can try the configuration in your reporting section of the POM. - jens Hi I'm trying to generate an XML report using the Cobertura plugin (2.2 apparently). I configured the plugin according to the documentation: plugin groupIdorg.apache.maven.plugins/groupId artifactIdcobertura-maven-plugin/artifactId configuration formats formatxml/format /formats /configuration /plugin Then I start Maven (mvn clean install cobertura:cobertura), but the plugin generates the HTML reports under .../target/site/cobertura/ (which I tell it not to do), but doesn't create any XML files. What am I doing wrong? Best regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Travel Assistance to ApacheCon US 2008 - 3 days to apply!
The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Cobertura plugin doesn't generate XML
Answering the questions of Jens (later post) and yourself: 1. I had the plugin in the reporting section. If I put it into the build section, Maven tells me that the plugin can't be downloaded (we use an internal Archiva server, which should load unknown stuff from the official Maven repos). 2. Version 2.2 Best regards, Eric -Ursprüngliche Nachricht- Von: Nick Stolwijk [mailto:[EMAIL PROTECTED] Gesendet: Montag, 29. September 2008 12:33 An: Maven Users List Betreff: Re: Cobertura plugin doesn't generate XML I can think of two things, that could go wrong: 1. Did you configure this under the reporting section or under the build section of your pom file? It should be under the build section afaik. 2. Otherwise, what version of the cobertura plugin are you using? Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Sep 29, 2008 at 12:04 PM, Lewis, Eric [EMAIL PROTECTED] wrote: Hi I'm trying to generate an XML report using the Cobertura plugin (2.2 apparently). I configured the plugin according to the documentation: plugin groupIdorg.apache.maven.plugins/groupId artifactIdcobertura-maven-plugin/artifactId configuration formats formatxml/format /formats /configuration /plugin Then I start Maven (mvn clean install cobertura:cobertura), but the plugin generates the HTML reports under .../target/site/cobertura/ (which I tell it not to do), but doesn't create any XML files. What am I doing wrong? Best regards, Eric - 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]
mirrors, oh mirrors
Hi all, Mirrors are giving me headache recently. See this: mirrors mirror idcorporate-repo/id namecorporate-repo-backup/name url.../url mirrorOf*/mirrorOf /mirror mirror idcorporate-repo-backup/id namecorporate-repo-backup/name url.../url mirrorOf*/mirrorOf /mirror /mirrors Above configuration is a dead simple fail-over system. If corporate-repo is down, I want the corporate-repo-backup to mirror everything. Unfortunately it doesn't work :( It seems only last mirror is active when mirrorOf property is the same. Is this how it suppose to work? After all, the point of mirrors is to provide multiple locations for the same content, isn't it? Any input? Cheers, Szczepan Faber - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mirrors, oh mirrors
szczepiq wrote: Hi all, Mirrors are giving me headache recently. See this: mirrors mirror idcorporate-repo/id namecorporate-repo-backup/name url.../url mirrorOf*/mirrorOf /mirror mirror idcorporate-repo-backup/id namecorporate-repo-backup/name url.../url mirrorOf*/mirrorOf /mirror /mirrors Above configuration is a dead simple fail-over system. If corporate-repo is down, I want the corporate-repo-backup to mirror everything. Unfortunately it doesn't work :( It seems only last mirror is active when mirrorOf property is the same. Is this how it suppose to work? After all, the point of mirrors is to provide multiple locations for the same content, isn't it? Any input? The point of mirrors is to provide an alternate location for the content. This does not imply fallback. You can use for quite some OS organizations mirrors of their content (Apache, SF,net, ...), however, if you select a mirror and it is not available or out of date and your file is not found, you're also not automagically redirected to a different one, that is available and in sync. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot run program env
Hello, thanks for the reply. I tried a 2.0.9 version and the 2.1 preview releases, but the error still show up. Error getting environment vars for profile activation java.io.IOException: Cannot run program env: java.io.IOException: error=12, Cannot allocate memory I read in other posts, that there was a bug with the environment variables. But mine are fine. The good thing is the error do not crash maven this time. The env command cannot run because maven cannot spawn other processes. I do not know how to modify this behaviour. Brett Porter wrote: I believe someone encountered this recently and it was a result of running as the super user which had a very limited environment. You might find more information in the archives. Cheers, Brett 2008/9/29 greeklinux [EMAIL PROTECTED]: Hello, I am using maven, and I setup an CI system on a virtual server. When the build process starts, maven fails with the following error: Parsing POMs ERROR: Failed to parse POMs java.io.IOException: Cannot run program env: java.io.IOException: error=12, Cannot allocate memory at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) at java.lang.Runtime.exec(Runtime.java:593) at java.lang.Runtime.exec(Runtime.java:431) at java.lang.Runtime.exec(Runtime.java:328) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.init(RegexBasedModelInterpolator.java:63) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) at org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) at org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) at org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) at org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78) at hudson.maven.MavenEmbedder.start(MavenEmbedder.java:655) at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:75) at hudson.tasks.Maven$MavenInstallation.createEmbedder(Maven.java:337) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:691) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:640) at hudson.FilePath.act(FilePath.java:363) at hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:390) at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:285) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:240) at hudson.model.Run.run(Run.java:793) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:205) at hudson.model.ResourceController.execute(ResourceController.java:70) at
Maven @ ApacheCon US; Discounted rate until Fri Oct 3
For those thinking of attending ApacheCon US in New Orleans, these are the Maven sessions this year: * Brett Porter: Apache Maven, End-to-end (full-day training) http://us.apachecon.com/c/acus2008/sessions/89 * Brett Porter: More Apache Maven Best Practices (Presentation) http://us.apachecon.com/c/acus2008/sessions/50 * Carlos Sanchez: Q, Maven integration for Eclipse (Presentation) http://us.apachecon.com/c/acus2008/sessions/51 In addition to all the other useful Apache-related presentations, you'll no doubt find several Maven committers around the conference, Hackathon and Barcamp on Monday and Tuesday. For more information and registration, see http://www.us.apachecon.com/. There's still a discounted rate this week. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot run program env
Can you try running it under a different user account? - Brett 2008/9/29 greeklinux [EMAIL PROTECTED]: Hello, thanks for the reply. I tried a 2.0.9 version and the 2.1 preview releases, but the error still show up. Error getting environment vars for profile activation java.io.IOException: Cannot run program env: java.io.IOException: error=12, Cannot allocate memory I read in other posts, that there was a bug with the environment variables. But mine are fine. The good thing is the error do not crash maven this time. The env command cannot run because maven cannot spawn other processes. I do not know how to modify this behaviour. Brett Porter wrote: I believe someone encountered this recently and it was a result of running as the super user which had a very limited environment. You might find more information in the archives. Cheers, Brett 2008/9/29 greeklinux [EMAIL PROTECTED]: Hello, I am using maven, and I setup an CI system on a virtual server. When the build process starts, maven fails with the following error: Parsing POMs ERROR: Failed to parse POMs java.io.IOException: Cannot run program env: java.io.IOException: error=12, Cannot allocate memory at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) at java.lang.Runtime.exec(Runtime.java:593) at java.lang.Runtime.exec(Runtime.java:431) at java.lang.Runtime.exec(Runtime.java:328) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.init(RegexBasedModelInterpolator.java:63) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) at org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) at org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) at org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) at org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78) at hudson.maven.MavenEmbedder.start(MavenEmbedder.java:655) at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:75) at hudson.tasks.Maven$MavenInstallation.createEmbedder(Maven.java:337) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:691) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:640) at hudson.FilePath.act(FilePath.java:363) at hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:390) at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:285) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:240) at hudson.model.Run.run(Run.java:793) at
Accessing project version number from Java
What's the easiest way to get at the version number in the POM from
Java?
I've been using getResourceAsStream('META-INF/maven/groupId/artifactId/
pom.properties'); But this doesn't work while I'm developing in
Eclipse (only when using the built jar file).
Ideally, I'd like to somehow generate a Java class which contains the
version number. I thought I should be able to do this using resource
filtering, but I couldn't see a way to configure the resources plugin
to achieve this…
Any help would be most gratefully appreciated.
Thanks,
-Dom
Re: Accessing project version number from Java
2008/9/29 Dominic Mitchell [EMAIL PROTECTED]:
What's the easiest way to get at the version number in the POM from Java?
I've been using
getResourceAsStream('META-INF/maven/groupId/artifactId/pom.properties');
But this doesn't work while I'm developing in Eclipse (only when using the
built jar file).
Yes, this is only generated when the JAR is packaged. It might be best
for your test cases to substitute in a known value here rather than
relying on it, unless you are doing something specific with the
version.
Ideally, I'd like to somehow generate a Java class which contains the
version number. I thought I should be able to do this using resource
filtering, but I couldn't see a way to configure the resources plugin to
achieve this…
@project.version@ should be substituted in a copy, but resources are
processed after compilation so the timing is not correct. You'd need
to execute a specific plugin in the generate-sources phase.
- Brett
Any help would be most gratefully appreciated.
Thanks,
-Dom
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing project version number from Java
2008/9/29 Dominic Mitchell [EMAIL PROTECTED]:
What's the easiest way to get at the version number in the POM from Java?
I've been using
getResourceAsStream('META-INF/maven/groupId/artifactId/pom.properties');
But this doesn't work while I'm developing in Eclipse (only when using the
built jar file).
Ideally, I'd like to somehow generate a Java class which contains the
version number. I thought I should be able to do this using resource
filtering, but I couldn't see a way to configure the resources plugin to
achieve this…
Any help would be most gratefully appreciated.
You can use maven-runtime to dynamically obtain this information, but
it still has the limitation of requiring the META-INF files created at
package-time:
http://maven.apache.org/shared/maven-runtime/
I'd quite like to see the generation of these metadata files occur at
the generate-resources phase of the lifecycle which would allow it
work within the IDE too.
Cheers,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing project version number from Java
On 29 Sep 2008, at 13:08, Brett Porter wrote:
2008/9/29 Dominic Mitchell [EMAIL PROTECTED]:
What's the easiest way to get at the version number in the POM from
Java?
I've been using
getResourceAsStream('META-INF/maven/groupId/artifactId/
pom.properties');
But this doesn't work while I'm developing in Eclipse (only when
using the
built jar file).
Yes, this is only generated when the JAR is packaged. It might be best
for your test cases to substitute in a known value here rather than
relying on it, unless you are doing something specific with the
version.
There's nothing particularly important about this — it's just a minor
annoyance. We already substitute [dev] if we can't read it.
Ideally, I'd like to somehow generate a Java class which contains the
version number. I thought I should be able to do this using resource
filtering, but I couldn't see a way to configure the resources
plugin to
achieve this…
@project.version@ should be substituted in a copy, but resources are
processed after compilation so the timing is not correct. You'd need
to execute a specific plugin in the generate-sources phase.
I'll have a play with this to see if I can get it to do what I want.
Thanks for your quick response!
-Dom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing project version number from Java
On 29 Sep 2008, at 13:22, Mark Hobson wrote:
2008/9/29 Dominic Mitchell [EMAIL PROTECTED]:
What's the easiest way to get at the version number in the POM from
Java?
I've been using
getResourceAsStream('META-INF/maven/groupId/artifactId/
pom.properties');
But this doesn't work while I'm developing in Eclipse (only when
using the
built jar file).
You can use maven-runtime to dynamically obtain this information, but
it still has the limitation of requiring the META-INF files created at
package-time:
http://maven.apache.org/shared/maven-runtime/
Aha! Thanks for pointing this out. That's much more useful than
rolling my own implementation of such a thing.
I'd quite like to see the generation of these metadata files occur at
the generate-resources phase of the lifecycle which would allow it
work within the IDE too.
-Dom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: repository for youtube api
Hi, Have you already chosen the youtube API you're gonna use? Maven can't replace that. You won't choose a given library because it's available in some maven repo. You'll choose it 'cause it matches your needs. And if it's well-known, then there's chances that it's already present in some repo. Maybe google could be your friend... After 10 seconds of research: http://code.google.com/p/gdata-java-client/ It seems like it's not present in repo1 or google maven repository, so if this lib suits your needs, you might have to: * install it locally (or deploy in your corporate maven repo) * File an issue in the project ( http://code.google.com/p/gdata-java-client/issues/entry) to require a maven deployment Cheers. 2008/9/29 Angelo Chen [EMAIL PROTECTED] Hi, I need to use youtube api in my 'mavenized' app, is there a youtube dependency somewhere? thanks. A.C. -- View this message in context: http://www.nabble.com/repository-for-youtube-api-tp19719346p19719346.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Problems with path in pom (windows)
I actually set my local repo in my settings.xml to C:\opt\.m2 to avoid spaces. On Sun, Sep 28, 2008 at 7:52 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Sun, Sep 28, 2008 at 4:28 AM, Matthias Dorfner [EMAIL PROTECTED] wrote: I tried to integrate umlgraph to my pom. It looks as following: docletPathC:\Dokumente und Einstellungen\Matty\.m2\repository\UMLGraph-5.1\lib\UmlGraph.jar/docletPath Most likely the spaces in the path are causing problems. The best bet is to install the jar into your local repository using mvn install:install-file, and then use docletArtifact instead of docletPath, as shown here: http://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html The UMLGraph artifacts belong in groupId=gr.spinellis and artifactId=UmlGraph , see http://repo1.maven.org/maven2/gr/spinellis/UmlGraph/ (Adding arbitrary paths to ~/.m2/repository as you've done, apparently by unpacking the UMLGraph distribution, isn't recommended. The local repository has a specific format.) If you are working with a team and have a shared (internal) remote repository, then deploy the artifact there instead, and/or submit it for upload to the central repo. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Thank You… Mick Knutson BASE Logic, inc. (415) 354-4215 Website: http://baselogic.com Blog: http://baselogic.com/blog BLiNC Magazine: http://blincmagazine.com Linked IN: http://linkedin.com/in/mickknutson DJ Mick: http://djmick.com MySpace: http://myspace.com/mickknutson Vacation Rental: http://tahoe.baselogic.com
copy libraries to classpath
Hi, is it possible to let maven copy all dependencies to my classpath? my jar-configuration looks like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath classpathPrefixlib//classpathPrefix mainClassuboot.App/mainClass /manifest /archive /configuration /plugin so it would be nice if maven would create a lib-directory and copy all jars in to it since there are plenty of them and doing this by hand is troublesome cheers, Norbert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot run program env
Does maven have enough memory allocated? Looks like the virtual server does not have the minimum for maven to run. 128mb is the min I think. On Sun, Sep 28, 2008 at 8:10 AM, greeklinux [EMAIL PROTECTED] wrote: Hello, I am using maven, and I setup an CI system on a virtual server. When the build process starts, maven fails with the following error: Parsing POMs ERROR: Failed to parse POMs java.io.IOException: Cannot run program env: java.io.IOException: error=12, Cannot allocate memory at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) at java.lang.Runtime.exec(Runtime.java:593) at java.lang.Runtime.exec(Runtime.java:431) at java.lang.Runtime.exec(Runtime.java:328) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.init(RegexBasedModelInterpolator.java:63) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) at org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) at org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) at org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) at org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78) at hudson.maven.MavenEmbedder.start(MavenEmbedder.java:655) at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:75) at hudson.tasks.Maven$MavenInstallation.createEmbedder(Maven.java:337) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:691) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:640) at hudson.FilePath.act(FilePath.java:363) at hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:390) at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:285) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:240) at hudson.model.Run.run(Run.java:793) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:205) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:88) Caused by: java.io.IOException: java.io.IOException: error=12, Cannot allocate memory at java.lang.UNIXProcess.init(UNIXProcess.java:148) at java.lang.ProcessImpl.start(ProcessImpl.java:65) at java.lang.ProcessBuilder.start(ProcessBuilder.java:452) ... 41 more Is this because maven cannot create a new process? Or some other problem? Thanks -- View this message in context: http://www.nabble.com/Cannot-run-program-%22env%22-tp19712302p19712302.html Sent from the Maven - Users mailing list archive at
how to set '/' as root context for war?
I want to set my war to have a root context of '/' instead of 'mywarname/' I can't remember how to set this and would appreciate a refresher. -- --- Thank You… Mick Knutson BASE Logic, inc. (415) 354-4215 Website: http://baselogic.com Blog: http://baselogic.com/blog BLiNC Magazine: http://blincmagazine.com Linked IN: http://linkedin.com/in/mickknutson DJ Mick: http://djmick.com MySpace: http://myspace.com/mickknutson Vacation Rental: http://tahoe.baselogic.com
Re: Are we blocked by central Maven repo?
Rsync'ing the whole repository seems a real bad idea to me, I guess you
could be blacklisted doing that.
It's far better to do the downloading on demand and caching it by using a
common maven repo manager (archiva, nexus...).
In fact, if you mirror the whole repository, I guess you're just going to:
* waste your bandwidth and the central repo one during a quite long time
* waste your local disk space.
I guess you're unlikely going to use even 5% of the thousands of existing
artifacts from central.
Well, redirecting packets to repo1.maven.org might be acceptable, though
it's often useful to verify if the artifact is really available publicly
before insulting your corporate repo. I do it myself quite regularly.
Cheers.
2008/9/26 Beyer,Nathan [EMAIL PROTECTED]
It's possible that from the central repo's perspective, all traffic from
your company may seem like it's coming from one IP address because of NAT.
Using an internal mirror can help alleviate things. The most non-invasive
mirror would be to rsync the central repo periodically and then modify
internal DNS to point 'repo1.maven.org' to an internal IP address. You can
save a lot of bandwidth and time this way.
-Nathan
-Original Message-
From: 陈思淼 [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2008 10:47 AM
To: Maven Users List
Subject: Re: Are we blocked by central Maven repo?
we didn't do that kind of thing. we have a company-level artifactory
repository.someone didn't follow the rule but most of us are good citizen,
and follow the maven RULE,
Is maven block strategy to block IP too strict?
Can I do anything to Fix it Up?
2008/9/26 Wayne Fay [EMAIL PROTECTED]
It is possible to get blocked if you are acting as a bad citizen
(downloading the entire Central repo using wget, for example). Have
you (or someone else at your company) attempted to do this from your
IP address?
If not, the repo is probably just busy, or you had some random
Internet connection failure. Try again. Normal Maven usage of the
repo will not get you blocked.
Wayne
On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 [EMAIL PROTECTED] wrote:
This's log from artifactory.
2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
repo1:
Error in getting information for 'org/apache/maven
/maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
(org.apache.commons.httpclient.ConnectionPoolTimeoutException: Timeout
waiting
for connection).
we company only have one outlet IP address ,someone may download Maven
from
apache and didn't set the Mirror of central in the conf/setting.xml. so
they
download the pom directly from central? Is that the reason why the
central
repo block our IP address?
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: Are we blocked by central Maven repo?
First might be that you privately ask Jason if you are concerned by
http://blogs.sonatype.com/jvanzyl/2008/08/28/1219948661495.html
If so, then beg his pardon and promise you won't do it again, never :-).
But before annoying Jason, obviously try wget'ing something from
repo1.maven.org from your corporate maven repository server.
Cheers.
2008/9/26 陈思淼 [EMAIL PROTECTED]
we didn't do that kind of thing. we have a company-level artifactory
repository.someone didn't follow the rule but most of us are good citizen,
and follow the maven RULE,
Is maven block strategy to block IP too strict?
Can I do anything to Fix it Up?
2008/9/26 Wayne Fay [EMAIL PROTECTED]
It is possible to get blocked if you are acting as a bad citizen
(downloading the entire Central repo using wget, for example). Have
you (or someone else at your company) attempted to do this from your
IP address?
If not, the repo is probably just busy, or you had some random
Internet connection failure. Try again. Normal Maven usage of the
repo will not get you blocked.
Wayne
On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 [EMAIL PROTECTED] wrote:
This's log from artifactory.
2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
repo1:
Error in getting information for 'org/apache/maven
/maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
(org.apache.commons.httpclient.ConnectionPoolTimeoutException: Timeout
waiting
for connection).
we company only have one outlet IP address ,someone may download Maven
from
apache and didn't set the Mirror of central in the conf/setting.xml. so
they
download the pom directly from central? Is that the reason why the
central
repo block our IP address?
--
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: how to set '/' as root context for war?
This is a deployment option, dependent on your container. Unless you are referring to the Jetty Maven plugin, I don't believe there's anything in the WAR packaging process in Maven that affects this. - Brett 2008/9/27 Mick Knutson [EMAIL PROTECTED]: I want to set my war to have a root context of '/' instead of 'mywarname/' I can't remember how to set this and would appreciate a refresher. -- --- Thank You… Mick Knutson BASE Logic, inc. (415) 354-4215 Website: http://baselogic.com Blog: http://baselogic.com/blog BLiNC Magazine: http://blincmagazine.com Linked IN: http://linkedin.com/in/mickknutson DJ Mick: http://djmick.com MySpace: http://myspace.com/mickknutson Vacation Rental: http://tahoe.baselogic.com -- Brett Porter Blog: http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to set '/' as root context for war?
On Fri, Sep 26, 2008 at 7:29 PM, Mick Knutson [EMAIL PROTECTED]wrote: I want to set my war to have a root context of '/' instead of 'mywarname/' I can't remember how to set this and would appreciate a refresher. That's configuration in the application server, usually -- completely unrelated to Maven, unless you're talking about, say, making that happen in the Maven cargo plugin. - Geoffrey -- Geoffrey Wiseman
Re: copy libraries to classpath
using the maven-dependency-plugin with:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/lib/outputDirectory
overWriteReleasesfalse/overWriteReleases
overWriteSnapshotsfalse/overWriteSnapshots
overWriteIfNewertrue/overWriteIfNewer
/configuration
/execution
/executions
/plugin
like suggested on the plugin-homepage all dependencies are copied to
targed/dependencies. why is the outputDirectory ignored?
cheers,
Norbert
Norbert Lazzeri schrieb:
Hi,
is it possible to let maven copy all dependencies to my classpath?
my jar-configuration looks like:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifest
addClasspathtrue/addClasspath
classpathPrefixlib//classpathPrefix
mainClassuboot.App/mainClass
/manifest
/archive
/configuration
/plugin
so it would be nice if maven would create a lib-directory and copy all
jars in to it since there are plenty of them and doing this by hand is
troublesome
cheers,
Norbert
-
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: mirrors, oh mirrors
The point of mirrors is to provide an alternate location for the content. I'd like mirrors to provide multiple alternate locations. I put the improvement request here: http://jira.codehaus.org/browse/MNG-3772 Cheers, Szczepan On Mon, Sep 29, 2008 at 1:41 PM, Jörg Schaible [EMAIL PROTECTED] wrote: szczepiq wrote: Hi all, Mirrors are giving me headache recently. See this: mirrors mirror idcorporate-repo/id namecorporate-repo-backup/name url.../url mirrorOf*/mirrorOf /mirror mirror idcorporate-repo-backup/id namecorporate-repo-backup/name url.../url mirrorOf*/mirrorOf /mirror /mirrors Above configuration is a dead simple fail-over system. If corporate-repo is down, I want the corporate-repo-backup to mirror everything. Unfortunately it doesn't work :( It seems only last mirror is active when mirrorOf property is the same. Is this how it suppose to work? After all, the point of mirrors is to provide multiple locations for the same content, isn't it? Any input? The point of mirrors is to provide an alternate location for the content. This does not imply fallback. You can use for quite some OS organizations mirrors of their content (Apache, SF,net, ...), however, if you select a mirror and it is not available or out of date and your file is not found, you're also not automagically redirected to a different one, that is available and in sync. - Jörg - 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: Plugin inheritance
There is an attribute that you can specify to indicate that you are appending elements rather than replacing... if only I could remember it! 2008/9/29 tjunak [EMAIL PROTECTED] I've checked it again - every time a whole list is overriden not elements on the list. I have made few tries on different plugins - and the result is always the same. I have dozens of child-pom where their configuration in many cases differ a little. It looks that it is needed to move whole configuration from Parent-Pom into every child pom that need even a slight change in configuration (one extra element on the list). I hoped to keep common settings in Parent-Pom and that I could add specific options in some child-poms. But then in that case it is very hard to maintain - especially in a corporate level projects. Isn't it a bug? How does the merging work in Maven in case of list structure ? Thank you for any help! Baptiste MATHUS-4 wrote: Hi, You should try pluginManagement node to manage this, see http://maven.apache.org/pom.html#Plugin_Management. Cheers. 2008/9/25 tjunak [EMAIL PROTECTED] Hi, I have a following problem with plugin inheritance. I have put a plugin with lot of configuration in Parent-Pom, there are lot of child-poms in the project. Most of them use the plugin configuration but in some cases I have to re-define some options. Let's say: Parent-Pom: plugin artifactIdmy-plugin/artifactId configuration defines definedef-A/define definedef-B/define /defines /configuration /plugin In my real project there are much more such lists and elements. Child-Pom: Here I have to add some special define: plugin artifactIdmy-plugin/artifactId configuration defines definedef-C/define /defines /configuration /plugin The problem is that when I'm checking this with help:effective-pom I get only this: defines definedef-C/define /defines which means whole list is overriden not elements on the list. My expectation is to get: defines definedef-A/define definedef-B/define definedef-C/define /defines This causes that in a lot of child-poms I have re-write almost all configuration from Parent-Pom which of course will be later hard to maintain. Is there a way to inherit it on list elements level with Maven ? Thank you in advance! -- View this message in context: http://www.nabble.com/Plugin-inheritance-tp19664782p19664782.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- View this message in context: http://www.nabble.com/Plugin-inheritance-tp19664782p19722688.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin inheritance
You would do something like this: configuration items combine.children=append itemthree/item /items /configuration See http://www.ejlife.net/blogs/buildchimp/2007/06/07/1181254122408.html Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Sep 29, 2008 at 3:05 PM, Stephen Connolly [EMAIL PROTECTED] wrote: There is an attribute that you can specify to indicate that you are appending elements rather than replacing... if only I could remember it! 2008/9/29 tjunak [EMAIL PROTECTED] I've checked it again - every time a whole list is overriden not elements on the list. I have made few tries on different plugins - and the result is always the same. I have dozens of child-pom where their configuration in many cases differ a little. It looks that it is needed to move whole configuration from Parent-Pom into every child pom that need even a slight change in configuration (one extra element on the list). I hoped to keep common settings in Parent-Pom and that I could add specific options in some child-poms. But then in that case it is very hard to maintain - especially in a corporate level projects. Isn't it a bug? How does the merging work in Maven in case of list structure ? Thank you for any help! Baptiste MATHUS-4 wrote: Hi, You should try pluginManagement node to manage this, see http://maven.apache.org/pom.html#Plugin_Management. Cheers. 2008/9/25 tjunak [EMAIL PROTECTED] Hi, I have a following problem with plugin inheritance. I have put a plugin with lot of configuration in Parent-Pom, there are lot of child-poms in the project. Most of them use the plugin configuration but in some cases I have to re-define some options. Let's say: Parent-Pom: plugin artifactIdmy-plugin/artifactId configuration defines definedef-A/define definedef-B/define /defines /configuration /plugin In my real project there are much more such lists and elements. Child-Pom: Here I have to add some special define: plugin artifactIdmy-plugin/artifactId configuration defines definedef-C/define /defines /configuration /plugin The problem is that when I'm checking this with help:effective-pom I get only this: defines definedef-C/define /defines which means whole list is overriden not elements on the list. My expectation is to get: defines definedef-A/define definedef-B/define definedef-C/define /defines This causes that in a lot of child-poms I have re-write almost all configuration from Parent-Pom which of course will be later hard to maintain. Is there a way to inherit it on list elements level with Maven ? Thank you in advance! -- View this message in context: http://www.nabble.com/Plugin-inheritance-tp19664782p19664782.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- View this message in context: http://www.nabble.com/Plugin-inheritance-tp19664782p19722688.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy libraries to classpath
I think the outputDirectory is ignored because of the ArtifactItem
(whatever that may be... ;) )
From the documentation:
outputDirectory :
Default location used for mojo unless overridden in ArtifactItem
* Type: java.io.File
* Since: 1.0
* Required: No
* Expression: ${outputDirectory}
* Default: ${project.build.directory}/dependency
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Mon, Sep 29, 2008 at 3:01 PM, Norbert Lazzeri [EMAIL PROTECTED] wrote:
using the maven-dependency-plugin with:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/lib/outputDirectory
overWriteReleasesfalse/overWriteReleases
overWriteSnapshotsfalse/overWriteSnapshots
overWriteIfNewertrue/overWriteIfNewer
/configuration
/execution
/executions
/plugin
like suggested on the plugin-homepage all dependencies are copied to
targed/dependencies. why is the outputDirectory ignored?
cheers,
Norbert
Norbert Lazzeri schrieb:
Hi,
is it possible to let maven copy all dependencies to my classpath?
my jar-configuration looks like:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifest
addClasspathtrue/addClasspath
classpathPrefixlib//classpathPrefix
mainClassuboot.App/mainClass
/manifest
/archive
/configuration
/plugin
so it would be nice if maven would create a lib-directory and copy all
jars in to it since there are plenty of them and doing this by hand is
troublesome
cheers,
Norbert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy libraries to classpath
yeah i red that too. but i thought this would refer to the
configuration-section of the plugin :-S
cheers
norbert
Nick Stolwijk schrieb:
I think the outputDirectory is ignored because of the ArtifactItem
(whatever that may be... ;) )
From the documentation:
outputDirectory :
Default location used for mojo unless overridden in ArtifactItem
* Type: java.io.File
* Since: 1.0
* Required: No
* Expression: ${outputDirectory}
* Default: ${project.build.directory}/dependency
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Mon, Sep 29, 2008 at 3:01 PM, Norbert Lazzeri [EMAIL PROTECTED] wrote:
using the maven-dependency-plugin with:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/lib/outputDirectory
overWriteReleasesfalse/overWriteReleases
overWriteSnapshotsfalse/overWriteSnapshots
overWriteIfNewertrue/overWriteIfNewer
/configuration
/execution
/executions
/plugin
like suggested on the plugin-homepage all dependencies are copied to
targed/dependencies. why is the outputDirectory ignored?
cheers,
Norbert
Norbert Lazzeri schrieb:
Hi,
is it possible to let maven copy all dependencies to my classpath?
my jar-configuration looks like:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifest
addClasspathtrue/addClasspath
classpathPrefixlib//classpathPrefix
mainClassuboot.App/mainClass
/manifest
/archive
/configuration
/plugin
so it would be nice if maven would create a lib-directory and copy all
jars in to it since there are plenty of them and doing this by hand is
troublesome
cheers,
Norbert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
I second that.
We used to rsync the whole repo... but after the second time our internal
mirror server ran out of disk space we gave up and switched to nexus... the
whole thing is a lot more stable than the rsync nightmare... plus
we're not hitting 1/100 as much bandwith, and since we needed an internal
repo to deploy to anyway... win win win win
-Stephen
2008/9/26 Baptiste MATHUS [EMAIL PROTECTED]
Rsync'ing the whole repository seems a real bad idea to me, I guess you
could be blacklisted doing that.
It's far better to do the downloading on demand and caching it by using a
common maven repo manager (archiva, nexus...).
In fact, if you mirror the whole repository, I guess you're just going to:
* waste your bandwidth and the central repo one during a quite long time
* waste your local disk space.
I guess you're unlikely going to use even 5% of the thousands of existing
artifacts from central.
Well, redirecting packets to repo1.maven.org might be acceptable, though
it's often useful to verify if the artifact is really available publicly
before insulting your corporate repo. I do it myself quite regularly.
Cheers.
2008/9/26 Beyer,Nathan [EMAIL PROTECTED]
It's possible that from the central repo's perspective, all traffic from
your company may seem like it's coming from one IP address because of
NAT.
Using an internal mirror can help alleviate things. The most non-invasive
mirror would be to rsync the central repo periodically and then modify
internal DNS to point 'repo1.maven.org' to an internal IP address. You
can
save a lot of bandwidth and time this way.
-Nathan
-Original Message-
From: 陈思淼 [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2008 10:47 AM
To: Maven Users List
Subject: Re: Are we blocked by central Maven repo?
we didn't do that kind of thing. we have a company-level artifactory
repository.someone didn't follow the rule but most of us are good
citizen,
and follow the maven RULE,
Is maven block strategy to block IP too strict?
Can I do anything to Fix it Up?
2008/9/26 Wayne Fay [EMAIL PROTECTED]
It is possible to get blocked if you are acting as a bad citizen
(downloading the entire Central repo using wget, for example). Have
you (or someone else at your company) attempted to do this from your
IP address?
If not, the repo is probably just busy, or you had some random
Internet connection failure. Try again. Normal Maven usage of the
repo will not get you blocked.
Wayne
On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 [EMAIL PROTECTED] wrote:
This's log from artifactory.
2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
repo1:
Error in getting information for 'org/apache/maven
/maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
(org.apache.commons.httpclient.ConnectionPoolTimeoutException:
Timeout
waiting
for connection).
we company only have one outlet IP address ,someone may download
Maven
from
apache and didn't set the Mirror of central in the conf/setting.xml.
so
they
download the pom directly from central? Is that the reason why the
central
repo block our IP address?
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
creating a project
Hi guys, I use this command from the archetype plugin: Mvn archetype:create -DarchetpeGroupId=org.apache.maven.archetypes \ -DarchetypeArtifactId=maven-archetype-site \ -DgroupId=com.mycompany \ -DartifactId=my-site It creates a dedicated site project where I can customize the layout and the html (via apt, faq files etc.) output stuff. How can I integrate my java sources and reports for that sources (e.g. from javadoc, checkstyle, pmd, xref...) to this site? Regards, Matthias
RE: how to set '/' as root context for war?
Geoffrey Wiseman wrote: On Fri, Sep 26, 2008 at 7:29 PM, Mick Knutson [EMAIL PROTECTED]wrote: I want to set my war to have a root context of '/' instead of 'mywarname/' I can't remember how to set this and would appreciate a refresher. That's configuration in the application server, usually -- completely unrelated to Maven, unless you're talking about, say, making that happen in the Maven cargo plugin. - Geoffrey Unless you're using EAR files, in which case it's pretty trivial (and documented!). See http://maven.apache.org/plugins/maven-ear-plugin/examples/customizing-co ntext-root.html. There is no standard mechanism for specifying a context root of a standalone WAR deployment (i.e. outside of an EAR deployment). Justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are we blocked by central Maven repo?
What would you suggest then? Anything that requires customized maven installs
or modifying 'settings.xml' post install is not feasible in our environment -
development is too distributed.
In the long-run I believe the rsync approach does reduce bandwith, but more
importantly, the concurrent access to the central repo via HTTP is close to nil.
Additionally, as I mentioned, the repository managers are NOT stable and
require too much configuration and setup. These are not acceptable options. The
repository managers aren't providing any other value beyond central repo
caching for us.
If you're going to cut off anonymous rsync access, you might as well just kill
anonymous central repo access too, as that's the only way you'll be able to
force people into use repository managers.
I would suggest more granular rsync access, so that requests can be more
targeted.
-Nathan
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2008 3:51 PM
To: Maven Users List
Subject: Re: Are we blocked by central Maven repo?
On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote:
I disagree. 10gb or even 20gb isn't that much data, and rsync isn't
pulling that same amount down every time it runs. We're doing it and
it's working quite well. It's much more stable and reliable than any
other current mirroring practices. The internal DNS modification
makes user setup easy, since there isn't any. The use of mirror
settings per device is a non-starter for large, disparate
organizations. All of the various caching servers just aren't stable
enough yet, in my opinion.
It is possible to get blocked by the central repo - we were
contacted about our significant usage and told we were on the verge
of being blacklisted, which is what lead us to rsync the mirror.
There is no way you could use less bandwidth rsyncing then using a
repository manager. If everyone rsynced and we allowed that against
central we would get destroyed. We only allow mirrors to rsync, not
users and mirrors will probably also stop providing rsync access
because the first hit is just too high now if everyone did it.
-Nathan
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2008 11:11 AM
To: Maven Users List
Subject: Re: Are we blocked by central Maven repo?
IIRC Central is well over 10gb at this point (possibly 20gb) and a
given organization will really only use at the most 1gb of it, so
rsync'ing it is just a bad idea unless you are setting up an actual
external mirror that will be available to the community.
They are already using Artifactory, and I certainly hope/assume they
are caching the results. This would limit their use of Central to one
access per artifact (GAV) plus some hits by people not using their
Artifactory instance.
I would generally doubt they are actually blocked by Central, but
rather this is an intermittent failure that will eventually resolve
itself.
Wayne
2008/9/26 Beyer,Nathan [EMAIL PROTECTED]:
It's possible that from the central repo's perspective, all traffic
from your company may seem like it's coming from one IP address
because of NAT.
Using an internal mirror can help alleviate things. The most non-
invasive mirror would be to rsync the central repo periodically and
then modify internal DNS to point 'repo1.maven.org' to an internal
IP address. You can save a lot of bandwidth and time this way.
-Nathan
-Original Message-
From: 陈思淼 [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2008 10:47 AM
To: Maven Users List
Subject: Re: Are we blocked by central Maven repo?
we didn't do that kind of thing. we have a company-level artifactory
repository.someone didn't follow the rule but most of us are good
citizen,
and follow the maven RULE,
Is maven block strategy to block IP too strict?
Can I do anything to Fix it Up?
2008/9/26 Wayne Fay [EMAIL PROTECTED]
It is possible to get blocked if you are acting as a bad citizen
(downloading the entire Central repo using wget, for example). Have
you (or someone else at your company) attempted to do this from your
IP address?
If not, the repo is probably just busy, or you had some random
Internet connection failure. Try again. Normal Maven usage of the
repo will not get you blocked.
Wayne
On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 [EMAIL PROTECTED]
wrote:
This's log from artifactory.
2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
repo1:
Error in getting information for 'org/apache/maven
/maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
(org.apache.commons.httpclient.ConnectionPoolTimeoutException:
Timeout
waiting
for connection).
we company only have one outlet IP address ,someone may download
Maven
from
apache and didn't set the Mirror of central in the conf/
setting.xml. so
they
download the pom directly from central? Is that the reason why the
Re: Are we blocked by central Maven repo?
One thing I keep thinking about doing is creating a public mirror that is synced from central (it's a public mirror, thus, they would allow that), but provide rsync acess on some sort of paid agreement. Maybe $5/month or possibly just a ontime $100 setup fee or similar. Basically, enough to cover the bandwidth/hosting charges plus deter everyone and their mother from just rsyncing away.Is that something that people would have interest in? If I only had the time to get it setup... :-( Dan On Monday 29 September 2008 10:21:54 am Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. I would suggest more granular rsync access, so that requests can be more targeted. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the most 1gb of it, so rsync'ing it is just a bad idea unless you are setting up an actual external mirror that will be available to the community. They are already using Artifactory, and I certainly hope/assume they are caching the results. This would limit their use of Central to one access per artifact (GAV) plus some hits by people not using their Artifactory instance. I would generally doubt they are actually blocked by Central, but rather this is an intermittent failure that will eventually resolve itself. Wayne 2008/9/26 Beyer,Nathan [EMAIL PROTECTED]: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 10:47 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? we didn't do that kind of thing. we have a company-level artifactory repository.someone didn't follow the rule but most of us are good citizen, and follow the maven RULE, Is maven block strategy to block IP too strict? Can I do anything to Fix it Up? 2008/9/26 Wayne Fay [EMAIL PROTECTED] It is possible to get blocked if you are acting as a bad citizen (downloading the entire Central repo using wget, for example). Have you (or someone else at your company) attempted to do this from your IP address? If not, the repo is probably just busy, or you had some random Internet connection failure. Try again. Normal Maven usage of the repo will not get
Re: Are we blocked by central Maven repo?
Here is a quick set up for you. On your local machine that you were using for the internal mirror: 1. Install Apache httpd 2.2 with mod_proxy_ajp 2. Install Nexus 3. Front Nexus through ajp on the Apache httpd 4. Use a rewrite rule for /maven2 to /nexus/content/repositories/central/ 5. Change your internal dns records so that repo1.maven.org points to this local machine Now you have the same mirroring capabilities as before, only lower bandwidth and everything will be hunky-dorey 6. If you want to be ultra-fancy, add mod-proxy rules to map anything that's not on the server through to the real repo1.maven.org -Stephen 2008/9/29 Beyer,Nathan [EMAIL PROTECTED] What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. I would suggest more granular rsync access, so that requests can be more targeted. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the most 1gb of it, so rsync'ing it is just a bad idea unless you are setting up an actual external mirror that will be available to the community. They are already using Artifactory, and I certainly hope/assume they are caching the results. This would limit their use of Central to one access per artifact (GAV) plus some hits by people not using their Artifactory instance. I would generally doubt they are actually blocked by Central, but rather this is an intermittent failure that will eventually resolve itself. Wayne 2008/9/26 Beyer,Nathan [EMAIL PROTECTED]: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 10:47 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? we didn't do that kind of thing. we have a company-level artifactory repository.someone didn't follow the rule but most of us are good citizen, and follow the maven RULE, Is maven block strategy to block IP too strict? Can I do anything to Fix it Up? 2008/9/26 Wayne Fay [EMAIL PROTECTED] It is possible to get blocked if you are acting as a bad citizen (downloading the entire Central repo using wget, for example). Have you (or someone else at your company) attempted to do this from your IP address? If not, the repo is probably just busy, or you had
Re: Are we blocked by central Maven repo?
On 29-Sep-08, at 10:21 AM, Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. So how do you used your rsync'd repository? How do you get all your developers to use your in-house repository which is a copy of central? Using repository managers makes distributed development an order of magnitude easier. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Believe, as the one who looks at the logs and watch people crawl the repository this is not the case. In the long run you will see that you use less then 3% of what's in central so there is no point in pulling the bulk of the content. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. Hardly. We have people who have been using Nexus for over a year and they couldn't live without it now These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. You have no idea what you're talking about. Sorry but you're are sadly mistaken. - Does your organization like your developers' builds crawling around every repository listed in a POM? You have no control over that without a repository manager. Tell your management that you're not controlling access to external repositories and see how much they like that. - You can create and manage access by all your developers from one location, if you have multiple repositories which most organizations have, this is a nightmare without a repository manager - IDE integration? Using a Nexus index you get complete autocompletion in the POM editor, ability to search for all plugins available, all archetypes available. - Routing around bad metadata protecting your developers from mis- formed POMs which can happen - Optimized searching for dependencies i.e. don't think around the world for your company's artifacts or only take Apache artifacts from the Apache repository - Repository federation, by proxing other repositories in Nexus you can search them all - Deployment with a simple PUT, no requirement for the WebDAV provider - Fine grained access to repositories i.e. far more powerful then access via Apache If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. There is no anonymous rsync access to central, there never has been because the bandwidth charges would have made the situation unmanageable. We aren't forcing anyone to use repository managers, it boils down to a matter of cost in bandwidth. And people are using repository managers because it's just the smarter way to work with Maven. I would suggest more granular rsync access, so that requests can be more targeted. That pretty much amounts to the way a repository manager works. You're not going to get more targeted access then that. You get what you need and that's it. Run your CI system working against a repository manager will always keep your repository primed for use by your developers. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the
Re: Are we blocked by central Maven repo?
There is no rsync access to central. But the crawling is doing the equivalent amount of damage. There is no upside to using rsync over a repository manager. On 29-Sep-08, at 10:51 AM, Daniel Kulp wrote: One thing I keep thinking about doing is creating a public mirror that is synced from central (it's a public mirror, thus, they would allow that), but provide rsync acess on some sort of paid agreement. Maybe $5/month or possibly just a ontime $100 setup fee or similar. Basically, enough to cover the bandwidth/hosting charges plus deter everyone and their mother from just rsyncing away.Is that something that people would have interest in? If I only had the time to get it setup... :-( Dan On Monday 29 September 2008 10:21:54 am Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. I would suggest more granular rsync access, so that requests can be more targeted. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the most 1gb of it, so rsync'ing it is just a bad idea unless you are setting up an actual external mirror that will be available to the community. They are already using Artifactory, and I certainly hope/assume they are caching the results. This would limit their use of Central to one access per artifact (GAV) plus some hits by people not using their Artifactory instance. I would generally doubt they are actually blocked by Central, but rather this is an intermittent failure that will eventually resolve itself. Wayne 2008/9/26 Beyer,Nathan [EMAIL PROTECTED]: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 10:47 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? we didn't do that kind of thing. we have a company-level artifactory repository.someone didn't follow the rule but most of us are good citizen, and follow the maven RULE, Is maven block strategy to block IP too strict? Can I do anything to Fix it Up? 2008/9/26 Wayne Fay [EMAIL PROTECTED] It is possible to get blocked if you are acting as a bad citizen (downloading the entire Central repo using wget, for example). Have you (or someone else at your company) attempted to do this from your IP address? If not, the repo is probably just busy, or you had
RE: Are we blocked by central Maven repo?
Does anyone have anecdotal proof that Nexus can handle significant loads? In my experience, it hasn't been able to scale beyond a small group of users (less than 25). I'm aware of this option, but none of the repository managers, in my experience, have been able to scale as well as a Apache web server loading artifacts from a filesystem. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 10:05 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? Here is a quick set up for you. On your local machine that you were using for the internal mirror: 1. Install Apache httpd 2.2 with mod_proxy_ajp 2. Install Nexus 3. Front Nexus through ajp on the Apache httpd 4. Use a rewrite rule for /maven2 to /nexus/content/repositories/central/ 5. Change your internal dns records so that repo1.maven.org points to this local machine Now you have the same mirroring capabilities as before, only lower bandwidth and everything will be hunky-dorey 6. If you want to be ultra-fancy, add mod-proxy rules to map anything that's not on the server through to the real repo1.maven.org -Stephen 2008/9/29 Beyer,Nathan [EMAIL PROTECTED] What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. I would suggest more granular rsync access, so that requests can be more targeted. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the most 1gb of it, so rsync'ing it is just a bad idea unless you are setting up an actual external mirror that will be available to the community. They are already using Artifactory, and I certainly hope/assume they are caching the results. This would limit their use of Central to one access per artifact (GAV) plus some hits by people not using their Artifactory instance. I would generally doubt they are actually blocked by Central, but rather this is an intermittent failure that will eventually resolve itself. Wayne 2008/9/26 Beyer,Nathan [EMAIL PROTECTED]: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 10:47 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? we didn't do that kind of thing. we have a
RE: Are we blocked by central Maven repo?
Rsync - http://maven.apache.org/guides/mini/guide-mirror-settings.html (see 'Creating your own mirror') We aren't crawling. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 10:00 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? There is no rsync access to central. But the crawling is doing the equivalent amount of damage. There is no upside to using rsync over a repository manager. On 29-Sep-08, at 10:51 AM, Daniel Kulp wrote: One thing I keep thinking about doing is creating a public mirror that is synced from central (it's a public mirror, thus, they would allow that), but provide rsync acess on some sort of paid agreement. Maybe $5/month or possibly just a ontime $100 setup fee or similar. Basically, enough to cover the bandwidth/hosting charges plus deter everyone and their mother from just rsyncing away.Is that something that people would have interest in? If I only had the time to get it setup... :-( Dan On Monday 29 September 2008 10:21:54 am Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. I would suggest more granular rsync access, so that requests can be more targeted. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the most 1gb of it, so rsync'ing it is just a bad idea unless you are setting up an actual external mirror that will be available to the community. They are already using Artifactory, and I certainly hope/assume they are caching the results. This would limit their use of Central to one access per artifact (GAV) plus some hits by people not using their Artifactory instance. I would generally doubt they are actually blocked by Central, but rather this is an intermittent failure that will eventually resolve itself. Wayne 2008/9/26 Beyer,Nathan [EMAIL PROTECTED]: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 10:47 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? we didn't do that kind of thing. we have a company-level artifactory repository.someone didn't follow the rule but most of us are good citizen, and follow the maven
Re: Are we blocked by central Maven repo?
On Monday 29 September 2008 10:59:48 am Jason van Zyl wrote: There is no rsync access to central. But the crawling is doing the equivalent amount of damage. I was suggesting creating a new public mirror that would be listable on http://maven.apache.org/guides/mini/guide-mirror-settings.html as a public mirror. Thus, it could be pushed from central like the other mirrors. From there, people could rsync from that repo instead of central or ibiblio or such. There is no upside to using rsync over a repository manager. I disagree. For one, with rsync, if the network goes down, and an artifact that a developer wants that hasn't yet been used is requested, nexus is useless. He's still stuck. With an rsync everything is available. This HAS bitten us. We have several developers that work from home offices and thus have their own repo manager setup or similar (or maybe don't use one). They develop stuff, commit some changes. The nightly builds then run but due to network hickups, fail as the artifacts couldn't be retrieved since those builds are the first to ask for them. Managers come running and screaming saying maven sucks cause the build fail. Anything that keeps the managers from running to me screaming maven sucks is a good thing. They don't care about repo managers, rsyncs, etc They just want their builds to not fail for stupid reasons. Second, being a command line person, I like being able to login to the server and do something like find . -name *.pom | xargs grep somestring and such to find various things. (I know, the repo managers have search things, but gui's suck) Third, httpd can run and serve static files on some very lightweight hardware that cannot even begin to consider running java. As such, it's much faster than Nexus or others. Finally, this is the most important thing to me, each mirrored repository can be kept on a unique URL. http://proxy/central, http://proxy/java.net, http://proxy/apache-incubator, http://proxy/apache-snapshot, etc Thus, I can be sure that poms that are checked in have the appropriate repository entries that can resolve artifacts from their proper location in the absense of any repo manager.(Yes, Archiva can do this via the virtual repositories. Archiva is the only repo manager I would consider using because of this.) That said, there are a lot of advantages to using a repo manager as well. I admit that. But using a repo manager currently does not meet ALL requirements. Dan On 29-Sep-08, at 10:51 AM, Daniel Kulp wrote: One thing I keep thinking about doing is creating a public mirror that is synced from central (it's a public mirror, thus, they would allow that), but provide rsync acess on some sort of paid agreement. Maybe $5/month or possibly just a ontime $100 setup fee or similar. Basically, enough to cover the bandwidth/hosting charges plus deter everyone and their mother from just rsyncing away.Is that something that people would have interest in? If I only had the time to get it setup... :-( Dan -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are we blocked by central Maven repo?
As I mentioned in an earlier email, we rsync periodically, and override our internal DNS to redirect 'repo1.maven.org'. All internal developers automatically use the local copy. We don't crawl the repository. You may know people using Nexus for over a year that can't live without it. We've been using Apache web server mod_dav for three+ years with LDAP-based authentication and authorization - it has worked perfectly. As for all of your points about not having control of developers - a repository manager won't give me that either. There is no amount technology that can be applied to completely prevent any of those issues or countless others. I prefer to allow open access, facilitate developers, educate them and then review multiple times. The review points are where we begin to lock down and restrict access and the builds go through quality assurance, which can be automated. Locking down, filtering or controlling access up front prematurely limits innovation. I prefer to allow people to access what they want, as they want and as they move to later points in the process, then we tighten control as their builds move closer to manufacturing and work through dependency approval, license compliance, etc. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 9:59 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 29-Sep-08, at 10:21 AM, Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. So how do you used your rsync'd repository? How do you get all your developers to use your in-house repository which is a copy of central? Using repository managers makes distributed development an order of magnitude easier. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Believe, as the one who looks at the logs and watch people crawl the repository this is not the case. In the long run you will see that you use less then 3% of what's in central so there is no point in pulling the bulk of the content. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. Hardly. We have people who have been using Nexus for over a year and they couldn't live without it now These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. You have no idea what you're talking about. Sorry but you're are sadly mistaken. - Does your organization like your developers' builds crawling around every repository listed in a POM? You have no control over that without a repository manager. Tell your management that you're not controlling access to external repositories and see how much they like that. - You can create and manage access by all your developers from one location, if you have multiple repositories which most organizations have, this is a nightmare without a repository manager - IDE integration? Using a Nexus index you get complete autocompletion in the POM editor, ability to search for all plugins available, all archetypes available. - Routing around bad metadata protecting your developers from mis- formed POMs which can happen - Optimized searching for dependencies i.e. don't think around the world for your company's artifacts or only take Apache artifacts from the Apache repository - Repository federation, by proxing other repositories in Nexus you can search them all - Deployment with a simple PUT, no requirement for the WebDAV provider - Fine grained access to repositories i.e. far more powerful then access via Apache If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. There is no anonymous rsync access to central, there never has been because the bandwidth charges would have made the situation unmanageable. We aren't forcing anyone to use repository managers, it boils down to a matter of cost in bandwidth. And people are using repository managers because it's just the smarter way to work with Maven. I would suggest more granular rsync access, so that requests can be more targeted. That pretty much amounts to the way a repository manager works. You're not going to get more targeted access then that. You get what you need and that's it. Run your CI system working against a repository manager will always keep your repository primed for use by your developers. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users
JAR resources and WAR creation
I am interested in creating components that are made of Java classes packaged along with CSS and Javascript files. Components have dependencies between themselves. In the end, components are used to create web applications. I am thinking Maven is perfect for this, but I can not settle on the file format to use. Basically, in a Maven directory structure, a component is made of src/main/java files and webapp files. Yet, the preferred artifact file format would be JAR since other components requires the class files from it in their classpath. Finally, when all components are created, an all encompassing WAR application is built. When this happens, all the webapp files should be taken out of the JARs and put in the right places for WAR generation. In details, here would be the process. For a component: /src/main/java/**/*.java /src/main/webapp/**/* gets turned into a JAR: **/*.class META-INF/manifest.mf __webapp/**/* In final assembly into a WAR, all the files from the JARs under a __webapp directory gets copied into the top directory of the WAR. Is there anyone out there already performing similar packaging? If not, any suggestion on how to go about this would be appreciated. Thanks, JP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven schemaspy plugin with MSSql
Hello, I am using Oracle and ran into this same issue when I tried to run the Maven SchemaSpy Plugin. I have looked at the source code briefly and it appears that it is not passing along some required arguments for certain databases (like the -port argument you have mentioned). There are also some other issues with the version of SchemaSpy that is embedded and modified within the plugin involving the classloader for loading the JDBC drivers for databases not directly supported by the plugin. I can only say for certain that the plugin currently works with Apache Derby without some modifications. I actually plan on trying to fix this soon because I think this is a great tool. When I do, I'll contact the plugin creator to see if I can contribute it. In the short term, your only option is to download the source code and try to patch it yourself. ~Brad -Original Message- From: Sench [EMAIL PROTECTED] Reply-To: Maven Users List users@maven.apache.org To: users@maven.apache.org Subject: Maven schemaspy plugin with MSSql Date: Mon, 29 Sep 2008 00:10:02 -0700 (PDT) Hi all, Has anyone used before maven schemaspy plugin to generate DB schema site from MSSql? I'm trying to configure schemaspy plugin as described in http://maven.wakaleo.com/mojo/maven-schemaspy-plugin/usage.html http://maven.wakaleo.com/mojo/maven-schemaspy-plugin/usage.html as folows reporting plugins plugin groupIdcom.wakaleo.schemaspy/groupId artifactIdmaven-schemaspy-plugin/artifactId version1.0/version configuration databaseTypemssql/databaseType database[DbName]/database host[Host]/host user[Login]/user password[Password]/password /configuration plugin . plugins /reporting But during build of my site I'm getting this error Parameter '-port' (database port on host) missing. It is required for the specified database type. Why maven schemaspy plugin didn't trying to connect to MSSql with defaul port? Or how can I pass port to maven schemaspy plugin? Plz help, Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Invoker Plugin 1.3 Released
The Maven team is pleased to announce the release of the Maven Invoker Plugin, version 1.3. http://maven.apache.org/plugins/maven-invoker-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-invoker-plugin/artifactId version1.3/version /plugin Release Notes - Maven 2.x Invoker Plugin - Version 1.3 ** Bug * [MINVOKER-47] - Test builds fail to locate staged artifacts when using custom settings and non-default local repo path * [MINVOKER-48] - Project cloning does not retain empty directories * [MINVOKER-51] - NPE when packaging is pom * [MINVOKER-53] - Filtering erroneously interpolates expressions from the POM even if prefix is neither project nor pom * [MINVOKER-59] - Using invoker.profiles with empty value causes unintended build * [MINVOKER-60] - Artifact staging misses attached artifact metadata of POM projects ** Improvement * [MINVOKER-55] - Filter IT POMs in-place if cloneProjectsTo is used * [MINVOKER-56] - Clone all projects which are locally reachable from the invoked IT project * [MINVOKER-62] - Change the default value for the projectsDirectory parameter * [MINVOKER-64] - invoker:install does not install dependencies unless they are in the reactor * [MINVOKER-65] - Support token localRepositoryUrl for filtering settings.xml * [MINVOKER-67] - Create interpolated settings file in cloneProjectsTo directory and keep it after execution ** New Feature * [MINVOKER-7] - Add groovy support for pre/post build hook scripts * [MINVOKER-36] - Support for non-project based Maven invocations * [MINVOKER-46] - Allow multiple invocations of Maven on the same project * [MINVOKER-49] - Inject global variable with path to local repo into hook scripts * [MINVOKER-50] - Filter all POMs that are relevant to the forked build * [MINVOKER-52] - Add a new mojo parameter to specify filter properties using the more convenient map-syntax * [MINVOKER-57] - Allow to configure M2_HOME and JAVA_HOME for the forked builds * [MINVOKER-58] - Allow to declare setup projects which must be run before all the rest * [MINVOKER-61] - Allow to ignore failures Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
I'm not saying you are. It's the hundreds of other people trying it. You cannot sync against the central repository, you are syncing against ibiblio. Not the same thing. On 29-Sep-08, at 11:34 AM, Beyer,Nathan wrote: Rsync - http://maven.apache.org/guides/mini/guide-mirror- settings.html (see 'Creating your own mirror') We aren't crawling. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 10:00 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? There is no rsync access to central. But the crawling is doing the equivalent amount of damage. There is no upside to using rsync over a repository manager. On 29-Sep-08, at 10:51 AM, Daniel Kulp wrote: One thing I keep thinking about doing is creating a public mirror that is synced from central (it's a public mirror, thus, they would allow that), but provide rsync acess on some sort of paid agreement. Maybe $5/month or possibly just a ontime $100 setup fee or similar. Basically, enough to cover the bandwidth/hosting charges plus deter everyone and their mother from just rsyncing away.Is that something that people would have interest in? If I only had the time to get it setup... :-( Dan On Monday 29 September 2008 10:21:54 am Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. I would suggest more granular rsync access, so that requests can be more targeted. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the most 1gb of it, so rsync'ing it is just a bad idea unless you are setting up an actual external mirror that will be available to the community. They are already using Artifactory, and I certainly hope/assume they are caching the results. This would limit their use of Central to one access per artifact (GAV) plus some hits by people not using their Artifactory instance. I would generally doubt they are actually blocked by Central, but rather this is an intermittent failure that will eventually resolve itself. Wayne 2008/9/26 Beyer,Nathan [EMAIL PROTECTED]: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 10:47 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? we didn't do that kind of thing. we have a company-level
Re: Cannot run program env
Hi, after finishing my previous message I startet maven again, and got the error and maven stops again :confused: The behaviour is the same for root and my tomcat6 user account. I tried to give maven more memory, but did not help. (there are no min. mem. requirements for maven) Brett Porter wrote: Can you try running it under a different user account? - Brett 2008/9/29 greeklinux [EMAIL PROTECTED]: Hello, thanks for the reply. I tried a 2.0.9 version and the 2.1 preview releases, but the error still show up. Error getting environment vars for profile activation java.io.IOException: Cannot run program env: java.io.IOException: error=12, Cannot allocate memory I read in other posts, that there was a bug with the environment variables. But mine are fine. The good thing is the error do not crash maven this time. The env command cannot run because maven cannot spawn other processes. I do not know how to modify this behaviour. Brett Porter wrote: I believe someone encountered this recently and it was a result of running as the super user which had a very limited environment. You might find more information in the archives. Cheers, Brett 2008/9/29 greeklinux [EMAIL PROTECTED]: Hello, I am using maven, and I setup an CI system on a virtual server. When the build process starts, maven fails with the following error: Parsing POMs ERROR: Failed to parse POMs java.io.IOException: Cannot run program env: java.io.IOException: error=12, Cannot allocate memory at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) at java.lang.Runtime.exec(Runtime.java:593) at java.lang.Runtime.exec(Runtime.java:431) at java.lang.Runtime.exec(Runtime.java:328) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.init(RegexBasedModelInterpolator.java:63) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) at org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) at org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) at org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) at org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78) at hudson.maven.MavenEmbedder.start(MavenEmbedder.java:655) at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:75) at hudson.tasks.Maven$MavenInstallation.createEmbedder(Maven.java:337) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:691) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:640) at hudson.FilePath.act(FilePath.java:363) at
javadoc plugin fails during mvn release:perform ?
Hi, How come the javadoc plugin fails with a 'cannot find symbol XYZ' error when running 'mvn release:perform' but 'mvn site' works fine ? Since compilation works I would assume my pom.xml contains all required dependencies. Maven version: 2.0.9 (i386 Linux) JDK version: 1.5 (tested with 1.6 as well, both fail) maven-release-plugin: 2.0-beta-7 javadoc-plugin: 2.4 My project uses a rather large parent POM , unfortunately I had no time to try to reproduce this issue with a simpler POM yet. (Plugin) version numbers are inherited from a parent POM, along with dependency version numbers (although these are not completely managed using dependencyManagement/ , we're currently in a kind of 'transition phase' and use a mix of version properties and dependencyManagement in our parent POM). Regards, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
On 29-Sep-08, at 11:54 AM, Daniel Kulp wrote: On Monday 29 September 2008 10:59:48 am Jason van Zyl wrote: There is no rsync access to central. But the crawling is doing the equivalent amount of damage. I was suggesting creating a new public mirror that would be listable on http://maven.apache.org/guides/mini/guide-mirror-settings.html as a public mirror. Thus, it could be pushed from central like the other mirrors. From there, people could rsync from that repo instead of central or ibiblio or such. There is no upside to using rsync over a repository manager. I disagree. For one, with rsync, if the network goes down, and an artifact that a developer wants that hasn't yet been used is requested, nexus is useless. If your rsync just finished and the network hasn't gone down, and an artifact is released your developer makes a request for an artifact then your rsync'd repository is useless. There are potential holes in both cases but given the assumption your network is relatively healthy a repository manager is a more robust solution. Provided your CI mechanism is working against the repository manager it is going to be primed the vast majority of the time. The days of the repository being down for more then 10 minutes are over. So provided you have built in the recent past you have what you need. He's still stuck. With an rsync everything is available. This HAS bitten us. We have several developers that work from home offices and thus have their own repo manager setup or similar (or maybe don't use one). They develop stuff, commit some changes. The nightly builds then run but due to network hickups, fail as the artifacts couldn't be retrieved since those builds are the first to ask for them. Managers come running and screaming saying maven sucks cause the build fail. Anything that keeps the managers from running to me screaming maven sucks is a good thing. They don't care about repo managers, rsyncs, etc They just want their builds to not fail for stupid reasons. This is where repository managers vastly outstrip direct use. You can't do any routing to protect yourself, so bad metadata will hose your developers. I think your chances of problems with you developers are higher without a repository manager. Second, being a command line person, I like being able to login to the server and do something like find . -name *.pom | xargs grep somestring and such to find various things. (I know, the repo managers have search things, but gui's suck) You can do that with a repository manager that uses a file-based system like Nexus. The repository looks just like you expect unless you have your own store implementation. Nexus also has a rest API so you can have curl script to make a REST call to do a search, get a POM, an artifact, a configuration, the status. Anything that is available via the UI in Nexus is available via the CLI. The UI is just a REST client. Third, httpd can run and serve static files on some very lightweight hardware that cannot even begin to consider running java. As such, it's much faster than Nexus or others. Jetty using memory mapped buffers are really not that different. We are not currently doing that in Nexus but once we do it won't be that different. But the mediation that a repository manager provides means you can fix all sorts of crap you cannot drinking from the fire hose. Finally, this is the most important thing to me, each mirrored repository can be kept on a unique URL. http://proxy/central, http://proxy/java.net , http://proxy/apache-incubator, http://proxy/apache-snapshot, etc Thus, I can be sure that poms that are checked in have the appropriate repository entries that can resolve artifacts from their proper location in the absense of any repo manager.(Yes, Archiva can do this via the virtual repositories. Archiva is the only repo manager I would consider using because of this.) Nexus does this for certain, and I'm sure Artifactory does as well. But repositories in POMs are a bad practice and it's far easier to control everything from the repository manager. Repositories in POM make the artifacts non-portable which we've seen make a Maven environment pretty much unworkable. In an environment where you want partitioning and you promote artifacts based on quality (whether it's promoted to a different logical or physical repository) then you can have a build that is now targeted for a QA environment pointing back to a dev environment. Nexus can actually reroute any repository request in a POM but I consider it a Maven anti-pattern. The repository management side is now starting to parallel the changes that have happened in the build management side. I think it's a natural evolution in the use of Maven. That said, there are a lot of advantages to using a repo manager as
Re: reactor plugin Embedded error: Roots differ
Jorg Heymans wrote: The root-pom/pom.xml contains a modules section that just references the project modules modules module../modules/module /modules Yup, this is a known bug MREACTOR-1 http://jira.codehaus.org/browse/MREACTOR-1 It'll be pretty tough to fix it, I think. :-( -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: creating a project
Hi, I can now answer the question myself. If you want to create an skeleton with site structure for a already existing project, you have to run e.g. the archetype quickstart plugin first, second the e.g. maven-archetype-site-simple plugin. Of course both with same group and artifact Id. But the out-of-the-box linking for project information, project reports html files which is generated automatically by running the mvn site command is now on your own, as far as I know. Is there a blank index.apt somewhere which includes all these standard links? Thank you! Regards, Matthias -Ursprüngliche Nachricht- Von: Matthias Dorfner [mailto:[EMAIL PROTECTED] Gesendet: Montag, 29. September 2008 15:56 An: users@maven.apache.org Betreff: creating a project Hi guys, I use this command from the archetype plugin: Mvn archetype:create -DarchetpeGroupId=org.apache.maven.archetypes \ -DarchetypeArtifactId=maven-archetype-site \ -DgroupId=com.mycompany \ -DartifactId=my-site It creates a dedicated site project where I can customize the layout and the html (via apt, faq files etc.) output stuff. How can I integrate my java sources and reports for that sources (e.g. from javadoc, checkstyle, pmd, xref...) to this site? Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javadoc plugin fails during mvn release:perform ?
Hi Tobias, Some more details about your project would probably help. Do your missing symbols happen to be related to types created by source code generation? I had run into a similar problem with one of my builds a couple months ago, so let me share what I found. I had a multi-module project which used the XMLBeans Maven Plugin to generate some code from XML Schema files. I had the plugin defined in the module POM and had it configured to use JDK 1.5, which means amongst other things, that it creates get*List() methods in addition to get*Array() methods. The reactor project built fine, and I was able to successfully run site:site. After successfully running release:prepare, I tried release:perform, and all of a sudden the build failed with an error like: cannot find symbol symbol : method getPropertyList() location: interface I investigated this and found that the problem was that the XMLBeans Maven Plugin was being run multiple times during a reactor build, and during the site generation process it was being re-run but without the proper plugin configuration (specifically javaSource = 1.5 was not set). As a result, the get*List() versions of the methods were not being generated and the build failed. I tried several things to resolve this issue. I found that the only solution for me was to move the plugin configuration into the pluginManagement section of the root POM to insure that the configuration was always available, since for some unknown reason it was sometimes being omitted during a reactor build. This approach resolved the issue for me. I am not sure if this will help you at all, but I thought I would share in case you do have a similar configuration, or at least it may give you some ideas. I *think* this may be related to http://jira.codehaus.org/browse/MJAVADOC-179, but I am not sure. Good luck! ~Brad -Original Message- From: Tobias Gierke [EMAIL PROTECTED] Reply-To: Maven Users List users@maven.apache.org To: Maven Users List users@maven.apache.org Subject: javadoc plugin fails during mvn release:perform ? Date: Mon, 29 Sep 2008 18:13:45 +0200 Hi, How come the javadoc plugin fails with a 'cannot find symbol XYZ' error when running 'mvn release:perform' but 'mvn site' works fine ? Since compilation works I would assume my pom.xml contains all required dependencies. Maven version: 2.0.9 (i386 Linux) JDK version: 1.5 (tested with 1.6 as well, both fail) maven-release-plugin: 2.0-beta-7 javadoc-plugin: 2.4 My project uses a rather large parent POM , unfortunately I had no time to try to reproduce this issue with a simpler POM yet. (Plugin) version numbers are inherited from a parent POM, along with dependency version numbers (although these are not completely managed using dependencyManagement/ , we're currently in a kind of 'transition phase' and use a mix of version properties and dependencyManagement in our parent POM). Regards, Tobias - 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]
ConversionException
Hi,
what could be causing this exception (in maven 2.0.9)?
[INFO] Trace com.thoughtworks.xstream.converters.ConversionException:
dependenciesInfo : dependenciesInfo
Debugging information
message : dependenciesInfo : dependenciesInfo
cause-exception :
com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message : dependenciesInfo : dependenciesInfo
class : org.apache.maven.plugin.war.util.WebappStructure
required-type : org.apache.maven.plugin.war.util.WebappStructure
path: /webapp-structure/dependenciesInfo
line number : 10
---
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:45)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:46)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:117)
at
com.thoughtworks.xstream.core.ReferenceByXPathMarshallingStrategy.unmarshal(ReferenceByXPathMarshallingStrategy.java:29)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:846)
Here's what the pom looks like:
?xml version=1.0 encoding=UTF-8?
project xmlns=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;
modelVersion4.0.0/modelVersion
artifactIdnotificationWebUI/artifactId
packagingwar/packaging
parent
groupIdservice.notification/groupId
artifactIdnotificationProject/artifactId
version1.1.2-SNAPSHOT/version
relativePath../pom.xml/relativePath
/parent
dependencies
dependency
groupId${pom.groupId}/groupId
artifactIdnotificationClient/artifactId
version1.1.2-SNAPSHOT/version
scopeprovided/scope
/dependency
/dependencies
/project
thanks
Dmitry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: reactor plugin Embedded error: Roots differ
Dan Fabulich wrote: Jorg Heymans wrote: The root-pom/pom.xml contains a modules section that just references the project modules modules module../modules/module /modules Yup, this is a known bug MREACTOR-1 http://jira.codehaus.org/browse/MREACTOR-1 It'll be pretty tough to fix it, I think. :-( Wait, no, actually, I'm wrong. MREACTOR-1 is perfectly real, but the Different roots error you're getting is surprising to me; I can't reproduce it even following your directions. Note that, in the system you showed me, you should be able to go to the modules directory and do mvn reactor:make -Dmake.folders=A/api and get it to work. If that doesn't work, please put together a reduced test case (zip up a simplified set of Maven projects) and file a bug. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
2008/9/30 Dan Tran [EMAIL PROTECTED]: repo1.maven.org has a new IP Address, so if you hardcoded repo1.maven.org in your /etc/hosts you will have this problem. Sorry if this s a repeat. -D We're having this exact same problem. Our Nexus repository suddenly over the weekend couldn't access repo1. The machine on which the Nexus repository runs has limited access to the internet, based on IP address. So, if repo1's address has changed, this will be the cause. Thanks for the info! It wasn't a repeat for me, as I must have missed the first time. Given that we're pretty much dependant on that IP address not changing, I wish there was a better notification system for changes to central. It's just buggered up all of our builds for the last 1 1/2 days. Thanks, Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
We could start publishing a feed, but depending on the IP of the machine is probably not the best idea. Given that we've installed a load balancer the IP you get is going to be a whatever you get. On 29-Sep-08, at 6:59 PM, Ed Hillmann wrote: 2008/9/30 Dan Tran [EMAIL PROTECTED]: repo1.maven.org has a new IP Address, so if you hardcoded repo1.maven.org in your /etc/hosts you will have this problem. Sorry if this s a repeat. -D We're having this exact same problem. Our Nexus repository suddenly over the weekend couldn't access repo1. The machine on which the Nexus repository runs has limited access to the internet, based on IP address. So, if repo1's address has changed, this will be the cause. Thanks for the info! It wasn't a repeat for me, as I must have missed the first time. Given that we're pretty much dependant on that IP address not changing, I wish there was a better notification system for changes to central. It's just buggered up all of our builds for the last 1 1/2 days. Thanks, Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing project version number from Java
I use this little snippet inside ant build.xml target named
versionProperties to generate a Java file that gets compiled and provides a
constant (as ProgramVersion.VERSION):
property name=generated.src.dir
location=${basedir}/target/generated-sources/java /
echo
file=${generated.src.dir}/com/company/version/ProgramVersion.java
package com.company.version;
/** Generated in ANT */
public class ProgramVersion
{
public static final String VERSION = ${program.version};
}
/echo
Then this goes inside the buildplugins section of the pom:
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
property name=program.version
value=${pom.version}/property
ant antfile=build.xml dir=.
target=versionProperties inheritRefs=true /
/tasks
sourceRoot
${project.build.directory}/generated-sources/java
/sourceRoot
/configuration
/execution
/executions
/plugin
No need to use the pom.version value to set it but you do have to not put a
double-quote or a newline in there.
It works.
-- Lee
On Mon, Sep 29, 2008 at 7:37 AM, Dominic Mitchell [EMAIL PROTECTED] wrote:
On 29 Sep 2008, at 13:22, Mark Hobson wrote:
2008/9/29 Dominic Mitchell [EMAIL PROTECTED]:
What's the easiest way to get at the version number in the POM from Java?
I've been using
getResourceAsStream('META-INF/maven/groupId/artifactId/pom.properties');
But this doesn't work while I'm developing in Eclipse (only when using
the
built jar file).
You can use maven-runtime to dynamically obtain this information, but
it still has the limitation of requiring the META-INF files created at
package-time:
http://maven.apache.org/shared/maven-runtime/
Aha! Thanks for pointing this out. That's much more useful than rolling
my own implementation of such a thing.
I'd quite like to see the generation of these metadata files occur at
the generate-resources phase of the lifecycle which would allow it
work within the IDE too.
-Dom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com
Re: Are we blocked by central Maven repo?
On Tue, Sep 30, 2008 at 9:38 AM, Jason van Zyl [EMAIL PROTECTED] wrote: We could start publishing a feed, but depending on the IP of the machine is probably not the best idea. Given that we've installed a load balancer the IP you get is going to be a whatever you get. Thanks for the info. We'll have to address our setup and either find a mirror with a fixed IP or see if we can do this another way (second option is up to my IS dept, not me). Thanks, Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site deployment to sourceforge.net broken
Is there an official answer for Marat's question? Can site plugin be configured to deploy file by file instead of zip/unzip? Thanks. http://sourceforge.net/community/forum/topic.php?id=3518pagereplies=1 Regards -Jiaqi Guo SourceForge Marat Radchenko wrote: After last changes in sf.net infrastructure there are three ways of uploading stuff to web area: 1) sftp 2) scp 3) rsync over ssh I've tried two first options and they both failed. Maven uploads zip file (wagon.zip) and then tries to unzip it. However unzip commandis not available. As far as I understand, Maven doesn't support site deployment via rsync. Am I doing something wrong or it is a real bug? Any existing workarounds? - 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: Maven schemaspy plugin with MSSql
Hi Brad, Thanks for your reply. I needn't to download source, I'll wait still normal version would be released. Thanks! -- View this message in context: http://www.nabble.com/Maven-schemaspy-plugin-with-MSSql-tp19719190p19736091.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven schemaspy plugin with MSSql
Perhaps you should consider using the jdbcUrl parameter instead? That should let you pass the port info, I would assume. *Note: I've never used this plugin, just glanced at the docs. Wayne On Mon, Sep 29, 2008 at 9:45 PM, Sench [EMAIL PROTECTED] wrote: Hi Brad, Thanks for your reply. I needn't to download source, I'll wait still normal version would be released. Thanks! -- View this message in context: http://www.nabble.com/Maven-schemaspy-plugin-with-MSSql-tp19719190p19736091.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: YUICompressor plugin going ape
additionally I would try running the build with command line maven (is settable in project's properties) In fact the command line maven execution will be default in netbeans 6.5 as the embedded build is encountering many problems. Incompatibility with the latest released bits, bugs, not having plugins ready for embedded use. Milos On Thu, Sep 11, 2008 at 6:56 PM, nicolas de loof [EMAIL PROTECTED] wrote: This plugin is not part of standard maven plugins. Please report your issue to alchim.sf.net 2008/9/11 John Coleman [EMAIL PROTECTED] Hi, The YUICompressor plugin gives the dump below. Anyone have any ideas why this should suddenly go wrong? We already tried to get a fresh update from the central repo. Is this maybe a mvn version issue given that it is a core mvn plugin class missing? TIA, John Using default encoding to copy filtered resources. [yuicompressor:compress] [FATAL]net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo#execute() caused a linkage error (java.lang.NoClassDefFoundError). Check the realms: [FATAL]NOTE: [FATAL]Plugin realm is: /plugins/net.sf.alchim:yuicompressor-maven-plugin:[EMAIL PROTECTED]/thread:exec_B uild eTraderII_17 [FATAL]Container realm is: plexus.core [FATAL]Realm ID: /plugins/net.sf.alchim:yuicompressor-maven-plugin:[EMAIL PROTECTED]/thread:exec_B uild eTraderII_17 [FATAL]urls[0] = file:/C:/Documents%20and%20Settings/user/.m2/repository/net/sf/alchim/yu icompressor-maven-plugin/0.6.3/yuicompressor-maven-plugin-0.6.3.jar [FATAL]urls[1] = file:/C:/Documents%20and%20Settings/user/.m2/repository/rhino/js/1.6R7/j s-1.6R7.jar [FATAL]urls[2] = file:/C:/Documents%20and%20Settings/user/.m2/repository/net/sf/retrotran slator/retrotranslator-runtime/1.2.1/retrotranslator-runtime-1.2.1.jar [FATAL]urls[3] = file:/C:/Documents%20and%20Settings/user/.m2/repository/backport-util-co ncurrent/backport-util-concurrent/3.0/backport-util-concurrent-3.0.jar [FATAL]Realm ID: plexus.core [FATAL]urls[0] = file:/C:/Documents%20and%20Settings/user/.netbeans/6.1/maven2/rootpackag e/ java.lang.NoClassDefFoundError: org/codehaus/plexus/util/DirectoryScanner at net.sf.alchim.mojo.yuicompressor.MojoSupport.processDir(MojoSupport.java :133) at net.sf.alchim.mojo.yuicompressor.MojoSupport.execute(MojoSupport.java:10 3) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:579) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:498) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentFo rProject(DefaultLifecycleExecutor.java:265) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:191) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:149) at org.codehaus.mevenide.netbeans.embedder.exec.MyLifecycleExecutor.execute (MyLifecycleExecutor.java:72) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.ja va:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedde r.java:904) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(Maven Embedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.codehaus.mevenide.netbeans.execute.MavenJavaExecutor.run(MavenJavaEx ecutor.java:215) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151) Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan
