Resources Plugin - is it possible to filter my.filters in dependency.jar ?
Hi, is it possible to filter my.filters in a .jar (one of those referenced with dependency) ? Regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for the internet afraid
Chris Helck wrote: Could you clarify the security requirement? It sounds like you don't want unverified jars entering the development space. Is this correct? That is essentially correct. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to override "src/site" for site doc inputs?
Simply enough, ... maven-site-plugin site ... I doubt, however, that this is really what you're looking for. At risk of stating the obvious, you will be much happier in the long run if you can transition to the standard directory structure. By taking a half-and-half approach, you will most likely feel equivalent pain again when you decide you really should accept Maven's opinionated ways. Dan Rollo wrote: Does anybody know of a good place to put some free-form documentation files in the maven project/pom.xml? I know the default location appears to be "src/site", but I overrode the default source location when creating our pom.xml (to minimize changes) to be "src". Therefore, stuffing docs into the actual source code tree would be confusing (at best). I couldn't see where to configure an override for the site input in a pom.xml. Our project pom overrides are: ... src ... test ... Thanks, Dan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: 5 minute guide - Incorrect documentation/documentation improvement?
On Tue, Feb 3, 2009 at 10:34 AM, Wayne Fay wrote: >> Since that is now deprecated in favour of archetype:generate, should >> the documentation be updated to use the non deprecated project >> creation method? > > All Maven bugs, including those in documentation, go in JIRA... And if you checkout the code and attach a patch, it is more likely to get fixed :) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: 5 minute guide - Incorrect documentation/documentation improvement?
> Since that is now deprecated in favour of archetype:generate, should > the documentation be updated to use the non deprecated project > creation method? All Maven bugs, including those in documentation, go in JIRA... Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Issue with ArtifactHandler in reactor builds
I am having an issue on 2.0.9. Basicallly, I have a custom plugin that has it's own packaging type and creates a file of it's own extension type. This only happens if I run a reactor build. If run maven in that project, it works correctly. For example, my-bundle will create artifactId-version.exe However, with maven-2.0.9 it creates the file correcting in the target directory but it installs it and deploys it as artifactId-version.my-bundle. Here is an example output: [INFO] Installing C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe to C:\Documents and Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle I wrote a similar plugin with a previous company and it worked fine. That was on maven-2.0.7 though. Here is my component.xml snippet? ... org.apache.maven.artifact.handler.ArtifactHandler my-bundle org.apache.maven.artifact.handler.DefaultArtifactHandler exe my-bundle my-bundle java true Does anyone have any ideas what could be happening here or have a good way to debug this?
Issue with ArtifactHandler in reactor builds
I am having an issue on 2.0.9. Basicallly, I have a custom plugin that has it's own packaging type and creates a file of it's own extension type. This only happens if I run a reactor build. If run maven in that project, it works correctly. For example, my-bundle will create artifactId-version.exe However, with maven-2.0.9 it creates the file correcting in the target directory but it installs it and deploys it as artifactId-version.my-bundle. Here is an example output: [INFO] Installing C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe to C:\Documents and Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle I wrote a similar plugin with a previous company and it worked fine. That was on maven-2.0.7 though. Here is my component.xml snippet? ... org.apache.maven.artifact.handler.ArtifactHandler my-bundle org.apache.maven.artifact.handler.DefaultArtifactHandler exe my-bundle my-bundle java true Does anyone have any ideas what could be happening here?
[maven-user] Environment dependant and independent modules question
Meant to prefix this email with maven-user, my apologies. From: John Prystash To: Maven Users List Sent: Monday, February 2, 2009 10:08:53 AM Subject: [mule-user] Environment dependant and independent modules question Hi, I have a couple best practices questions. My project setup is a parent with two modules, I'll call them core and container. The core module has all the core logic. The container module depends on it and packages everything up via the assembly plugin for distribution. The core is environment-independent, no property filters, and the container module is environment dependent with properties files filtered for environment specific things (install directory, db connections, ports, etc.). Now I throw in an applicationContext.xml for Spring with many of beans dependant on environment specific database information. Since the Application Context is specific and really required by the core logic, I would first think that the file belongs in my core module, but that then breaks the environment-independent aspect of the core, so maybe the container module would be better? On the other hand, my database-related beans and the related Application Context definitions might be better served living in a third "datbase" module. I could then keep the core entity classes environment-independent and have the new module depend on the core. Second question: In my container module, I reproduce many of the dependencies found in the core module scoped at runtime so that they can be included in my assembly. To avoid this duplication, would it may be better to have the core module produce a jar-with-dependenices and have only that be part of the assembly? What would be the best or recommended practice here? Whew.. Thanks for any thoughts and insights in advance.
Re: pde build with maven
Jason is correct, I am no longer working with PDE plugin since I dont have direct working environment with eclipse PDE any more. -D On Mon, Feb 2, 2009 at 9:30 AM, Jason van Zyl wrote: > Igor and I will eventually synchronize many of the changes but Tycho > currently does work as we use it for m2eclipse everyday. Tycho is in active > development. I don't believe Dan is working on the PDE plugin anymore but he > can correct me if that's not right. > > On 2-Feb-09, at 6:38 AM, Konstantin Domoratskyy wrote: > >> Hi, >> >> my recomendation for rcp build with maven is "tycho" maven: >> e.g. http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview >> But you must be ready the project configuration with tycho differs >> often from "normal" Maven one. >> >> Gruß, >> Konstantin >> >> --- >>> >>> Hi, i want to setup my rcp project with a maven build. so first i >> >> want >>> >>> to build succesfully the example from the pde-maven-plugin site. >>> >>> i started by downloading the following eclipse sdk and delta pack: >>> - eclipse-3.4.1-delta-pack.zip >>> - eclipse-RCP-SDK-3.4.1-win32.zip >>> >>> i read through the examples from pde-maven-plugin mojo and found a >>> tutorial that builds a product. >>> >>> this tutorial can be found here: >>> >> http://snapshots.repository.codehaus.org/org/codehaus/mojo/pde-maven-p >> lugin/ >>> >>> i downloaded this one: >>> pde-maven-plugin-1.0-20080304.235354-2-tutorials.zip (if you want an >> >>> SSCCE (http://pscode.org/sscce.html)) >>> >>> after i imported the project to my eclipse ide i have done som >> >> changes >>> >>> to build.properties and pom.xml to ensure the paths are well formed. >> >>> (the name of the plugin is: >> >> test.pde_maven_plugin.simple_application) >>> >>> now i tried the pde build to be sure its running without maven: >>> >>> 1) launch the application (SUCCESSFUL) >>> 2) launch the product (SUCCESSFUL) >>> 3) export as product and launch (SUCCESSFUL) >>> >>> everything works fine! now i tried to do the maven install, but this >> >> failed: >>> >>> BUILD FAILED >>> >> D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v2008 >> 0604\scripts\productBuild\productBuild.xml:25: >>> >>> The following error occurred while executing this line: >>> >> D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v2008 >> 0604\scripts\productBuild\productBuild.xml:53: >>> >>> Unable to find plug-in: test.pde_maven_plugin.simple_application. >> >> Please >>> >>> check the error log for more details. >>> >>> as you can see, the pde build (i think) can't found the application >> >> i >>> >>> want to export, it seems that maven doesn't calls the pde build for >> >> the >>> >>> application first, it assumes that the plugin has already be there? >> >> if i >>> >>> change the maven packaging to jar, do the install, copy this jar to >> >> my >>> >>> target.env into plugins change packaging back to zip, do the install >> >>> again. everything runs fine, but this isn't a great solutions or? in >> >> my >>> >>> pov i think this should be done by pde build? please correct me if i >> >> am >>> >>> wrong if you need more informartions just let me know -- or if you >> >> got >>> >>> time have a look inside the maven-pde-plugin tutorial. >>> >>> thank you >>> chris >>> >>> >> - >>> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [SPAM] RE: Maven deploy project on a server different from remote repo server
I am doing something like this using dependency:unpack-dependencies at the generate-resources phase. This way I don't have to think about a jar of jars or classpath. -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Monday, February 02, 2009 12:19 PM To: Maven Users List Subject: [SPAM] RE: Maven deploy project on a server different from remote repo server Importance: Low You could use the assembly plugin to produce a bundle with the dependencies. Or you could patch something together with dependency:copy-dependencies and dependency:build-classpath -Original Message- From: Qureshi,Shahzad [Ontario] [mailto:shahzad.qure...@ec.gc.ca] Sent: Monday, February 02, 2009 11:26 AM To: users@maven.apache.org Subject: Maven deploy project on a server different from remote repo server Hi all, Here is the situation. Our internal remote repository is on server1 and my application that will require some of the jars sitting on the remote repo is on server2. Now my application is in jar format (created using maven) and is used by a web coldfusion based application. Now, do I simply figure out which dependencies my app requires and manually put them somewhere on server2 and use the classpath way of doing things to run this app or is there a better way to do this using Maven? I have been using Maven for a few months now and I understand how it works but I am not sure what to do in this deployment scenario that I mentioned above Any insights will be appreciated. Thank you Shahzad Qureshi Systems Analyst/Programmer Applications Directorate, CIOB Environment Canada shahzad.qure...@ec.gc.ca - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Archiva and Maven 2.0.9, defect POM
Once you have deleted the directory from disk you will have to update the database (admin: database > update database now) and scan your repository (admin: repositories > scan repository now). -Original Message- From: Michael Hüttermann [mailto:mich...@huettermann.net] Sent: Monday, February 02, 2009 12:04 PM To: Maven Users List Subject: RE: Archiva and Maven 2.0.9, defect POM Thanks, but migrating the tooling is not a solution strategy for us. Any ideas to solve that issue? Thanks !!! > We had similar issues with archiva. These type of issues were resolved > when we went to http://nexus.sonatype.org/ > > -Original Message- > From: Michael Hüttermann [mailto:mich...@huettermann.net] > Sent: Monday, February 02, 2009 11:45 AM > To: users@maven.apache.org > Subject: Archiva and Maven 2.0.9, defect POM > > Hello, > > I use Maven 2.0.9 and Archiva 1.1.1. > In my environment the central proxy repository Archiva has a defect > entry for \internal\org\apache\maven\maven\2.0.9. After some manual > and suboptimal work there only dummy data garbage is existing in that folder. > Actually after installing Archiva the folder was not existing at all. > > OK, now I have issues with that defect entries for 2.0.9, and I > removed the whole folder \internal\org\apache\maven\maven\2.0.9 from > disc. I'm not sure how wise this was, but if I trigger a "mvn install" > or if I browse Archiva via web interface, I still get and see the old > and corrupt 2.0.9 version. > > So the question is, how can I refresh Archiva that it will deliver the > right 2.0.9 version for me? The correct version I see under > http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.9/ ? > > Thank you for your time!!! > > Best regards > Michael > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Archiva and Maven 2.0.9, defect POM
On Mon, Feb 2, 2009 at 9:45 AM, Michael Hüttermann wrote: > I use Maven 2.0.9 and Archiva 1.1.1. > In my environment the central proxy repository Archiva has a defect entry > for \internal\org\apache\maven\maven\2.0.9. After some manual and > suboptimal work there only dummy data garbage is existing in that folder. > Actually after installing Archiva the folder was not existing at all. Please ask on the Archiva users list, you can find subscription info at http://archiva.apache.org/mail-lists.html . -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Archiva and Maven 2.0.9, defect POM
We have tools that would allow you to do this very quickly. Tools for separate a repository into a proper snapshot/release repository and from that point a few configuration changes and you're done. I took Matt Raible's Appfuse repository and flipped it into Nexus in less the 30 minutes. On 2-Feb-09, at 9:04 AM, Michael Hüttermann wrote: Thanks, but migrating the tooling is not a solution strategy for us. Any ideas to solve that issue? Thanks !!! We had similar issues with archiva. These type of issues were resolved when we went to http://nexus.sonatype.org/ -Original Message- From: Michael Hüttermann [mailto:mich...@huettermann.net] Sent: Monday, February 02, 2009 11:45 AM To: users@maven.apache.org Subject: Archiva and Maven 2.0.9, defect POM Hello, I use Maven 2.0.9 and Archiva 1.1.1. In my environment the central proxy repository Archiva has a defect entry for \internal\org\apache\maven\maven\2.0.9. After some manual and suboptimal work there only dummy data garbage is existing in that folder. Actually after installing Archiva the folder was not existing at all. OK, now I have issues with that defect entries for 2.0.9, and I removed the whole folder \internal\org\apache\maven\maven\2.0.9 from disc. I'm not sure how wise this was, but if I trigger a "mvn install" or if I browse Archiva via web interface, I still get and see the old and corrupt 2.0.9 version. So the question is, how can I refresh Archiva that it will deliver the right 2.0.9 version for me? The correct version I see under http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.9/ ? Thank you for your time!!! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: pde build with maven
Igor and I will eventually synchronize many of the changes but Tycho currently does work as we use it for m2eclipse everyday. Tycho is in active development. I don't believe Dan is working on the PDE plugin anymore but he can correct me if that's not right. On 2-Feb-09, at 6:38 AM, Konstantin Domoratskyy wrote: Hi, my recomendation for rcp build with maven is "tycho" maven: e.g. http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview But you must be ready the project configuration with tycho differs often from "normal" Maven one. Gruß, Konstantin --- Hi, i want to setup my rcp project with a maven build. so first i want to build succesfully the example from the pde-maven-plugin site. i started by downloading the following eclipse sdk and delta pack: - eclipse-3.4.1-delta-pack.zip - eclipse-RCP-SDK-3.4.1-win32.zip i read through the examples from pde-maven-plugin mojo and found a tutorial that builds a product. this tutorial can be found here: http://snapshots.repository.codehaus.org/org/codehaus/mojo/pde-maven-p lugin/ i downloaded this one: pde-maven-plugin-1.0-20080304.235354-2-tutorials.zip (if you want an SSCCE (http://pscode.org/sscce.html)) after i imported the project to my eclipse ide i have done som changes to build.properties and pom.xml to ensure the paths are well formed. (the name of the plugin is: test.pde_maven_plugin.simple_application) now i tried the pde build to be sure its running without maven: 1) launch the application (SUCCESSFUL) 2) launch the product (SUCCESSFUL) 3) export as product and launch (SUCCESSFUL) everything works fine! now i tried to do the maven install, but this failed: BUILD FAILED D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v2008 0604\scripts\productBuild\productBuild.xml:25: The following error occurred while executing this line: D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v2008 0604\scripts\productBuild\productBuild.xml:53: Unable to find plug-in: test.pde_maven_plugin.simple_application. Please check the error log for more details. as you can see, the pde build (i think) can't found the application i want to export, it seems that maven doesn't calls the pde build for the application first, it assumes that the plugin has already be there? if i change the maven packaging to jar, do the install, copy this jar to my target.env into plugins change packaging back to zip, do the install again. everything runs fine, but this isn't a great solutions or? in my pov i think this should be done by pde build? please correct me if i am wrong if you need more informartions just let me know -- or if you got time have a look inside the maven-pde-plugin tutorial. thank you chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven deploy project on a server different from remote repo server
You could use the assembly plugin to produce a bundle with the dependencies. Or you could patch something together with dependency:copy-dependencies and dependency:build-classpath -Original Message- From: Qureshi,Shahzad [Ontario] [mailto:shahzad.qure...@ec.gc.ca] Sent: Monday, February 02, 2009 11:26 AM To: users@maven.apache.org Subject: Maven deploy project on a server different from remote repo server Hi all, Here is the situation. Our internal remote repository is on server1 and my application that will require some of the jars sitting on the remote repo is on server2. Now my application is in jar format (created using maven) and is used by a web coldfusion based application. Now, do I simply figure out which dependencies my app requires and manually put them somewhere on server2 and use the classpath way of doing things to run this app or is there a better way to do this using Maven? I have been using Maven for a few months now and I understand how it works but I am not sure what to do in this deployment scenario that I mentioned above Any insights will be appreciated. Thank you Shahzad Qureshi Systems Analyst/Programmer Applications Directorate, CIOB Environment Canada shahzad.qure...@ec.gc.ca - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: RE: nexus can't find maven-archetype-plugin?
You will have trouble getting snapshots with your settings because you are only mirroring central which is not enabled for snapshots. You want to use something like this: nexus * http://localhost:8081/nexus/content/groups/public development central http://central true true central http://central true true development -Original Message- From: Jens Rapp [mailto:tec_la...@gmx.de] Sent: Monday, February 02, 2009 1:32 AM To: Maven Users List Subject: Re: RE: nexus can't find maven-archetype-plugin? well, here's my settings.xml- couldn't send it earlier. I'm just using the standard repositories which are configured in nexus. Original-Nachricht > Datum: Thu, 29 Jan 2009 15:16:04 -0500 > Von: "Brian E. Fox" > An: "Maven Users List" > Betreff: RE: nexus can\'t find maven-archetype-plugin? > Little hard to diagnose with that info. How is your settings.xml setup? > What repos are in your group? What exactly is maven saying (log)? > > We have a nexus user list where your questions will be noticed quicker: > http://nexus.sonatype.org/dev/mailing-lists.html > > -Original Message- > From: Jens Rapp [mailto:tec_la...@gmx.de] > Sent: Wednesday, January 28, 2009 4:17 AM > To: users@maven.apache.org > Subject: nexus can't find maven-archetype-plugin? > > hi, > i'm playing around with nexus as repository manager and now have a > little > problem: the maven-archetype-plugin can't be found. most of the other > plugins work maven uses the standard public repository group in nexus. > what do i have to do for being able to use em all??? > > -- > Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: > http://www.gmx.net/de/go/multimessenger > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Archiva and Maven 2.0.9, defect POM
Thanks, but migrating the tooling is not a solution strategy for us. Any ideas to solve that issue? Thanks !!! > We had similar issues with archiva. These type of issues were resolved > when we went to http://nexus.sonatype.org/ > > -Original Message- > From: Michael Hüttermann [mailto:mich...@huettermann.net] > Sent: Monday, February 02, 2009 11:45 AM > To: users@maven.apache.org > Subject: Archiva and Maven 2.0.9, defect POM > > Hello, > > I use Maven 2.0.9 and Archiva 1.1.1. > In my environment the central proxy repository Archiva has a defect entry > for \internal\org\apache\maven\maven\2.0.9. After some manual and > suboptimal work there only dummy data garbage is existing in that folder. > Actually after installing Archiva the folder was not existing at all. > > OK, now I have issues with that defect entries for 2.0.9, and I removed > the whole folder \internal\org\apache\maven\maven\2.0.9 from disc. I'm not > sure how wise this was, but if I trigger a "mvn install" or if I browse > Archiva via web interface, I still get and see the old and corrupt 2.0.9 > version. > > So the question is, how can I refresh Archiva that it will deliver the > right 2.0.9 version for me? The correct version I see under > http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.9/ ? > > Thank you for your time!!! > > Best regards > Michael > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Archiva and Maven 2.0.9, defect POM
We had similar issues with archiva. These type of issues were resolved when we went to http://nexus.sonatype.org/ -Original Message- From: Michael Hüttermann [mailto:mich...@huettermann.net] Sent: Monday, February 02, 2009 11:45 AM To: users@maven.apache.org Subject: Archiva and Maven 2.0.9, defect POM Hello, I use Maven 2.0.9 and Archiva 1.1.1. In my environment the central proxy repository Archiva has a defect entry for \internal\org\apache\maven\maven\2.0.9. After some manual and suboptimal work there only dummy data garbage is existing in that folder. Actually after installing Archiva the folder was not existing at all. OK, now I have issues with that defect entries for 2.0.9, and I removed the whole folder \internal\org\apache\maven\maven\2.0.9 from disc. I'm not sure how wise this was, but if I trigger a "mvn install" or if I browse Archiva via web interface, I still get and see the old and corrupt 2.0.9 version. So the question is, how can I refresh Archiva that it will deliver the right 2.0.9 version for me? The correct version I see under http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.9/ ? Thank you for your time!!! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: OSGi and MEF (.NET) comparision?
They do update the spec: http://www.osgi.org/Specifications/HomePage Maybe someone in the working groups is keeping an eye on the competition: http://www.osgi.org/WG/HomePage Mark Derricutt wrote: 'lo all, Earlier today I was listening to the latest Hanselminutes podcast [1] with Glenn block about the .NET Managed Extensibility Framework (MEF) [2] and found that it sounds fairly similar to OSGi over on the Java side (thou I suspect OSGi has more power). Has anyone here had any experience with MEF to know how the compare (sans VM differences) - does MEF have any neat features that OSGi could do with 'borrowing'? [1] http://www.hanselminutes.com/default.aspx?showID=166 [2] http://www.codeplex.com/MEF ...and then Buffy staked Edward. The End. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Archiva and Maven 2.0.9, defect POM
Hello, I use Maven 2.0.9 and Archiva 1.1.1. In my environment the central proxy repository Archiva has a defect entry for \internal\org\apache\maven\maven\2.0.9. After some manual and suboptimal work there only dummy data garbage is existing in that folder. Actually after installing Archiva the folder was not existing at all. OK, now I have issues with that defect entries for 2.0.9, and I removed the whole folder \internal\org\apache\maven\maven\2.0.9 from disc. I'm not sure how wise this was, but if I trigger a "mvn install" or if I browse Archiva via web interface, I still get and see the old and corrupt 2.0.9 version. So the question is, how can I refresh Archiva that it will deliver the right 2.0.9 version for me? The correct version I see under http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.9/ ? Thank you for your time!!! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven deploy project on a server different from remote repo server
Hi all, Here is the situation. Our internal remote repository is on server1 and my application that will require some of the jars sitting on the remote repo is on server2. Now my application is in jar format (created using maven) and is used by a web coldfusion based application. Now, do I simply figure out which dependencies my app requires and manually put them somewhere on server2 and use the classpath way of doing things to run this app or is there a better way to do this using Maven? I have been using Maven for a few months now and I understand how it works but I am not sure what to do in this deployment scenario that I mentioned above Any insights will be appreciated. Thank you Shahzad Qureshi Systems Analyst/Programmer Applications Directorate, CIOB Environment Canada shahzad.qure...@ec.gc.ca
[mule-user] Environment dependant and independent modules question
Hi, I have a couple best practices questions. My project setup is a parent with two modules, I'll call them core and container. The core module has all the core logic. The container module depends on it and packages everything up via the assembly plugin for distribution. The core is environment-independent, no property filters, and the container module is environment dependent with properties files filtered for environment specific things (install directory, db connections, ports, etc.). Now I throw in an applicationContext.xml for Spring with many of beans dependant on environment specific database information. Since the Application Context is specific and really required by the core logic, I would first think that the file belongs in my core module, but that then breaks the environment-independent aspect of the core, so maybe the container module would be better? On the other hand, my database-related beans and the related Application Context definitions might be better served living in a third "datbase" module. I could then keep the core entity classes environment-independent and have the new module depend on the core. Second question: In my container module, I reproduce many of the dependencies found in the core module scoped at runtime so that they can be included in my assembly. To avoid this duplication, would it may be better to have the core module produce a jar-with-dependenices and have only that be part of the assembly? What would be the best or recommended practice here? Whew.. Thanks for any thoughts and insights in advance.
Re: pde build with maven
Hi, my recomendation for rcp build with maven is "tycho" maven: e.g. http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview But you must be ready the project configuration with tycho differs often from "normal" Maven one. Gruß, Konstantin --- > Hi, i want to setup my rcp project with a maven build. so first i want > to build succesfully the example from the pde-maven-plugin site. > > i started by downloading the following eclipse sdk and delta pack: > - eclipse-3.4.1-delta-pack.zip > - eclipse-RCP-SDK-3.4.1-win32.zip > > i read through the examples from pde-maven-plugin mojo and found a > tutorial that builds a product. > > this tutorial can be found here: > http://snapshots.repository.codehaus.org/org/codehaus/mojo/pde-maven-p lugin/ > > i downloaded this one: > pde-maven-plugin-1.0-20080304.235354-2-tutorials.zip (if you want an > SSCCE (http://pscode.org/sscce.html)) > > after i imported the project to my eclipse ide i have done som changes > to build.properties and pom.xml to ensure the paths are well formed. > (the name of the plugin is: test.pde_maven_plugin.simple_application) > > now i tried the pde build to be sure its running without maven: > > 1) launch the application (SUCCESSFUL) > 2) launch the product (SUCCESSFUL) > 3) export as product and launch (SUCCESSFUL) > > everything works fine! now i tried to do the maven install, but this failed: > > BUILD FAILED > D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v2008 0604\scripts\productBuild\productBuild.xml:25: > The following error occurred while executing this line: > D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v2008 0604\scripts\productBuild\productBuild.xml:53: > Unable to find plug-in: test.pde_maven_plugin.simple_application. Please > check the error log for more details. > > as you can see, the pde build (i think) can't found the application i > want to export, it seems that maven doesn't calls the pde build for the > application first, it assumes that the plugin has already be there? if i > change the maven packaging to jar, do the install, copy this jar to my > target.env into plugins change packaging back to zip, do the install > again. everything runs fine, but this isn't a great solutions or? in my > pov i think this should be done by pde build? please correct me if i am > wrong if you need more informartions just let me know -- or if you got > time have a look inside the maven-pde-plugin tutorial. > > thank you > chris > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven for the internet afraid
Could you clarify the security requirement? It sounds like you don't want
unverified jars entering the development space. Is this correct?
We have simple production builds (no site, no reports). My maven1 cert
repository has 210 jar files, 150 of them are external. How are you going to
validate this many files? This is a lot of effort just to support a build
process. I like maven, but perhaps Ant would be simpler?
-C. Helck
-Original Message-
From: Merv Green [mailto:paradeofh...@gmail.com]
Sent: Sunday, February 01, 2009 5:18 PM
To: Maven Users List
Subject: Re: Maven for the internet afraid
We envision a process where we periodically reevaluate our needs, gathering all
artifacts we'll use until the next assessment.
In summary, that is simply impractical; we need a different approach.
Saying that at work lately, I've felt like Cassandra, but I'll be glad to admit
if I'm wrong...
Tamás Cservenák wrote:
> I have to agree with Brian: letting developers use the proxy repo, but
> CI/Releases the procured repo (which pulls its content from same proxy
> repo that devs uses, but "bureaucratic" rules are applied). This IS a
> supported scenario.
>
> But, as with many things in our lives, you can play "Unnatural Acts"
> (sic!) with Nexus too...
>
> You could even procure a procured repository ("waterfall" procurement?
> ;)
>
> Set up "central" repo as proxy for central.
> Set up a procured-light repo, as procured for devs (with "light" rule
> management applied) using central as target.
> Set up a "devs" group and put procured-devs repo into it (and possibly
> any other "secure" reposes) Set up a procured-strong repo, as procured
> for CI/Release (with "bureaucratic" rule management applied) using
> "devs" group as target.
> ...and so on.
>
> That's it. But it would require a lot of beers to explain me why would
> you do it :)
>
> Thanks for appreciating Nexus!
> ~t~
>
> [1] fav TV series, followed by cultic Mighty Boosh
>
> On Sun, Feb 1, 2009 at 8:19 PM, Brian E. Fox wrote:
>
>> I don't see how you can have both an ask-first approach and not some
>> business process to handle it. The recommended setup we like to see is to
>> let developers have access to the repos, but keep the official builds behind
>> the Nexus Procurement repo so that you are sure what is officially built.
>> It's the best of both worlds. If they really insist on being 100% offline,
>> then you are stuck with a completely manual process that will be
>> bureaucratic regardless of the existence of a tool or not. It simply isn't
>> practical to try and pull down all 80gb of central and every other repo you
>> might ever want and then hide in a corner hoping you never need something
>> more. It has to be a balanced approach.
>>
>> -Original Message-
>> From: Merv Green [mailto:paradeofh...@gmail.com]
>> Sent: Sunday, February 01, 2009 2:14 PM
>> To: Maven Users List
>> Subject: Re: Maven for the internet afraid
>>
>> I need to clarify my question.
>>
>> The security people at my company certainly want the finest-grained
>> control possible over artifacts, that is, an ask-first model where
>> they approve each individually. I don't question that we can force
>> Maven into this mindset, but whether we can do so without
>> significantly hindering its usefulness.
>>
>> For us, a reactive approach like what Nexus's procurement mechanism
>> assists with will inevitably turn artifact approval into an agonizing
>> bureaucratic process at exactly the wrong times for developers. To
>> ensure that relatively arcane corners of dependency resolution do not
>> hamstring them in the midst of coding frenzies, I need a big-bang
>> approach to front-load the repository. Basically, how can I minimize
>> the pain when someone tries to use an already approved artifact in an
>> unanticipated configuration?
>>
>> Incidentally, I have been happily experimenting with Nexus for a
>> little while now. Good work.
>>
>>> In short, two handy URLs:
>>> http://books.sonatype.com/nexus-book/reference/procure.html
>>> http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-
>>> procurement/
>>>
>>>
>>> Hope helps,
>>> ~t~
>>>
>>>
>>> On Sat, Jan 31, 2009 at 9:36 PM, Merv Green wrote:
>>>
>>>
>>>
So, in my quest to take Maven completely internal, I'm still
grappling with a couple of use cases:
1. Gathering plugin dependencies
We have some list of approved plugins we somehow decide we need.
For each, we want to populate our repo with any artifacts those
plugins might require in use.
During the approval process we create dummy projects to exercise
each plugin, then we build those projects against a proxy repo and
declare whatever landed in the proxy kosher. That step rubs me
wrong because I feel like Maven is resolving plugin dependencies
based on the plugin's configuration for a particular project, and
we'll eas
5 minute guide - Incorrect documentation/documentation improvement?
Hi all, I recently gave a talk on Maven to the Java London Users group. One small thing I noticed while researching is that the instructions at: http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html talk about using mvn archetype:create Since that is now deprecated in favour of archetype:generate, should the documentation be updated to use the non deprecated project creation method? Cheers, Martijn - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Oddness with release:prepare
This is with maven 2.0.9 on Solaris 10 with Java 1.6.0_11 I have a project laid out thusly: myproject/pom.xml myproject/myproject-pom/pom.xml myproject/myproject-api/pom.xml myproject/myproject-common/pom.xml myproject/myproject-console/pom.xml The top-level pom is a minimal parent pom whose only module is myproject/myproject-pom. myproject/myproject-pom/pom.xml exists because Eclipse doesn't like nested projects. So this pom has things that would typically need to be changed. All of the other myproject/myproject-*/pom.xml are modules of myproject/myproject-pom/pom.xml. When I execute 'mvn release:prepare' things go well until it begins invoking subversion. Here is the relevant bit of output from the process: (sorry for the long lines) [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject && svn --non-interactive commit --file /var/tmp/maven-scm-1461319678.commit --targets /var/tmp/maven-scm-7441525038114668907-targets [INFO] Working directory: /export/home/ci/tmp/myproject [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom && svn --non-interactive commit --file /var/tmp/maven-scm-1292675052.commit --targets /var/tmp/maven-scm-6618196211309587095-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-api && svn --non-interactive commit --file /var/tmp/maven-scm-1794995489.commit --targets /var/tmp/maven-scm-2050429634740604341-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-api [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-common && svn --non-interactive commit --file /var/tmp/maven-scm-786958246.commit --targets /var/tmp/maven-scm-636982206221127-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-common [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-console && svn --non-interactive commit --file /var/tmp/maven-scm-637551884.commit --targets /var/tmp/maven-scm-3757207476498104603-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-console [INFO] Tagging release with the label myproject-1.0... [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject && svn --non-interactive copy --file /var/tmp/maven-scm-1862162340.commit . http://my-svn-server:/svn/myrepo/myprojects/tags/myproject-1.0 [INFO] Working directory: /export/home/ci/tmp/myproject [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Commit failed (details follow): svn: File '/svn/myrepo/myprojects/tags/myproject-1.0/myproject-common/pom.xml' already exists After investigating a while and trying to reproduce the process manually, I discovered that the error message is somewhat misleading. If I do an 'svn update' prior to the 'svn copy' then the process completes successfully. I put a shell script named 'svn' in my path in front of /usr/local/bin and had that script do an 'svn update' when it sees an 'svn copy' request. Invoking 'mvn release:prepare' with that in place will succeed. Has anybody else seen this kind of behavior? Is there a better solution than my hack of a workaround: $ cat ~/bin/svn #!/bin/bash echo "$@" > ~/svn.log if [ "$1" = "--non-interactive" -a "$2" = "copy" -a "$3" = "--file" ] then /usr/local/bin/svn update fi exec /usr/local/bin/svn "$@" - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
pde build with maven
Hi, i want to setup my rcp project with a maven build. so first i want to build succesfully the example from the pde-maven-plugin site. i started by downloading the following eclipse sdk and delta pack: - eclipse-3.4.1-delta-pack.zip - eclipse-RCP-SDK-3.4.1-win32.zip i read through the examples from pde-maven-plugin mojo and found a tutorial that builds a product. this tutorial can be found here: http://snapshots.repository.codehaus.org/org/codehaus/mojo/pde-maven-plugin/ i downloaded this one: pde-maven-plugin-1.0-20080304.235354-2-tutorials.zip (if you want an SSCCE (http://pscode.org/sscce.html)) after i imported the project to my eclipse ide i have done som changes to build.properties and pom.xml to ensure the paths are well formed. (the name of the plugin is: test.pde_maven_plugin.simple_application) now i tried the pde build to be sure its running without maven: 1) launch the application (SUCCESSFUL) 2) launch the product (SUCCESSFUL) 3) export as product and launch (SUCCESSFUL) everything works fine! now i tried to do the maven install, but this failed: BUILD FAILED D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v20080604\scripts\productBuild\productBuild.xml:25: The following error occurred while executing this line: D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v20080604\scripts\productBuild\productBuild.xml:53: Unable to find plug-in: test.pde_maven_plugin.simple_application. Please check the error log for more details. as you can see, the pde build (i think) can't found the application i want to export, it seems that maven doesn't calls the pde build for the application first, it assumes that the plugin has already be there? if i change the maven packaging to jar, do the install, copy this jar to my target.env into plugins change packaging back to zip, do the install again. everything runs fine, but this isn't a great solutions or? in my pov i think this should be done by pde build? please correct me if i am wrong if you need more informartions just let me know -- or if you got time have a look inside the maven-pde-plugin tutorial. thank you chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
