Re: Repository 'central' will be blacklisted
proxies !-- proxy ... /proxy -- /proxies If this is literally the content of your file, then you should realize that you've commented out the new proxy that you defined in the XML with the XML comment tags !-- ... --. Please open this file in an XML-editor so you can fix it, or learn XML and adjust the comment tags as you deem necessary. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to compile and run Java class
Hi,
I have created a a simple java class inside the folder
D:/Project/src/com.
package com;
public class HelloWorld {
public static void main(String[] args) {
System.out.println(Hello World);
}
}
I would like to compile this java file and place the .class file in to
ther folder D:/Project/build/classes/ and then how to run this .class file
from command line. I am new to Maven, please help me out. I have downloaded
Maven 2.1.0. Please provide the step by step procedure.
Thanks in advance,
--
View this message in context:
http://www.nabble.com/How-to-compile-and-run-Java-class-tp22799350p22799350.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Config File Consistency
dependency:unpack??? 2009/3/30 dutchman...@charter.net Jeff: If it was a single file (ie. CheckStyle) I would have most likely gone down the URL route. However, I have multiple configuration files (CheckStyle, PMD, FindBugs, testing, etc) so I would like it all as single dependency. If I go down the *.jar route, it works for CheckStyle but does not seem to work for other plug-ins. That is why I was looking for a solution that would allow a *.jar file to be pulled from a repository and explode to a defined directory. All of the plug-ins have an option to point to a given directory for configuration files. I can do it through the Ant plug-in (unzip) but I was trying to find a pure Maven solution first. Perry Hoekstra Jeff Jensen jeffjen...@upstairstechnology.com wrote: Hi Perry, Typically, I have used the configuration options of the tool, such as specifying the config file via a URL with Checkstyle. I have also bundled them together a separate project, deployed that jar, and made it a dependency of the projects. This works when the respective tool can can load the config file via the classpath. HTH On Mon, 30 Mar 2009 10:55:09 -0400 dutchman...@charter.net wrote: Hello all: I am working in a Maven multi-project environment and I would like to maintain some consistency across projects for some tools like CheckStyle, FindBugs, etc. In order to do this, I am thinking of using the remote resource plugin. However, the documentation states that the files from the resource bundle is deposited in the $basedir/target/classes directory. However, I would like it deposited in the $basedir/some_arbitrary_location directory? Can I configure the directory where the files are deposited or am I off in the weeds and there is an easier way? Thank you, Perry Hoekstra - 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: How to compile and run Java class
Hi,
Hi,
I have created a a simple java class inside the folder
D:/Project/src/com.
package com;
public class HelloWorld {
public static void main(String[] args) {
System.out.println(Hello World);
}
}
I would like to compile this java file and place the .class file in to
ther folder D:/Project/build/classes/ and then how to run this .class file
from command line. I am new to Maven, please help me out. I have downloaded
Maven 2.1.0. Please provide the step by step procedure.
Have a look at http://www.sonatype.com/books/maven-book/reference/ for a
general tutorial , to run your application you will need to use the
'maven-exec-plugin'.Changing the default build output folder
(target/classes) is possible but personally I don't recommend doing so
(last time I tried I had some weird issues with plugins that obviously
still searched the default path).
Regards,
Tobias
Thanks in advance,
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Config File Consistency
Hi there. I don't seem to get exactly what you want to accomplish, but it sounds like this is what you want to do: http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html You can download a specific artifact from a repository and unpack it to a certain directory during the prepare-source phase. Regards Am 30.03.2009 um 18:58 schrieb dutchman...@charter.net dutchman...@charter.net : Jeff: If it was a single file (ie. CheckStyle) I would have most likely gone down the URL route. However, I have multiple configuration files (CheckStyle, PMD, FindBugs, testing, etc) so I would like it all as single dependency. If I go down the *.jar route, it works for CheckStyle but does not seem to work for other plug-ins. That is why I was looking for a solution that would allow a *.jar file to be pulled from a repository and explode to a defined directory. All of the plug-ins have an option to point to a given directory for configuration files. I can do it through the Ant plug-in (unzip) but I was trying to find a pure Maven solution first. Perry Hoekstra Jeff Jensen jeffjen...@upstairstechnology.com wrote: Hi Perry, Typically, I have used the configuration options of the tool, such as specifying the config file via a URL with Checkstyle. I have also bundled them together a separate project, deployed that jar, and made it a dependency of the projects. This works when the respective tool can can load the config file via the classpath. HTH On Mon, 30 Mar 2009 10:55:09 -0400 dutchman...@charter.net wrote: Hello all: I am working in a Maven multi-project environment and I would like to maintain some consistency across projects for some tools like CheckStyle, FindBugs, etc. In order to do this, I am thinking of using the remote resource plugin. However, the documentation states that the files from the resource bundle is deposited in the $basedir/target/classes directory. However, I would like it deposited in the $basedir/some_arbitrary_location directory? Can I configure the directory where the files are deposited or am I off in the weeds and there is an easier way? Thank you, Perry Hoekstra - 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: Repository 'central' will be blacklisted
Hi, I am following the steps given in the URL http://www.ensode.net/maven_intro.html HERE to compile and run my java class When I run the command, mvn archetype:create -DgroupId=maven-test -DartifactId=maven-test -DpackageName=net.ensode.maventest I am getting, === D:\178010\Softwares\Apache-Maven-Installedmvn -X archetype:create -DgroupId=mav en-test -DartifactId=maven-test -DpackageName=net.ensode.maventest + Error stacktraces are turned on. Apache Maven 2.1.0 (r755702; 2009-03-19 00:40:27+0530) Java version: 1.6.0_06 Java home: D:\178010\JDK 6U6\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settin gs\178010\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'D:\178010\Softwares\A pache-Maven-Installed\apache-maven-2.1.0\bin\..\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [INFO] org.apache.maven.plugins: checking for updates from central [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: 'http://repo1.maven.org/ma ven2'. [DEBUG] Using Proxy: proxy.mycompany.com [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo [INFO] org.codehaus.mojo: checking for updates from central [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: 'http://repo1.maven.org/ma ven2'. [DEBUG] Using Proxy: proxy.mycompany.com [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for up dates from central [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: 'http://repo1.maven.org/ma ven2'. [DEBUG] Using Proxy: proxy.mycompany.com [DEBUG] maven-archetype-plugin: resolved to version 2.0-alpha-4 from repository central [DEBUG] Trying repository central [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: 'http://repo1.maven.org/ma ven2'. [DEBUG] Using Proxy: proxy.mycompany.com Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archet ype-plugin/2.0-alpha-4/maven-archetype-plugin-2.0-alpha-4.pom [DEBUG] attempting to create parent directories for destination: maven-archetype -plugin-2.0-alpha-4.pom.tmp 4K downloaded (maven-archetype-plugin-2.0-alpha-4.pom) [DEBUG] Artifact resolved [DEBUG] Retrieving parent-POM: org.apache.maven.archetype:maven-archetype:pom:2. 0-alpha-4 for project: org.apache.maven.plugins:maven-archetype-plugin:maven-plu gin:null from the repository. [DEBUG] Trying repository central [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: 'http://repo1.maven.org/ma ven2'. [DEBUG] Using Proxy: proxy.mycompany.com Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-arch etype/2.0-alpha-4/maven-archetype-2.0-alpha-4.pom [DEBUG] attempting to create parent directories for destination: maven-archetype -2.0-alpha-4.pom.tmp 13K downloaded (maven-archetype-2.0-alpha-4.pom) [DEBUG] Artifact resolved [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for project: org.apache.maven.archetype:maven-archetype:pom:2.0-alpha-4 from the repository. [DEBUG] Trying repository central [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: 'http://repo1.maven.org/ma ven2'. [DEBUG] Using Proxy: proxy.mycompany.com Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/9/maven -parent-9.pom [DEBUG] attempting to create parent directories for destination: maven-parent-9. pom.tmp 32K downloaded (maven-parent-9.pom) [DEBUG] Artifact resolved [DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project: org.apache.m aven:maven-parent:pom:9 from the repository. [DEBUG] Trying repository central [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: 'http://repo1.maven.org/ma ven2'. [DEBUG] Using Proxy: proxy.mycompany.com Downloading: http://repo1.maven.org/maven2/org/apache/apache/4/apache-4.pom [DEBUG] attempting to create parent directories for destination: apache-4.pom.tm p 4K downloaded (apache-4.pom) [DEBUG] Artifact resolved [DEBUG] Adding managed dependencies for org.apache.maven.plugins:maven-archetype -plugin
Re: The skin does not exist: Unable to determine the release version
Hi Jerry, the bad news are that I had the same problem - the good news are that I was able to get rid of the problem E.g. run mvn -U site to force an update of your repo - thanks to Wendy Smoak helping me with this issue ... Cheers, Siegfried Goeschl Jerry Thome wrote: Sorry if I missed this as a recent posting. Last night, several of my Maven projects running in Hudson starting to fail with the same error message. Does the recent site plug-in release have anything to do with this? It's becoming problematic to delete files in a repo and have maven auto-download them, which seems to fix this problem. Thanks. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] The skin does not exist: Unable to determine the release version Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.apache.maven.skins:maven-default-skin:jar:RELEASE The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Config File Consistency
Yes, after a great deal of paddling around, I ran into dependency:unpack and that is what I ended up using. Perry Hoekstra Stephen Connolly wrote: dependency:unpack??? 2009/3/30 dutchman...@charter.net Jeff: If it was a single file (ie. CheckStyle) I would have most likely gone down the URL route. However, I have multiple configuration files (CheckStyle, PMD, FindBugs, testing, etc) so I would like it all as single dependency. If I go down the *.jar route, it works for CheckStyle but does not seem to work for other plug-ins. That is why I was looking for a solution that would allow a *.jar file to be pulled from a repository and explode to a defined directory. All of the plug-ins have an option to point to a given directory for configuration files. I can do it through the Ant plug-in (unzip) but I was trying to find a pure Maven solution first. Perry Hoekstra Jeff Jensen jeffjen...@upstairstechnology.com wrote: Hi Perry, Typically, I have used the configuration options of the tool, such as specifying the config file via a URL with Checkstyle. I have also bundled them together a separate project, deployed that jar, and made it a dependency of the projects. This works when the respective tool can can load the config file via the classpath. HTH On Mon, 30 Mar 2009 10:55:09 -0400 dutchman...@charter.net wrote: Hello all: I am working in a Maven multi-project environment and I would like to maintain some consistency across projects for some tools like CheckStyle, FindBugs, etc. In order to do this, I am thinking of using the remote resource plugin. However, the documentation states that the files from the resource bundle is deposited in the $basedir/target/classes directory. However, I would like it deposited in the $basedir/some_arbitrary_location directory? Can I configure the directory where the files are deposited or am I off in the weeds and there is an easier way? Thank you, Perry Hoekstra - 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: The plugin 'org.apache.maven.plugins:maven-aar-plugin' does not exist
That plugin doesn't exist on apache, so the error is correct. -Original Message- From: Azazel Se [mailto:azazel...@hotmail.com] Sent: Monday, March 30, 2009 10:37 PM To: users@maven.apache.org Subject: The plugin 'org.apache.maven.plugins:maven-aar-plugin' does not exist Hi. I cannot get the service archiver plugin to work (AAR). mvn aar:aar gives this result: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'aar'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-aar-plugin' does not exist or no valid version could be found and with mvn -U aar:aar it says it is checking for updates from central but fails also. I've tried mvn org.aparche.axis2-aar-maven-plugin:aar as well but with same result. When I tried changing the version number in the pom.xml file and tried the command again it seemed to start downloading but failed again. Any suggestions as to what is wrong? -Az. _ Dobbelt så moro - del bilder med andre mens du chatter på Windows Live Messenger. http://www.microsoft.com/windows/windowslive/products/messenger.aspx - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate Module/Project Names in m2eclipse
On 30-Mar-09, at 9:26 PM, Andrew Hughes wrote: Hi, Eclipse can't seem to handle two modules in the same workspace that have the same artifactId. For example if I have a multi-module project (groupId:artifact) as below: - carworld:carworld - carworld:ferrari - carworld.ferrari:car - carworld:porsche - carworld.porsche:car There are two modules that have artifactIdcar/artifactId (but different groupId's). m2Eclipse+Eclipse appears to use the artifactId as the project identifier and when the two car projects are imported only one is actually imported. Is this a known issue? are there any workarounds? Give your projects different names. We're not going to support duplicate artifactIds in the reactor. You can't have two artifacts with the same coordinate and expect it to work. Name your projects properly. Cheers. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sharing Maven-based project
Please correct me if I'm wrong: 1. I have to install Nexus (my choice) on the dev machine (shared server). 2. I will use Nexus to copy my local MVN repository to the dev machine. Thanks for help , I'm so newbie with Maven. Cedros GmbH wrote: Yes, create a repository for your unit/company. You don't want to let your colleagues download artifacs manually from eg. SVN. We use Artifactoy as a repository and central mirror for every maven installation in the company. Its running on Tomcat, easy to install and integrated with the company LDAP. Regards Am 29.03.2009 um 16:08 schrieb HHB: Hey, I use Maven as the build tool for our project. Now my team mates want to checkout the project from the SVN and I want to add the project to out continuous integration server (Hudson). I'm not sure but should I create a central repository in our unit? or let each mate (and CI server) download the dependency himself? What repository manager do you suggest? Thanks. -- View this message in context: http://www.nabble.com/Sharing-Maven-based-project-tp22767986p22767986.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://www.nabble.com/Sharing-Maven-based-project-tp22767986p22804979.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sharing Maven-based project
On Tue, Mar 31, 2009 at 10:56 AM, HHB hubaghd...@yahoo.ca wrote: Please correct me if I'm wrong: 1. I have to install Nexus (my choice) on the dev machine (shared server). 2. I will use Nexus to copy my local MVN repository to the dev machine. Thanks for help , I'm so newbie with Maven. Yes, although if all your project dependencies are in the Maven central repository, there may be some value in waiting on Nexus (or one of the other repo managers, although I like Nexus) 'til you're ready. If you've already got several dependencies in your local repo that can't be found on central, then it's probably simpler to set up Nexus than it is to move dependencies around between developers, yes. - Geoffrey -- Geoffrey Wiseman http://www.geoffreywiseman.ca/
Re: The skin does not exist: Unable to determine the release version
That fixed it. I'll be sure to do that first in the future. Thank you. Siegfried Goeschl siegfried.goes...@it20one.at 03/31/2009 05:15 AM Please respond to Maven Users List users@maven.apache.org, siegfried.goes...@it20one.at To Maven Users List users@maven.apache.org cc Subject Re: The skin does not exist: Unable to determine the release version Hi Jerry, the bad news are that I had the same problem - the good news are that I was able to get rid of the problem E.g. run mvn -U site to force an update of your repo - thanks to Wendy Smoak helping me with this issue ... Cheers, Siegfried Goeschl Jerry Thome wrote: Sorry if I missed this as a recent posting. Last night, several of my Maven projects running in Hudson starting to fail with the same error message. Does the recent site plug-in release have anything to do with this? It's becoming problematic to delete files in a repo and have maven auto-download them, which seems to fix this problem. Thanks. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] The skin does not exist: Unable to determine the release version Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.apache.maven.skins:maven-default-skin:jar:RELEASE The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Duplicate Module/Project Names in m2eclipse
On Tue, Mar 31, 2009 at 6:56 AM, Jason van Zyl jvan...@sonatype.com wrote: Give your projects different names. We're not going to support duplicate artifactIds in the reactor. You can't have two artifacts with the same coordinate and expect it to work. Name your projects properly. That's a very narrow-minded view. While best practice suggests to have some project identifier as part of the artifact id (e.g. tapestry-ioc, maven-compiler-plugin) it's quite possible that two completely separate projects would arrive at the same artifact id. The point of group id and version together with the artifactid is to uniquely identify the artifact, is it not? So using just the artifact id in Eclipse to differentiate between the project is a limitation. It's not just a problem with just weakly named artifacts - for example try working on multiple branches at the same time and importing them to the same workspace (I often rename the projects in Eclipse first; you could try that Andrew). If m2eclipse would just use groupId:artifactId:version as the Eclipse project name what difference would it make? I mean, Jason what's the reason to oppose it so strongly? Hopefully nestable projects in Eclipse would solve this properly somewhere around 4.x. Kalle
RE: Duplicate Module/Project Names in m2eclipse
I think m2e does allow you to create a project with the groupId as part of the project name. If you open the Advanded dialog during an import you will see a name template. --- Todd Thiessen -Original Message- From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] Sent: Tuesday, March 31, 2009 1:55 PM To: Maven Users List Subject: Re: Duplicate Module/Project Names in m2eclipse On Tue, Mar 31, 2009 at 6:56 AM, Jason van Zyl jvan...@sonatype.com wrote: Give your projects different names. We're not going to support duplicate artifactIds in the reactor. You can't have two artifacts with the same coordinate and expect it to work. Name your projects properly. That's a very narrow-minded view. While best practice suggests to have some project identifier as part of the artifact id (e.g. tapestry-ioc, maven-compiler-plugin) it's quite possible that two completely separate projects would arrive at the same artifact id. The point of group id and version together with the artifactid is to uniquely identify the artifact, is it not? So using just the artifact id in Eclipse to differentiate between the project is a limitation. It's not just a problem with just weakly named artifacts - for example try working on multiple branches at the same time and importing them to the same workspace (I often rename the projects in Eclipse first; you could try that Andrew). If m2eclipse would just use groupId:artifactId:version as the Eclipse project name what difference would it make? I mean, Jason what's the reason to oppose it so strongly? Hopefully nestable projects in Eclipse would solve this properly somewhere around 4.x. Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Duplicate Module/Project Names in m2eclipse
When you import, you can select a naming template and one of them includes the group. This is also handy if you happen to have multiple branches imported at the same time, since one of the other options includes the version. -Original Message- From: Andrew Hughes [mailto:ahhug...@gmail.com] Sent: Tuesday, March 31, 2009 12:26 AM To: Maven Users List Subject: Duplicate Module/Project Names in m2eclipse Hi, Eclipse can't seem to handle two modules in the same workspace that have the same artifactId. For example if I have a multi-module project (groupId:artifact) as below: - carworld:carworld - carworld:ferrari - carworld.ferrari:car - carworld:porsche - carworld.porsche:car There are two modules that have artifactIdcar/artifactId (but different groupId's). m2Eclipse+Eclipse appears to use the artifactId as the project identifier and when the two car projects are imported only one is actually imported. Is this a known issue? are there any workarounds? Cheers. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Sharing Maven-based project
Yes, although if all your project dependencies are in the Maven central repository, there may be some value in waiting on Nexus (or one of the other repo managers, although I like Nexus) 'til you're ready. If you've already got several dependencies in your local repo that can't be found on central, then it's probably simpler to set up Nexus than it is to move dependencies around between developers, yes. Don't forget about the improved build performance that will come with the proxies you get with a repo manager. I wouldn't say that you don't need one until you actually need to share artifacts (which would happen as soon as you actually start building and releasing anyway). I would say that as soon as you have more than one developer in a given location, you should consider a repo manager if only to proxy builds and protect yourself from transient network outages. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate Module/Project Names in m2eclipse
Thanks, good to know. All the more reason to switch from q4e to m2e once the incremental compiler becomes available! Kalle On Tue, Mar 31, 2009 at 11:03 AM, Brian E. Fox bri...@reply.infinity.nuwrote: When you import, you can select a naming template and one of them includes the group. This is also handy if you happen to have multiple branches imported at the same time, since one of the other options includes the version. -Original Message- From: Andrew Hughes [mailto:ahhug...@gmail.com] Sent: Tuesday, March 31, 2009 12:26 AM To: Maven Users List Subject: Duplicate Module/Project Names in m2eclipse Hi, Eclipse can't seem to handle two modules in the same workspace that have the same artifactId. For example if I have a multi-module project (groupId:artifact) as below: - carworld:carworld - carworld:ferrari - carworld.ferrari:car - carworld:porsche - carworld.porsche:car There are two modules that have artifactIdcar/artifactId (but different groupId's). m2Eclipse+Eclipse appears to use the artifactId as the project identifier and when the two car projects are imported only one is actually imported. Is this a known issue? are there any workarounds? Cheers. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sharing Maven-based project
On Tue, Mar 31, 2009 at 2:07 PM, Brian E. Fox bri...@reply.infinity.nuwrote: Don't forget about the improved build performance that will come with the proxies you get with a repo manager. I wouldn't say that you don't need one until you actually need to share artifacts (which would happen as soon as you actually start building and releasing anyway). I would say that as soon as you have more than one developer in a given location, you should consider a repo manager if only to proxy builds and protect yourself from transient network outages. I'd agree that if you're comfortable with Maven, that's a good strategy. If you're not, then I'd probably rather get the team accustomed to Maven before they get into repo managers. It's just one more moving piece. YMMV, of course. - Geoffrey -- Geoffrey Wiseman http://www.geoffreywiseman.ca/
Re: Duplicate Module/Project Names in m2eclipse
Hi,
Hi,
Eclipse can't seem to handle two modules in the same workspace that
have the
same artifactId. For example if I have a multi-module
project (groupId:artifact) as below:
- carworld:carworld
- carworld:ferrari
- carworld.ferrari:car
- carworld:porsche
- carworld.porsche:car
There are two modules that have artifactIdcar/artifactId (but
different
groupId's). m2Eclipse+Eclipse appears to use the artifactId as the
project
identifier and when the two car projects are imported only one is
actually
imported.
Is this a known issue? are there any workarounds?
Give your projects different names.
We're not going to support duplicate artifactIds in the reactor. You
can't have two artifacts with the same coordinate and expect it to work.
Name your projects properly.
I always thought Maven artifacts are uniquely identified by { groupId ,
artifactId , version } - how come two artifacts with same artifact IDs
but *different* group IDs have the same coordinate ?
@op: At work we're using some Perl script magic along with the
maven-eclipse-plugin to automatically generate/update .classpath
/.project files. The plugin has a addGroupIdToProjectName/ option
that might solve your problem (haven't tried it myself but I'm afraid
you would have to disable m2eclipse for the project to make this work).
Changing one of the conflicting projects to use a different artifactId
might be way easier (assuming you don't have released these artifacts to
the public / clients).
Regards,
Tobias
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate Module/Project Names in m2eclipse
On 31-Mar-09, at 10:54 AM, Kalle Korhonen wrote: On Tue, Mar 31, 2009 at 6:56 AM, Jason van Zyl jvan...@sonatype.com wrote: Give your projects different names. We're not going to support duplicate artifactIds in the reactor. You can't have two artifacts with the same coordinate and expect it to work. Name your projects properly. That's a very narrow-minded view. You need a unique coordinate. The system breakdowns pretty fast if you don't have that. Should we adjust the internals of Maven to deal with something that is easily rectified in an individual project. While best practice suggests to have some project identifier as part of the artifact id (e.g. tapestry-ioc, maven-compiler-plugin) it's quite possible that two completely separate projects would arrive at the same artifact id. It appeared from his example it was in the same reactor, and therefore I assumed the same coordinate. As long as there is a unique coordinate Maven is fine. Aside from that having the exact same artifactId also just leads to problems. Try putting them in the same assembly, try to visually identify which one is which in different directories. For the possible aggravation I opt for what will cause the least amount of hassle. The point of group id and version together with the artifactid is to uniquely identify the artifact, is it not? So using just the artifact id in Eclipse to differentiate between the project is a limitation. It's not just a problem with just weakly named artifacts - for example try working on multiple branches at the same time and importing them to the same workspace (I often rename the projects in Eclipse first; you could try that Andrew). If m2eclipse would just use groupId:artifactId:version as the Eclipse project name what difference would it make? I mean, Jason what's the reason to oppose it so strongly? Hopefully nestable projects in Eclipse would solve this properly somewhere around 4.x. Kalle Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- Three may keep a secret if two of them are dead. -- Benjamin Franklin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate Module/Project Names in m2eclipse
On 31-Mar-09, at 11:40 AM, Tobias Gierke wrote:
Hi,
Hi,
Eclipse can't seem to handle two modules in the same workspace
that have the
same artifactId. For example if I have a multi-module
project (groupId:artifact) as below:
- carworld:carworld
- carworld:ferrari
- carworld.ferrari:car
- carworld:porsche
- carworld.porsche:car
There are two modules that have artifactIdcar/artifactId (but
different
groupId's). m2Eclipse+Eclipse appears to use the artifactId as the
project
identifier and when the two car projects are imported only one
is actually
imported.
Is this a known issue? are there any workarounds?
Give your projects different names.
We're not going to support duplicate artifactIds in the reactor.
You can't have two artifacts with the same coordinate and expect it
to work.
Name your projects properly.
I always thought Maven artifacts are uniquely identified by
{ groupId , artifactId , version } - how come two artifacts with
same artifact IDs but *different* group IDs have the same
coordinate ?
The GAV is the coordinate. Beyond that the only rule I generally have
is that an artifact can land in a directory (assembly) which
everything else and not get clobbered, and that you can easily
identify what you are looking at. Having N car-1.0.jar artifacts does
not appear to be something I would want in a system I was trying to
maintain. Be unique at all levels == less aggravating over time.
@op: At work we're using some Perl script magic along with the maven-
eclipse-plugin to automatically generate/update .classpath /.project
files. The plugin has a addGroupIdToProjectName/ option
that might solve your problem (haven't tried it myself but I'm
afraid you would have to disable m2eclipse for the project to make
this work). Changing one of the conflicting projects to use a
different artifactId might be way easier (assuming you don't have
released these artifacts to the public / clients).
Regards,
Tobias
-
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
http://twitter.com/jvanzyl
--
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate Module/Project Names in m2eclipse
Hi,
Give your projects different names.
We're not going to support duplicate artifactIds in the reactor. You
can't have two artifacts with the same coordinate and expect it to
work.
Name your projects properly.
I always thought Maven artifacts are uniquely identified by { groupId
, artifactId , version } - how come two artifacts with same artifact
IDs but *different* group IDs have the same coordinate ?
The GAV is the coordinate. Beyond that the only rule I generally have
is that an artifact can land in a directory (assembly) which
everything else and not get clobbered, and that you can easily
identify what you are looking at. Having N car-1.0.jar artifacts does
not appear to be something I would want in a system I was trying to
maintain. Be unique at all levels == less aggravating over time.
You're right, I didn't think about the deployment issues.
Regards,
Tobias
@op: At work we're using some Perl script magic along with the
maven-eclipse-plugin to automatically generate/update .classpath
/.project files. The plugin has a addGroupIdToProjectName/ option
that might solve your problem (haven't tried it myself but I'm afraid
you would have to disable m2eclipse for the project to make this
work). Changing one of the conflicting projects to use a different
artifactId might be way easier (assuming you don't have released
these artifacts to the public / clients).
Regards,
Tobias
-
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
http://twitter.com/jvanzyl
--
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
-
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: Checktyle report incomplete
John Coleman wrote: Yes that works, many thanks. Are there similar ways to do this for the PMD report and Corbertura? It would be nice if the reporting plugins were more consistent. Yes, check out the Goals link on a plugins site and then follow the link to the goal you want to use. If you see an Expression, then that what you'd use on the command line. If there is no Expression then you use the name of the parameter itself. http://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#includes This is not available for Cobertura though. TIA John -Original Message- From: Dennis Lundberg [mailto:dennisl.apa...@gmail.com] On Behalf Of Dennis Lundberg Sent: 28 March 2009 17:06 To: Maven Users List Subject: Re: Checktyle report incomplete http://maven.apache.org/plugins/maven-checkstyle-plugin/checks tyle-mojo.html#includes You should use this command instead: mvn -Dcheckstyle.includes=**/Named.java compile pre-site checkstyle:checkstyle John Coleman wrote: Hi, When I run the command below I only get checkstyle reports for 2 classes in the project, and the class I have named is missed out. Why isn't the file I have referred to used? Perhaps I cannot put maven properties on the command line, who knows? mvn -Dmaven.checkstyle.includes=**/Named.java compile pre-site checkstyle:checkstyle TIA, John Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments. Eurobase Systems Limited is the main trading company in the Eurobase International Group; registered in England and Wales as company number 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex CM2 0RE, UK. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dennis Lundberg - 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 -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Duplicate Module/Project Names in m2eclipse
On 31-Mar-09, at 11:40 AM, Jason Van Zyn wrote: As long as there is a unique coordinate Maven is fine. Aside from that having the exact same artifactId also just leads to problems. Try putting them in the same assembly, try to visually identify which one is which in different directories. For the possible aggravation I opt for what will cause the least amount of hassle. Ok, I see that -- the fact that groupIds are not included in the artifact file naming pattern means that they cannot serve as a namespace for artifactIds, in the sense of being sufficient to establish uniqueness. That leaves two issues: (1) The need for globally unique artifactIds for things that might end up in the same project. Without the com.mycompany sort of convention, that's hard to do. If I'm including two third party artifacts that happen to share an artifactId, it sounds as though I'm in some trouble. (2) Is Maven consistent about artifactId (plus version) as a unique identifier? Is that documented somewhere? Will I get errors if I try to assemble a war or ear from artifacts that have different groupIds, but the same artifactId, regardless of whether the versions match? -- Bryan This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
Trevor - My organization is facing this exact same concern. We are primarily an application platform / hosted-solution company, meaning we don't shrinkwrap and support multiple versions of our systems - only one version is in production at a time. Of course, multiple branches are undergoing testing in parallel, each with different release timeframes, etc, and normal branch merging / management occurs at the SCM level. Separate systems, however, have their own release schedules. SystemA = Dev team A -War AWar1, depends on AJar1 -War AWar2 -Jar AJar1, depends on SSJar1 SharedStuff - Jar SSJar1 SystemB = Dev team B - Jar Bjar1, depends on SSJar1 - Jar Bjar2, depends on AJar1 **note: cross-system dependency - War Bwar1 - Ear Bear1 etc. Organizationally speaking, we have dev teams responsible for one system. Shared stuff is just that, shared - no particular team as owners / maintainers. Our current solution we're incubating is based around a floating snapshot concept. We use the version current-SNAPSHOT in all our trunk POMs. So far, we like it. I reiterate the fact that we don't really care about version numbers - once a branch goes to production, the previous branch is retired. Period. And we want to keep our systems relatively up-to-date in the in-house code they share. - Our CI server (CruiseControl at present) runs a 30 minute build loop. All projects - jars and wars alike - are mavenized (m2). Souce retrieved is tip/trunk at all times, to ensure trunk integrity. - Our build server runs builds on-demand, and retrieves only promoted source from our SCM. We think of these as release candidate builds, and we create them often. The ant scripting surrounding our mvn invocations basically mimics the release plugin. The scripts run by our build server check out the pom, inserts the CC build number, checks in a pom revision in SCM. The CI build scripting checks back out and re-inserts current- SNAPSHOT into the tip revision when triggered. The result is that whenever CI builds run, they build trunk of everything against trunk (current-SNAPSHOT) builds of all dependencies, creating an early warning system. Whenever build server builds run, the packaging of resultant builds include the latest blessed (promoted) builds of in-house code. If large amounts of time go between RC builds, then that project's dependencies can get out of date so to speak. We're still struggling with that to be honest. I welcome your thoughts. I think this is a discussion that is central to large-scale adoption of maven in the enterprise. If we need to take this off-list I am fine with that as well. -Scott Heaberlin Columbia, SC On Mar 25, 2009, at 3:10 PM, Trevor Harmon wrote: Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Trevor - 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: Dependencies for aggregated projects
I realize that this post is quite old, but I am looking for similar information. What we've experienced is that the aggregator pom does depend on the target build directory and not the local repository. Is there a way to reverse this? In our case, we are using a non-standard code structure (which we cannot modify at this point): ProjectA src java (contains source code) build (target build directory for source code) test java (contains test code) build (target build directory for test code) What happens is when we run a bunch of projects together in an aggregator, some of the target build directories come out incorrect. This means that in some cases where we actually depend on the test code, it is referring to the src/build target directory instead of the test/build directory, which is the one we need. We've found that the only way for us to work around this problem is to remove the problem project from the aggregator and simply ensure it is built ahead of time. However, this solution is less than ideal and we would like to know if there is a possibility to get this behaviour fixed (if anyone else has seen this problem as well) or to specify that the aggregator should look in the local repository instead of the target build directories. Thanks. Elizabeth -- View this message in context: http://www.nabble.com/Dependencies-for-aggregated-projects-tp9317930p22814635.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
building archive with 3rd party libs
I'm using nar to try to build an archive that includes sets of dynamic libraries that I've built for different architectures. How do I configure nar to pull the correct libraries into the archive? Seth - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
archetype:generate prompts
Can an archetype prompt for additional properties?For example if I have a dependency on junit but would like the user to specify the version of it that they want when creating a template project off an archetype. Is that possible? -- Rodney Dangerfield - I haven't spoken to my wife in years. I didn't want to interrupt her.
Re: archetype:generate prompts
Sry I just answered my own question. http://maven.apache.org/plugins/maven-archetype-plugin/examples/create-with-property-file.html On Tue, Mar 31, 2009 at 6:02 PM, Tim che...@gmail.com wrote: Can an archetype prompt for additional properties?For example if I have a dependency on junit but would like the user to specify the version of it that they want when creating a template project off an archetype. Is that possible? -- Rodney Dangerfield - I haven't spoken to my wife in years. I didn't want to interrupt her. -- Fran Lebowitz - Life is something to do when you can't get to sleep.
Update maven-metadata.xml
Hello all, I have two questions surrounding maven-metadata.xml files. I have a need to regenerate a bunch of maven-metadata.xml files. I was wondering if there where any tools or mojo's that might be able to help me do this. Needing to do this was caused by... I also have a problem with using deploy:deploy-file. It seems to just create a brand new maven-metadata.xml file regardless of if the file has contents or not. Does anyone know how to make it stop doing that? I have checked the documentation here: http://maven.apache.org/plugins/maven-deploy-plugin/index.html I did some googling around and found some comments regarding this but nothing definitive. FWIW, I am using Maven 2.1.0 for all of this, on Windows. Thanks! -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Update maven-metadata.xml
On 01/04/2009, at 12:16 PM, Jim McCaskey wrote: Hello all, I have two questions surrounding maven-metadata.xml files. I have a need to regenerate a bunch of maven-metadata.xml files. I was wondering if there where any tools or mojo's that might be able to help me do this. Needing to do this was caused by... Check out the repository managers - I believe they all can correct these files (I know for certain Archiva does). I also have a problem with using deploy:deploy-file. It seems to just create a brand new maven-metadata.xml file regardless of if the file has contents or not. Does anyone know how to make it stop doing that? I have checked the documentation here: which information is wrong afterwards - is it missing other versions? I assume you are talking about the one in the artifactId directory, not the group or version directory? If this really isn't working, an issue should be filed with the deploy plugin. - Brett - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Update maven-metadata.xml
I'm still trying to get away with not using a repo manager. I can always right a perl script to update the maven-metadata.xml files, but if something already existed, I would prefer that. This is what's in it after a deploy (group id and artifact id changed): ?xml version=1.0 encoding=UTF-8?metadata groupIdcom.pervasive.component/groupId artifactIdartifact-distribution/artifactId version4.0.2.11/version versioning versions version4.0.2.11/version /versions lastUpdated20090401013925/lastUpdated /versioning /metadata Yea, it's the maven-metadata.xml in the artifactId directory, sorry I was not clear on that. Basically the file gets recreated as if the maven-metadata.xml file was not there before. This just wipes out all of the other version in the maven-metadata.xml file that had been created. I opened a bug here: http://jira.codehaus.org/browse/MDEPLOY-99 FWIW, Maven 2.1.0 and maven-deploy-plugin 2.4. -Jim -Original Message- From: Brett Porter [mailto:br...@apache.org] Sent: Tuesday, March 31, 2009 8:33 PM To: Maven Users List Subject: Re: Update maven-metadata.xml On 01/04/2009, at 12:16 PM, Jim McCaskey wrote: Hello all, I have two questions surrounding maven-metadata.xml files. I have a need to regenerate a bunch of maven-metadata.xml files. I was wondering if there where any tools or mojo's that might be able to help me do this. Needing to do this was caused by... Check out the repository managers - I believe they all can correct these files (I know for certain Archiva does). I also have a problem with using deploy:deploy-file. It seems to just create a brand new maven-metadata.xml file regardless of if the file has contents or not. Does anyone know how to make it stop doing that? I have checked the documentation here: which information is wrong afterwards - is it missing other versions? I assume you are talking about the one in the artifactId directory, not the group or version directory? If this really isn't working, an issue should be filed with the deploy plugin. - Brett - 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: Update maven-metadata.xml
Using a repo manager would solve both problems. You could upload via a ui instead of deploy-file and the metadata would be correctly generated. -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Tuesday, March 31, 2009 9:17 PM To: 'users@maven.apache.org' Subject: Update maven-metadata.xml Hello all, I have two questions surrounding maven-metadata.xml files. I have a need to regenerate a bunch of maven-metadata.xml files. I was wondering if there where any tools or mojo's that might be able to help me do this. Needing to do this was caused by... I also have a problem with using deploy:deploy-file. It seems to just create a brand new maven-metadata.xml file regardless of if the file has contents or not. Does anyone know how to make it stop doing that? I have checked the documentation here: http://maven.apache.org/plugins/maven-deploy-plugin/index.html I did some googling around and found some comments regarding this but nothing definitive. FWIW, I am using Maven 2.1.0 for all of this, on Windows. Thanks! -Jim - 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
