Cannot configure Legacy Artifact Path Resolution of Non-standard path
Hi guys, I'm having troubles configuring legacy artifact path for maven-jaxb-plugin. Artifact is located here: http://download.java.net/maven/1/com.sun.tools.xjc.maven2/maven-plugins/ I believe, the M1 standard is to rather put maven plugins inside the plugins directory instead of maven-plugins. Anyway, I tried configuring it via admin: Path: com.sun.tools.xjc.maven2/maven-plugins/maven-jaxb-plugin-1.1.jar GroupId: com.sun.tools.xjc.maven2 ArtifactId: maven-jaxb-plugin Version: 1.1 Classifier: Type: maven-plugin And get this on submit: artifact reference does not match the initial path : com.sun.tools.xjc.maven2/plugins/maven-jaxb-plugin-1.1.jar Also, the auto complete feature does not correctly slice the input initially: ArtifactId: maven Version: jaxb-plugin-1.1 I just manually deployed to archiva instead using the pom and the jar file from this repo. Thanx! regards, mykol
Re: Cannot configure Legacy Artifact Path Resolution of Non-standard path
hi nicolas, here you go: http://jira.codehaus.org/browse/MRM-768 On Tue, Apr 8, 2008 at 3:37 PM, nicolas de loof [EMAIL PROTECTED] wrote: legacy artifact path configuration is a way for archiva to support maven1 clients (maven1 request URL is not fine-grained enough to safelly detect the artifactId / version / classifier). When you want to acces a legacy-layout repository using a proxy connector, you don't need to configure anything. Your issue is that archiva search the expected artifact in /plugins/ and not in /maven-plugins/ In archiva source code ( AbstractLegacyRepositoryContent.java ) I can read : typeToDirectoryMap.put( ArtifactExtensionMapping.MAVEN_PLUGIN, plugin ); BUT when deploying a project to a legacy repo, the maven ArtifactHandler (in maven-artifact.jar) set : roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintmaven-plugin/role-hint configuration typemaven-plugin/type extensionjar/extension IMHO, archiva tries to use the same type for two incompatible artifacts : maven1 plugins and maven2 ones. As requesting a maven2 plugin from a maven1 repository is really not a common use case, this may not have been discovered yet. Please open an Issue for this. Nicolas. 2008/4/8, Michael Mallete [EMAIL PROTECTED]: Hi guys, I'm having troubles configuring legacy artifact path for maven-jaxb-plugin. Artifact is located here: http://download.java.net/maven/1/com.sun.tools.xjc.maven2/maven-plugins/ I believe, the M1 standard is to rather put maven plugins inside the plugins directory instead of maven-plugins. Anyway, I tried configuring it via admin: Path: com.sun.tools.xjc.maven2/maven-plugins/maven-jaxb-plugin-1.1.jar GroupId: com.sun.tools.xjc.maven2 ArtifactId: maven-jaxb-plugin Version: 1.1 Classifier: Type: maven-plugin And get this on submit: artifact reference does not match the initial path : com.sun.tools.xjc.maven2/plugins/maven-jaxb-plugin-1.1.jar Also, the auto complete feature does not correctly slice the input initially: ArtifactId: maven Version: jaxb-plugin-1.1 I just manually deployed to archiva instead using the pom and the jar file from this repo. Thanx! regards, mykol
Re: timeouts configuration
the feature is present in trunk and will be released with Archiva 1.1. On 09/04/2008, aldana [EMAIL PROTECTED] wrote: hi, currently proxy repository of http://repository.codehaus.org/ had been very slow in respondance. this made archiva hang (see log below). after removing this repository as proxy connector everything worked fine again. instead of deleting this another setting would be nice, so if there are download problems or a certain timeout has been reached, respective proxy connector should be ignored for a certain time gap. 1150450336 [Thread-5] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:database-update - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lang.NullPointerException at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:118) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) Caused by: java.lang.NullPointerException at org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifactClosure.java:56) at org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateProcessed(JdoDatabaseUpdater.java:170) at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllProcessed(JdoDatabaseUpdater.java:111) at org.apache.maven.archiva.scheduled.executors.ArchivaDatabaseUpdateTaskExecutor.executeTask(ArchivaDatabaseUpdateTaskExecutor.java:78) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) - manuel aldana aldana((at))gmx.de homepage: http://www.aldana-online.de -- View this message in context: http://www.nabble.com/timeouts-configuration-tp16558750p16558750.html Sent from the archiva-users mailing list archive at Nabble.com. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: Archiva purge
Hi Brett, it is not docuented, but you need to restart archiva. Thanks for teh hint. Stefano yes, it should. Do you see a block summary in the logs that says the repository was scanned? If so, was the purge consumer listed? On 05/04/2008, Stefano Fornari [EMAIL PROTECTED] wrote: Hi All, I am using archiva 1.0.1 and I would like to use the purge functionality to purge the snapshots older than 10 days. I had configured the repository already some time ago, but I just recently realized I have to enable the repository-purge consumer. So I did it a week ago. Should this change take place and apply immediately from the next scan? looking into the repository there are still snapshots older than 10 days... Any hint is appreciated. Thanks in advance. stefano -- Stefano Fornari - Funambol CTO === Home: http://www.funambol.org Documents: http://www.funambol.org/documentation/documents.html FAQ: http://www.funambol.org/support/faq.html WIKI: https://wiki.objectweb.org/sync4j/ Mailinglist archives: http://groups.yahoo.com/group/Sync4j (login required) http://sourceforge.net/mailarchive/forum.php?forum_id=215 (sync4j-users) http://sourceforge.net/mailarchive/forum.php?forum_id=48877 (funambol-dev)
Re: metadata -updater does not appear to be working!
Hi Jason, Can you file this as a request? I think at present the updater corrects the versions flag, but not the snapshot information (it also doesn't correct the plugin group metadata). - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: According to the documentation the metadata-updater will do the following: metadata-updater - Updates artifact metadata files depending on the content of the repository. I have been testing this by deploying several artifacts to the repository and getting a specific timestamp and build number in the maven-metatadata.xml file. Next, I delete the latest (snapshot) build from the repo, including checksums. I run the repository scanner and the database-updater and this file is never fixed based on the actual contents of the file system. Archive updates it internal metadata, but not maven's metadata and thus maven fails to download the artifact. -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: metadata -updater does not appear to be working!
I will file it today. Is there any chance of getting it into a 1.0.2 release? I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:36 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! Hi Jason, Can you file this as a request? I think at present the updater corrects the versions flag, but not the snapshot information (it also doesn't correct the plugin group metadata). - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: According to the documentation the metadata-updater will do the following: metadata-updater - Updates artifact metadata files depending on the content of the repository. I have been testing this by deploying several artifacts to the repository and getting a specific timestamp and build number in the maven-metatadata.xml file. Next, I delete the latest (snapshot) build from the repo, including checksums. I run the repository scanner and the database-updater and this file is never fixed based on the actual contents of the file system. Archive updates it internal metadata, but not maven's metadata and thus maven fails to download the artifact. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: metadata -updater does not appear to be working!
On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base/archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven/archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426view=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: metadata -updater does not appear to be working!
I can confirm that both timestamp and build number are the problem. For example, here is the latest artifact on the file system: test-1.0-2008407.211352-3.jar here is the metatdata file: metadata groupIdchaffee.jason.test/groupId artifactIdtest/artifactId version1.0-SNAPSHOT/version versioning snapshot buildNumber5/buildNumber timestamp20080407.212453/timestamp /snapshot lastUpdated20080407212454/lastUpdated /versioning /metadata -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:54 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-repository-layer/src/main/java/org/apache/maven/archiva/reposit ory/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven /archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426vie w=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: metadata -updater does not appear to be working!
Ah, sorry I wasn't clear. I was referring to the timestamp on the filesystem - if you touch the JAR you listed and scan again, is the metadata updated? Likewise, does adding a new build instead of removing work? - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I can confirm that both timestamp and build number are the problem. For example, here is the latest artifact on the file system: test-1.0-2008407.211352-3.jar here is the metatdata file: metadata groupIdchaffee.jason.test/groupId artifactIdtest/artifactId version1.0-SNAPSHOT/version versioning snapshot buildNumber5/buildNumber timestamp20080407.212453/timestamp /snapshot lastUpdated20080407212454/lastUpdated /versioning /metadata -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:54 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-repository-layer/src/main/java/org/apache/maven/archiva/reposit ory/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven /archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426vie w=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: metadata -updater does not appear to be working!
If the metadata has been updated, then the deploy works fine and the metadata in updated correctly. If the metadata has not been update, the deploy still works fine, but the build numbers get off and there will be missing builds in the repo. I am not sure of other scenarios. We have not encountered any. Deleting files and fixing metatdata files has been a problem for us for awhile and we have had to do it manually in the past, so that it is why it is nice to have this feature in Archiva. However, I would like to see it correct the metatdata file without needing to touch any files after deleting files. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 4:34 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: 1) touching the old jar, seems to work. ok, I'll add that info to the bug 2) I add new builds with maven and not Archiva, and it will increment from the last build number so the next build will not be 4, it will be 6. If, the metatdata file isn't updated first. right - but if the metadata is up to date, then there's no problem? That is, are there scenarios other than deleting builds where the metadata is not updated? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 4:08 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! Ah, sorry I wasn't clear. I was referring to the timestamp on the filesystem - if you touch the JAR you listed and scan again, is the metadata updated? Likewise, does adding a new build instead of removing work? - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I can confirm that both timestamp and build number are the problem. For example, here is the latest artifact on the file system: test-1.0-2008407.211352-3.jar here is the metatdata file: metadata groupIdchaffee.jason.test/groupId artifactIdtest/artifactId version1.0-SNAPSHOT/version versioning snapshot buildNumber5/buildNumber timestamp20080407.212453/timestamp /snapshot lastUpdated20080407212454/lastUpdated /versioning /metadata -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:54 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-repository-layer/src/main/java/org/apache/maven/archiva/reposit ory/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven /archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426vie w=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
Unable to build archiva trunk
Hi, just tried to build archiva 1.0.2-SNAPSHOT and getting following error: [INFO] Building Archiva Base :: Common [INFO]task-segment: [compile] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-plugins/2-SNAPSHOT/maven-plugins-2-SNAPSHOT.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 Reason: Cannot find parent: org.apache.maven.plugins:maven-plugins for project: null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 for project null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 saying the artifact for maven-plugins:2-SNAPSHOT ist not available, so far so good. But if You have a clooser look this artifact is referenced by maven-resources-plugin:2.3-20060725.131549-1, mmmhhh build date 2006xxx. Ok, lets have a look in http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-resources-plugin/2.3-SNAPSHOT/ and voila there is a newer version, but it isn't referenced from the maven-metadata.xml file. And maven gets this very old snapshot version referencing maven-plugins:2-SNAPSHOT. Could someone correct this metadata, please? Roland
Re: Unable to build archiva trunk
fixed On 09/04/2008, Roland Klein [EMAIL PROTECTED] wrote: Hi, just tried to build archiva 1.0.2-SNAPSHOT and getting following error: [INFO] Building Archiva Base :: Common [INFO]task-segment: [compile] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-plugins/2-SNAPSHOT/maven-plugins-2-SNAPSHOT.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 Reason: Cannot find parent: org.apache.maven.plugins:maven-plugins for project: null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 for project null:maven-resources-plugin:maven-plugin:2.3-20060725.131549-1 saying the artifact for maven-plugins:2-SNAPSHOT ist not available, so far so good. But if You have a clooser look this artifact is referenced by maven-resources-plugin:2.3-20060725.131549-1, mmmhhh build date 2006xxx. Ok, lets have a look in http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-resources-plugin/2.3-SNAPSHOT/ and voila there is a newer version, but it isn't referenced from the maven-metadata.xml file. And maven gets this very old snapshot version referencing maven-plugins:2-SNAPSHOT. Could someone correct this metadata, please? Roland -- Brett Porter Blog: http://blogs.exist.com/bporter/
[ANNOUNCE] Apache Archiva 1.0.2 Released
The Apache Archiva team is pleased to announce the release of Archiva 1.0.2 Archiva is a build artifact repository manager for use with build tools such as Maven, Continuum and Ant. It has features like repository search and browse, securing repositories, identifying unknown artifacts and reporting of repository problems. Aside from these, it can also act as a nearby (proxy) cache of popular global repositories. The latest release is now available here: http://maven.apache.org/archiva/download.html If you have any questions, please consult: - the web site: http://maven.apache.org/archiva/ - the archiva-user mailing list: http://maven.apache.org/archiva/mail-lists.html New in Archiva 1.0.2 * Configurable Proxy Error Handling Two new options have been added to the proxy connector configuration page: - On remote error - gives control over whether to stop immediately, continue to try for a successful proxy, or ignore an error - Return error when - gives control over whether to return an existing artifact if present or fail regardless if a remote error occurs when updating an artifact Change Log for Archiva 1.0.2 === * [MRM-159] - should not respond with a 404 if proxying a file results in a remote error * [MRM-532] - Unable to specify the location of the index files through the web ui * [MRM-598] - Validation error on new repository creation and other fields under certain conditions * [MRM-608] - Unable to find project model for [...] if the initial import of the POM failed * [MRM-617] - Reporting does not work due to bug in client-side JavaScript validation * [MRM-618] - PLEXUS_BASE does not work for local databases * [MRM-622] - database not being updated with project model information * [MRM-626] - ClassCastException when saving proxy connector with property defined * [MRM-627] - Archiva doesn't download SNAPSHOTs for proxied repositories. * [MRM-642] - archiva-common tests rely on relative paths * [MRM-655] - The logs are duplicated in the archiva.log and wrapper.log file. * [MRM-659] - archiva cannot serve ejb artifacts from a maven1 repository * [MRM-661] - remote repository removals are not saved after restart * [MRM-664] - Cannot download a strut-module artifact in a Legacy repository * [MRM-674] - LayoutException when downloading SNAPSHOT test-sources * [MRM-683] - Archiva version missing from pages and logs * [MRM-687] - Project model cannot be added to database if it inherits groupId and/or version from parent POM * [MRM-689] - Incorrect war name in example for tomcat * [MRM-690] - using undefined appserver.base * [MRM-691] - Can't get any of the consumers to work without through a NPE * [MRM-701] - Buggy documentation on separating the base from the installation * [MRM-703] - Artifacts with extensions longer than fours characters breaks repository scanning. * [MRM-713] - extensionPattern in FilenameParser is incorrect * [MRM-715] - error adding artifacts to Lucene under some circumstances * [MRM-719] - NPE during repository scan * [MRM-725] - /archiva/browse URL does not work on WebSphere * [MRM-727] - Archiva does not download plugin artifacts in Geronimo * [MRM-734] - Unable to update metadata - No versions found for reference * [MRM-746] - unable to include *.xml in artifacts list as it picks up maven-metadata.xml * [MRM-750] - Adding a network proxy doesn't require an identifier * [MRM-755] - No content type for .pom files denoted in file archiva-mime-types.txt - workaround included * [MRM-758] - unable to schedule cron expressions that contain a comma * [MRM-761] - Exception when trying to retrieve a Maven 1 artifact of type zip * [MRM-762] - Footer doesn't stretch across repositoryScanning and database pages * [MRM-763] - Default cron expression for database update is invalid * [MRM-764] - default policies are not selected in the add proxy connector page * [MRM-504] - Find Artifact page needs more onscreen information/ instructions * [MRM-656] - Admin guide for installing WAR needs updating * [MRM-666] - Edit Managed Repository page should indicate the repo id being edited * [MRM-700] - Review the documentation on deploying to Archiva for inconsistent repository ids * [MRM-720] - Upgrade Lucene from 2.0 to 2.3.1 Thanks, The Apache Archiva team
Using Maven Ant Tasks in a CI Environment with IBM Jazz
Hello, I'm struggeling with some problems using the Maven ant tasks in the CI environment with IBM Jazz. There are some ant tasks for IBM Jazz which are handling the connection between the build engine and the Jazz server. These Jazz ant tasks are working well as long as I haven't used the Maven ant task in the build script. One of the Jazz guys analyzed the problem as follows: [quote] I was able to get some understanding of this problem. Maven is switching out the context class loader on the main Ant thread when their task is invoked. Before the Maven task runs when everything works properly...the main ant thread has a class loader of... classLoaderLauncher$AppClassLoader (id=113) [EMAIL PROTECTED] After the Maven task runs the class loader is now... classLoaderRealmClassLoader (id=166) [EMAIL PROTECTED] EMF can no longer find the appropriate factory as it delegates to the class loader to find the EMF package. The NPE is then thrown as it attempts to use the null factory to get the item type in WebServicesSAXXHandler while marshalling the request to the server. I hacked into our task a trap of the class loader before the Maven call and then set it back the next time our task executed. Everything worked fine again. It seems ridiculous that Maven is switching the class loader for the main ant thread when their task executes...at the very least if this insanity is necessary they should be switching it back. It appears you can work around this problem by making your pom call into Maven before you call any of our ant tasks. We then appear to get initially loaded into their class loader correctly and everything works ok. [/quote] Why is the Maven ant task switching the class loader for the main ant thread? Is this a bug or works as designed? Thanks for your feedback! Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: integration tests, packaging type pom and the maven-eclipse-plugin
Hi Kalle! On Monday 07 April 2008 Kalle Korhonen wrote: Just change the packaging type temporarily from pom to jar and run mvn eclipse:eclipse. That's what I do right now, but IMHO that's not a solution for the problem but rather a workaround. Thanks anyway and best regards, - martin signature.asc Description: This is a digitally signed message part.
Re: Use assembly and deploy togeather
I tried it with this command but my problem is the created zip file does not contain the deployed jar file. It still has a -SNAPSHOT postfix which is quite ugly. On Tue, Apr 8, 2008 at 1:44 AM, Luke Daley [EMAIL PROTECTED] wrote: On 07/04/2008, at 11:14 PM, Michael Mühlebach wrote: I want to create an assembly and deploy it but I have some troubles with it. I tried it with the command: mvn assembly:single deploy I got almost what I expected except: All artifacts from my project, including the one I executed maven for, are snapshot versions! (have the classifier -SNAPSHOT instead of a build date and number). What have I done wrong or did I misunderstand the assembly/deploy build cycle?! I am not sure exactly what you are trying to do, but if you are trying to create another build artifact (such as a distribution zip or something) and have it deployed along side your built jars (or whatever) then you might want to look at the assembly:attached goal. http://maven.apache.org/plugins/maven-assembly-plugin/attached-mojo.html LD. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath Loader Differences between Surefire 2.3 and 2.4 causes tests to fail
On Monday 07 April 2008 Andreas Guther wrote: We see a difference in classpath loading between Surefire 2.3 and 2.4. Search the archive of this list on nabble.com for surefire 2.4 classpath and you'll find your answer. Note, that there was a bug in maven 2.0.7, so updating to a newer maven version might be necessary. hth, - martin signature.asc Description: This is a digitally signed message part.
Re: maven2 pom help
On Monday 07 April 2008 Wayne Fay wrote: Start over from scratch. Put all Java source files in main/src/java. You do not need to configure the jar plugin. Sorry to correct you Wayne, but it's not main/src/java but src/main/java. hth, - martin signature.asc Description: This is a digitally signed message part.
Issue when run ant task under maven2
Hello y'all, Would u be nice to look a bit into my wicked issue) Bugger, i've spent 3 days and still screwing.. Main idea: try to submit any simple task under maven, i've done it before on my local machine as well, and then try on remote VM ware. Everywhere have the same enviroment - Eclipse with Maven 2 plugin. Source code (pom file): ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdboom/groupId artifactIdboom/artifactId version0.0.1-SNAPSHOT/version description/description build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId dependencies dependency groupIdant/groupId artifactIdant-antlr/artifactId version1.6.5/version /dependency /dependencies configuration taskscopy file=c:/temp/test.txt todir=c:///tasks /configuration executions execution phaseinstall/phase goals goalrun/goal /goals /execution /executions /plugin /plugins /build /project - Log file: [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - boom:boom:jar:0.0.1-SNAPSHOT [INFO]task-segment: [install] [INFO] [INFO] resources:resources [INFO] Using default encoding to copy filtered resources. [INFO] compiler:compile [INFO] Nothing to compile - all classes are up to date [INFO] resources:testResources [INFO] Using default encoding to copy filtered resources. [INFO] compiler:testCompile [INFO] Nothing to compile - all classes are up to date [INFO] surefire:test [INFO] Surefire report directory: C:\eclipse\workspaceX\boom\target\surefire-reports --- T E S T S --- There are no tests to run. Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 [INFO] jar:jar [INFO] install:install [INFO] Installing C:\eclipse\workspaceX\boom\target\boom-0.0.1-SNAPSHOT.jar to C:\Documents and Settings\T183724\.m2\repository\boom\boom\0.0.1-SNAPSHOT\boom-0.0.1-SNAPSHOT.jar [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] org.apache.tools.ant.UnknownElement.setNamespace(Ljava/lang/String;)V [INFO] [INFO] Total time: 5 second [INFO] Finished at: Tue Apr 08 10:26:41 CEST 2008 [INFO] Memory 7M/18M [INFO] I'm so sad according to following org.apache.tools.ant.UnknownElement.setNamespace(Ljava/lang/String;)V Before in this project I done some maven-assembly-plugin. Additionaly, I've tried make a new one project and inject small ant task in root pom.. and still have the same issue( Sincerely yours, -Gerasim -- View this message in context: http://www.nabble.com/Issue-when-run-ant-task-under-maven2-tp16549274s177p16549274.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repository search
We have a live instance of Nexus sitting on a mirror of Central: http://repository.sonatype.org -Original Message- From: Martin von Gagern [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2008 11:33 AM To: Maven Users List Subject: Re: Repository search Stuart McCulloch wrote: you mean like: http://www.mvnrepository.com Yes, that looks pretty much what I wanted, although I miss information about that site itself, like what repositories it has indexed. That's a minor issue, though. there's also the Nexus indexing tool, as used by various Maven IDE plugins: http://docs.codehaus.org/display/M2ECLIPSE/Nexus+indexer#NexusIndexer-in dexer http://nexus.sonatype.org That might be useful as well. Sadly, it looks like repo1.maven.org is the only repository from my list to actually provide this .index directory. And I'm still looking for a convenient way to use these indexes from the command line or a web interface. Thanks a lot, Martin von Gagern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Downloading Apache Maven Repositories : Proxy Workaround
Use Nexus as a local proxy/cache. You can download and run it out of the box with no config so it's the easiest and lightest instance to run on a local machine. Just hook up your Maven to it with a mirrorOf central (or *) and run your build ahead of time. This will populate Nexus with all the artifacts you need. You can then clear your local repository to show how Maven downloads the artifacts from central From: Edward Song [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2008 3:53 PM To: users@maven.apache.org Subject: Downloading Apache Maven Repositories : Proxy Workaround For demo purposes, I wanted to show the benefits of Apache Maven to a few others. There is a firewall and proxy over here that will not allow Maven to go get artifacts from the central maven repository and the networking guy will not provide the necessary authentication info to allow Maven to tunnel through the proxy. Is there a way to get an install of Maven which contains the latest artifact snapshots by default? Looking for a quick fix. Thanks in advance. Ed
Repository not working problem
Hello, How to setup timeout for rarely not working repository, or how to set to skip fetching poms from such repositories? I have problem because sometime when developing one of repo is out, and our build waits for it very long period of time - it consider only checking if newer version is available, we got fetched sooner right version for us - how to skip this checking? Best regards, Adr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Downloading Apache Maven Repositories : Proxy Workaround
Thanks Wayne for your reply, They're super strict with their networking and only allow HTTP traffic through a firewall and the demo computer is onsite. So installs can only be done from an internal approved resource. Despite their tight restrictions, they have a manual build process, and need some way to demonstrate that loosening the restriction via Maven and Archiva, would be a good solution for them. My current plan is to use Archiva on a laptop and bring it in to the client site, which works great by the way. But this is an instance, where a build with the most up to date snapshots would be beneficial. I guess my query is, of installing an internal repository by default, without looking towards an external repository at all for the initial snapshots? Thanks, Edward Song -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2008 4:34 PM To: Maven Users List Subject: Re: Downloading Apache Maven Repositories : Proxy Workaround Just connect to the Maven repo before your demo and let it update. You may want to run with -o for offline so it doesn't try to update again during the demo. Or perhaps consider running Archiva locally (on the same laptop that you're demo'ing Maven with). That sounds easiest to me. You'll want to update Archiva before the demo, of course, but then you can delete ~/.m2/repository and show Maven auto-downloading from the Archiva repo etc. Wayne On 4/7/08, Edward Song [EMAIL PROTECTED] wrote: For demo purposes, I wanted to show the benefits of Apache Maven to a few others. There is a firewall and proxy over here that will not allow Maven to go get artifacts from the central maven repository and the networking guy will not provide the necessary authentication info to allow Maven to tunnel through the proxy. Is there a way to get an install of Maven which contains the latest artifact snapshots by default? Looking for a quick fix. Thanks in advance. Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Apache Maven Repositories : Proxy Workaround
Well, for the record, this is the same with a default Archiva installation. Each to their own :) On 08/04/2008, Brian E. Fox [EMAIL PROTECTED] wrote: Use Nexus as a local proxy/cache. You can download and run it out of the box with no config so it's the easiest and lightest instance to run on a local machine. Just hook up your Maven to it with a mirrorOf central (or *) and run your build ahead of time. This will populate Nexus with all the artifacts you need. You can then clear your local repository to show how Maven downloads the artifacts from central From: Edward Song [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2008 3:53 PM To: users@maven.apache.org Subject: Downloading Apache Maven Repositories : Proxy Workaround For demo purposes, I wanted to show the benefits of Apache Maven to a few others. There is a firewall and proxy over here that will not allow Maven to go get artifacts from the central maven repository and the networking guy will not provide the necessary authentication info to allow Maven to tunnel through the proxy. Is there a way to get an install of Maven which contains the latest artifact snapshots by default? Looking for a quick fix. Thanks in advance. Ed -- Brett Porter Blog: http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven assembly differs when built on Windows vs. Unix
Hi Folks I've raised a JIRA issue regarding my project. When I do mvn assembly:assembly on Windows I get good artifacts, but the contents of my .tar files differs materially when the same is done on Linux (our build server). The problem concerns my introduction of classifier-based artifacts for a couple of shared libraries which as specific to solaris, linux_2x and linux_3x. Any comments on http://jira.codehaus.org/browse/MASSEMBLY-304 would be greatly appreciated as I'm up against the wall on this right now. I think it would be very useful to see the version number of the Maven Assembly Plugin but I can't see a way of doing so. As far as I know these are vanilla Maven 2.0.8 installs on both boxes. With so many classifier-based issues relatively recently addressed in the Assembly plug-in it would be good to vallidate the version I have. Thanks, Robin. _ Before acting on this e mail or opening any attachment please read the disclaimer which can be accessed at http://www.investec.com/EmailDisclaimer/UKEmailDisclaimer.htm Investec Bank (UK) Limited is authorised and regulated by the Financial Services Authority. _ _ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com Investec Bank (UK) Limited Registered office: 2 Gresham Street, London, EC2V 7QP Company No: 00489604 Incorporated in England and Wales
AW: Maven assembly differs when built on Windows vs. Unix
I noticed the difference between 2.2-beta-1 and 2.2-beta-2 as well. Either lock the plugin version: build plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-1/version /plugin /plugins /build or update your plugins by starting Maven with -U to have the latest version on all your systems. Regards, - Torben Giesselmann -Ursprüngliche Nachricht- Von: Robin Roos [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 8. April 2008 15:53 An: users@maven.apache.org Betreff: Maven assembly differs when built on Windows vs. Unix Hi Folks I've raised a JIRA issue regarding my project. When I do mvn assembly:assembly on Windows I get good artifacts, but the contents of my .tar files differs materially when the same is done on Linux (our build server). The problem concerns my introduction of classifier-based artifacts for a couple of shared libraries which as specific to solaris, linux_2x and linux_3x. Any comments on http://jira.codehaus.org/browse/MASSEMBLY-304 would be greatly appreciated as I'm up against the wall on this right now. I think it would be very useful to see the version number of the Maven Assembly Plugin but I can't see a way of doing so. As far as I know these are vanilla Maven 2.0.8 installs on both boxes. With so many classifier-based issues relatively recently addressed in the Assembly plug-in it would be good to vallidate the version I have. Thanks, Robin. _ Before acting on this e mail or opening any attachment please read the disclaimer which can be accessed at http://www.investec.com/EmailDisclaimer/UKEmailDisclaimer.htm Investec Bank (UK) Limited is authorised and regulated by the Financial Services Authority. _ _ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com Investec Bank (UK) Limited Registered office: 2 Gresham Street, London, EC2V 7QP Company No: 00489604 Incorporated in England and Wales - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
timeouts configuration
hi, currently proxy repository of http://repository.codehaus.org/ had been very slow in respondance. this made archiva hang (see log below). after removing this repository as proxy connector everything worked fine again. instead of deleting this another setting would be nice, so if there are download problems or a certain timeout has been reached, respective proxy connector should be ignored for a certain time gap. 1150450336 [Thread-5] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:database-update - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lang.NullPointerException at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:118) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) Caused by: java.lang.NullPointerException at org.apache.maven.archiva.database.updater.ProcessArchivaArtifactClosure.execute(ProcessArchivaArtifactClosure.java:56) at org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateProcessed(JdoDatabaseUpdater.java:170) at org.apache.maven.archiva.database.updater.JdoDatabaseUpdater.updateAllProcessed(JdoDatabaseUpdater.java:111) at org.apache.maven.archiva.scheduled.executors.ArchivaDatabaseUpdateTaskExecutor.executeTask(ArchivaDatabaseUpdateTaskExecutor.java:78) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) - manuel aldana aldana((at))gmx.de homepage: http://www.aldana-online.de -- View this message in context: http://www.nabble.com/timeouts-configuration-tp16558750p16558750.html Sent from the archiva-users mailing list archive at Nabble.com.
RE: Maven assembly differs when built on Windows vs. Unix
Since the behaviour of 2.2-beta-2 is not what I want I have now fixed the version number. Hopefully that will address the problem when our build server does the build. The problem I then face is that either -beta-2 breaks something, or I am relying on broken behaviour that was fixed in beta-2 -Original Message- From: Giesselmann, Torben [mailto:[EMAIL PROTECTED] Sent: 08 April 2008 15:18 To: Maven Users List Subject: AW: Maven assembly differs when built on Windows vs. Unix I noticed the difference between 2.2-beta-1 and 2.2-beta-2 as well. Either lock the plugin version: build plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-1/version /plugin /plugins /build or update your plugins by starting Maven with -U to have the latest version on all your systems. Regards, - Torben Giesselmann -Ursprüngliche Nachricht- Von: Robin Roos [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 8. April 2008 15:53 An: users@maven.apache.org Betreff: Maven assembly differs when built on Windows vs. Unix Hi Folks I've raised a JIRA issue regarding my project. When I do mvn assembly:assembly on Windows I get good artifacts, but the contents of my .tar files differs materially when the same is done on Linux (our build server). The problem concerns my introduction of classifier-based artifacts for a couple of shared libraries which as specific to solaris, linux_2x and linux_3x. Any comments on http://jira.codehaus.org/browse/MASSEMBLY-304 would be greatly appreciated as I'm up against the wall on this right now. I think it would be very useful to see the version number of the Maven Assembly Plugin but I can't see a way of doing so. As far as I know these are vanilla Maven 2.0.8 installs on both boxes. With so many classifier-based issues relatively recently addressed in the Assembly plug-in it would be good to vallidate the version I have. Thanks, Robin. _ Before acting on this e mail or opening any attachment please read the disclaimer which can be accessed at http://www.investec.com/EmailDisclaimer/UKEmailDisclaimer.htm Investec Bank (UK) Limited is authorised and regulated by the Financial Services Authority. _ _ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com Investec Bank (UK) Limited Registered office: 2 Gresham Street, London, EC2V 7QP Company No: 00489604 Incorporated in England and Wales - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _ Before acting on this e mail or opening any attachment please read the disclaimer which can be accessed at http://www.investec.com/EmailDisclaimer/UKEmailDisclaimer.htm Investec Bank (UK) Limited is authorised and regulated by the Financial Services Authority. _ _ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com Investec Bank (UK) Limited Registered office: 2 Gresham Street, London, EC2V 7QP Company No: 00489604 Incorporated in England and Wales - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Downloading Apache Maven Repositories : Proxy Workaround
Since you mentioned it, and I wasn't aware that there was a standalone archiva, I decided to check it out. Firing it up with no config, just adding an admin user uses up ~130MB of ram. A standalone default Nexus config is using only ~28. Artifactory is using about ~50mb. On a server this might not be important, but on a developer machine that could be significant. In fact I never thought much about it, but we are running the public nexus instance[1] that is hosting the proxy and repositories for our two CI systems and the M2eclipse build, with the JDK default of 64mb of ram. [1]http://repository.sonatype.org -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 10:02 AM To: Maven Users List Subject: Re: Downloading Apache Maven Repositories : Proxy Workaround Well, for the record, this is the same with a default Archiva installation. Each to their own :) On 08/04/2008, Brian E. Fox [EMAIL PROTECTED] wrote: Use Nexus as a local proxy/cache. You can download and run it out of the box with no config so it's the easiest and lightest instance to run on a local machine. Just hook up your Maven to it with a mirrorOf central (or *) and run your build ahead of time. This will populate Nexus with all the artifacts you need. You can then clear your local repository to show how Maven downloads the artifacts from central From: Edward Song [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2008 3:53 PM To: users@maven.apache.org Subject: Downloading Apache Maven Repositories : Proxy Workaround For demo purposes, I wanted to show the benefits of Apache Maven to a few others. There is a firewall and proxy over here that will not allow Maven to go get artifacts from the central maven repository and the networking guy will not provide the necessary authentication info to allow Maven to tunnel through the proxy. Is there a way to get an install of Maven which contains the latest artifact snapshots by default? Looking for a quick fix. Thanks in advance. Ed -- Brett Porter Blog: http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple Executions with Hibernate3 Plugin
So, it is the case that you can only use antrun one in your pom.xml to do one thing? You can't create new goals using XML? If so, that is wicked lame. Alan On Apr 7, 2008, at 3:38 PM, Alan Gutierrez wrote: Wayne You could either include the full plugin config in the plugin or just a property value, whatever makes the most sense. Did you mean... You could either include the full plugin config in the *profile* or just a property value, whatever makes the most sense. Okay. So, there are profiles. I'll use that. I'm curious though, is there no way to create custom goals? I'm wondering how someone would use the antrun task more than once in their build. Let's say I had a foo tool and a bar tool, neither of which had a Maven plugin, but both of which had ant tasks. What if I wanted to create two goals. bar:run foo:run But those goals really where calling antrun:run , which would have to be used twice in the pom, once to define bar:run and once to define foo:run . Analogous, I suppose, to creating ant tasks in build.xml . Is there no way to create new goals short of creating a new plugin? Are profiles supposed to be the means to define new tasks? Alan On Apr 6, 2008, at 11:55 PM, Wayne Fay wrote: The best way to handle this is with multiple profiles. Then you activate one with -Pprofilename eg -Pdbupdate. You could either include the full plugin config in the plugin or just a property value, whatever makes the most sense. Wayne On 4/4/08, Alan Gutierrez [EMAIL PROTECTED] wrote: I have the maven plugin working with the following code. plugin groupIdorg.codehaus.mojo/groupId artifactIdhibernate3-maven-plugin/artifactId version2.0-alpha-2/version dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.3/version /dependency /dependencies configuration executions execution phaseprocess-resources/phase goals goalhbm2ddl/goal /goals /execution /executions componentProperties exportfalse/export !-- updatetrue/update -- ejb3true/ejb3 jdk5true/jdk5 formattrue/format outputfilenameschema.sql/outputfilename /componentProperties /configuration /plugin The executions section I've just added, but I'm not sure how to get to where I want to go. What I want is the ability to run this plugin with the update feature on, so that I can update the databases easily, when I'm in development mode. What XML do I add to create a new separate goal? I supposed I could toggle update using a commandline parameter, but I'm wondering, what are the ways to create a different configuration for a plugin? For the antrun plugin to be useful, it seems like you should be able to specify many different task configurations. -- Alan Gutierrez | [EMAIL PROTECTED] | http://blogometer.com/ | 504 717 1428 Think New Orleans | http://thinknola.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alan Gutierrez | [EMAIL PROTECTED] | http://blogometer.com/ | 504 717 1428 Think New Orleans | http://thinknola.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Apache Maven Repositories : Proxy Workaround
On 09/04/2008, Brian E. Fox [EMAIL PROTECTED] wrote: Since you mentioned it, and I wasn't aware that there was a standalone archiva, I decided to check it out. Firing it up with no config, just adding an admin user uses up ~130MB of ram. A standalone default Nexus config is using only ~28. Artifactory is using about ~50mb. On a server this might not be important, but on a developer machine that could be significant. In fact I never thought much about it, but we are running the public nexus instance[1] that is hosting the proxy and repositories for our two CI systems and the M2eclipse build, with the JDK default of 64mb of ram. Not really the right forum to debate such a thing, but I question your results since I run with -Xmx64m in the wrapper also, continuously on my macbook. It's true that the use of JSP and the default of Derby incurs some overhead which is why I expect that Archiva's figures are closer to that of Artifactory's. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Ant Tasks in a CI Environment with IBM Jazz
Whatever operations are performed on our side that switches the classloader should switch it back. The analysis below doesn't really help us identify where this is happening, but Herve can probably take a look. It might be in the task code, or in Maven itself. On 7-Apr-08, at 11:22 PM, Thomas Tardy wrote: Hello, I'm struggeling with some problems using the Maven ant tasks in the CI environment with IBM Jazz. There are some ant tasks for IBM Jazz which are handling the connection between the build engine and the Jazz server. These Jazz ant tasks are working well as long as I haven't used the Maven ant task in the build script. One of the Jazz guys analyzed the problem as follows: [quote] I was able to get some understanding of this problem. Maven is switching out the context class loader on the main Ant thread when their task is invoked. Before the Maven task runs when everything works properly...the main ant thread has a class loader of... classLoaderLauncher$AppClassLoader (id=113) [EMAIL PROTECTED] After the Maven task runs the class loader is now... classLoaderRealmClassLoader (id=166) [EMAIL PROTECTED] EMF can no longer find the appropriate factory as it delegates to the class loader to find the EMF package. The NPE is then thrown as it attempts to use the null factory to get the item type in WebServicesSAXXHandler while marshalling the request to the server. I hacked into our task a trap of the class loader before the Maven call and then set it back the next time our task executed. Everything worked fine again. It seems ridiculous that Maven is switching the class loader for the main ant thread when their task executes...at the very least if this insanity is necessary they should be switching it back. It appears you can work around this problem by making your pom call into Maven before you call any of our ant tasks. We then appear to get initially loaded into their class loader correctly and everything works ok. [/quote] Why is the Maven ant task switching the class loader for the main ant thread? Is this a bug or works as designed? Thanks for your feedback! Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple Executions with Hibernate3 Plugin
No, you can't create new goals using XML. And this is not wicked lame -- its a good thing for people who care about consistent and repeatable builds across their organization. You can however bind multiple occurrences of the antrun plugin (with varying configurations) to multiple phases if you need various things done automatically at various times in the build. Or you can use profiles as I suggested and call a specific Antrun execution. Maven is not Ant. If you want to use Ant, then just use it instead. Wayne On 4/8/08, Alan Gutierrez [EMAIL PROTECTED] wrote: So, it is the case that you can only use antrun one in your pom.xml to do one thing? You can't create new goals using XML? If so, that is wicked lame. Alan On Apr 7, 2008, at 3:38 PM, Alan Gutierrez wrote: Wayne You could either include the full plugin config in the plugin or just a property value, whatever makes the most sense. Did you mean... You could either include the full plugin config in the *profile* or just a property value, whatever makes the most sense. Okay. So, there are profiles. I'll use that. I'm curious though, is there no way to create custom goals? I'm wondering how someone would use the antrun task more than once in their build. Let's say I had a foo tool and a bar tool, neither of which had a Maven plugin, but both of which had ant tasks. What if I wanted to create two goals. bar:run foo:run But those goals really where calling antrun:run , which would have to be used twice in the pom, once to define bar:run and once to define foo:run . Analogous, I suppose, to creating ant tasks in build.xml . Is there no way to create new goals short of creating a new plugin? Are profiles supposed to be the means to define new tasks? Alan On Apr 6, 2008, at 11:55 PM, Wayne Fay wrote: The best way to handle this is with multiple profiles. Then you activate one with -Pprofilename eg -Pdbupdate. You could either include the full plugin config in the plugin or just a property value, whatever makes the most sense. Wayne On 4/4/08, Alan Gutierrez [EMAIL PROTECTED] wrote: I have the maven plugin working with the following code. plugin groupIdorg.codehaus.mojo/groupId artifactIdhibernate3-maven-plugin/artifactId version2.0-alpha-2/version dependencies dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.3/version /dependency /dependencies configuration executions execution phaseprocess-resources/phase goals goalhbm2ddl/goal /goals /execution /executions componentProperties exportfalse/export !-- updatetrue/update -- ejb3true/ejb3 jdk5true/jdk5 formattrue/format outputfilenameschema.sql/outputfilename /componentProperties /configuration /plugin The executions section I've just added, but I'm not sure how to get to where I want to go. What I want is the ability to run this plugin with the update feature on, so that I can update the databases easily, when I'm in development mode. What XML do I add to create a new separate goal? I supposed I could toggle update using a commandline parameter, but I'm wondering, what are the ways to create a different configuration for a plugin? For the antrun plugin to be useful, it seems like you should be able to specify many different task configurations. -- Alan Gutierrez | [EMAIL PROTECTED] | http://blogometer.com/ | 504 717 1428 Think New Orleans | http://thinknola.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alan Gutierrez | [EMAIL PROTECTED] | http://blogometer.com/ | 504 717 1428 Think New Orleans | http://thinknola.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven2 pom help
Thanks for that Martin, and no need to say sorry! I am human just like anyone and certainly make my share of mistakes. Wayne On 4/8/08, Martin Höller [EMAIL PROTECTED] wrote: On Monday 07 April 2008 Wayne Fay wrote: Start over from scratch. Put all Java source files in main/src/java. You do not need to configure the jar plugin. Sorry to correct you Wayne, but it's not main/src/java but src/main/java. hth, - martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How change location of settings.xml
THANX ALL! -- View this message in context: http://www.nabble.com/How-change-location-of-settings.xml-tp16535853s177p16562011.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Ant Tasks in a CI Environment with IBM Jazz
Here's a simple ant class and script that demonstrates the problem. It uses
the Maven sample.
The ant build script:
?xml version=1.0 encoding=UTF-8?
project name=MavenTest default=default
xmlns:artifact=antlib:org.apache.maven.artifact.ant
description
description
/description
taskdef name=mavenTestTask
classname=maven.test.task.MavenTestTask /
target name=default
echo message=Invoking test class that does nothing but echo the
classloader/
mavenTestTask/
echo message=Invoking maven artifact:pom task/
artifact:pom id=pom file=C:/maven-sample/my-app/pom.xml /
echo message=Invoking test class again that does nothing but echo the
classloader/
mavenTestTask/
/target
/project
The simple Ant Task:
package maven.test.task;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Task;
/**
* Test task demonstrating Maven switching the class loader.
*/
public class MavenTestTask extends Task {
/* (non-Javadoc)
* Intentionally not documented. See parent.
*/
@Override
public void execute() throws BuildException {
log(Current Class Loader: +
Thread.currentThread().getContextClassLoader());
}
The output when run in Ant:
Buildfile: C:\Maven\Test\build.xml
default:
[echo] Invoking test class that does nothing but echo the classloader
[mavenTestTask] Current Class Loader:
[EMAIL PROTECTED]
[echo] Invoking maven artifact:pom task
[echo] Invoking test class again that does nothing but echo the
classloader
[mavenTestTask] Current Class Loader:
[EMAIL PROTECTED]
BUILD SUCCESSFUL
Total time: 871 milliseconds
}
wibbo wrote:
Hello,
I'm struggeling with some problems using the Maven ant tasks in the CI
environment with IBM Jazz. There are some ant tasks for IBM Jazz which
are handling the connection between the build engine and the Jazz
server. These Jazz ant tasks are working well as long as I haven't
used the Maven ant task in the build script. One of the Jazz guys
analyzed the problem as follows:
[quote]
I was able to get some understanding of this problem. Maven is
switching out the context class loader on the main Ant thread when
their task is invoked. Before the Maven task runs when everything
works properly...the main ant thread has a class loader of...
classLoaderLauncher$AppClassLoader (id=113)
[EMAIL PROTECTED]
After the Maven task runs the class loader is now...
classLoaderRealmClassLoader (id=166)
[EMAIL PROTECTED]
EMF can no longer find the appropriate factory as it delegates to the
class loader to find the EMF package. The NPE is then thrown as it
attempts to use the null factory to get the item type in
WebServicesSAXXHandler while marshalling the request to the server. I
hacked into our task a trap of the class loader before the Maven call
and then set it back the next time our task executed. Everything
worked fine again. It seems ridiculous that Maven is switching the
class loader for the main ant thread when their task executes...at the
very least if this insanity is necessary they should be switching it
back.
It appears you can work around this problem by making your pom call
into Maven before you call any of our ant tasks. We then appear to
get initially loaded into their class loader correctly and everything
works ok.
[/quote]
Why is the Maven ant task switching the class loader for the main ant
thread? Is this a bug or works as designed?
Thanks for your feedback!
Regards,
Thomas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Using-Maven-Ant-Tasks-in-a-CI-Environment-with-IBM-Jazz-tp16556859s177p16568639.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mvn repository:bundle-create, no SCM available
Hello! I would like to upload an artifact to Maven central repository, however there's no public SCM available for the artifact - can I still upload the artifact to the repository, or I have to set up and maintain our custom in-house repository for publishing jars and source attachments? Thank you in advance! -- Eugene N Dzhurinsky pgp2ndFPTOIEV.pgp Description: PGP signature
how to execute a plugin only once in multi-project parent pom
Hi, I have a pom that acts both as parent and as multi-module. In it, I have a plugin execution. What I want is for the plugin to execute once when invoking maven on the parent pom (so it does not run for every module), and also have it executed when invoking maven on some child module (where only that module is executed) Thank you, Ittay -- Ittay Dror [EMAIL PROTECTED] Tikal http://www.tikalk.com Tikal Project http://tikal.sourceforge.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn repository:bundle-create, no SCM available
That's ok -- you can publish jars without having a public SCM. Wayne On 4/8/08, Eugeny N Dzhurinsky [EMAIL PROTECTED] wrote: Hello! I would like to upload an artifact to Maven central repository, however there's no public SCM available for the artifact - can I still upload the artifact to the repository, or I have to set up and maintain our custom in-house repository for publishing jars and source attachments? Thank you in advance! -- Eugene N Dzhurinsky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: how to execute a plugin only once in multi-project parent pom
You can set inherited=false in the parent so it won't go down to all the children. There is no way to currently tell a plugin to execute only once in a given build no matter where the build is executed. I tried to do this with the enforcer and ended up having to put caching logic into the plugin itself to deal with this. -Original Message- From: Ittay Dror [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 2:31 PM To: Maven Users List Subject: how to execute a plugin only once in multi-project parent pom Hi, I have a pom that acts both as parent and as multi-module. In it, I have a plugin execution. What I want is for the plugin to execute once when invoking maven on the parent pom (so it does not run for every module), and also have it executed when invoking maven on some child module (where only that module is executed) Thank you, Ittay -- Ittay Dror [EMAIL PROTECTED] Tikal http://www.tikalk.com Tikal Project http://tikal.sourceforge.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing test.properties from within a test case class?
Hi, all. I feel like this must be a really obvious question, but I haven't found an example yet. When I started my project from an archetype (struts 2, specifically) my /test/resources folder got a file called test.properties. It seems pretty clear that this is where properties that my test cases will use should go, but I'm not sure how to access them from within the test case classes. In case specifics are needed, I want to test database-related functions, and am looking for the correct place to put the connection string, user name, etc, as well as the way to access them in Java code so that I can open connections accordingly. Thanks in advance, ~Dan Allen -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of any entity within the KBC Financial Products group of companies (together referred to as KBC FP). This message does not create any obligation, contractual or otherwise, on the part of KBC FP. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC FP would enter into a transaction, or prices at which similar transactions may be carried on KBC FP's own books. The information contained in this message is provided as is, without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing test.properties from within a test case class?
It will be on the classpath, so load that property file as a resource from the cp. -Original Message- From: Allen, Daniel [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:45 PM To: Maven Users List Subject: Accessing test.properties from within a test case class? Hi, all. I feel like this must be a really obvious question, but I haven't found an example yet. When I started my project from an archetype (struts 2, specifically) my /test/resources folder got a file called test.properties. It seems pretty clear that this is where properties that my test cases will use should go, but I'm not sure how to access them from within the test case classes. In case specifics are needed, I want to test database-related functions, and am looking for the correct place to put the connection string, user name, etc, as well as the way to access them in Java code so that I can open connections accordingly. Thanks in advance, ~Dan Allen -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of any entity within the KBC Financial Products group of companies (together referred to as KBC FP). This message does not create any obligation, contractual or otherwise, on the part of KBC FP. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC FP would enter into a transaction, or prices at which similar transactions may be carried on KBC FP's own books. The information contained in this message is provided as is, without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing test.properties from within a test case class?
Ok, thanks. Sorry, I knew it was going to something simple that I was just missing. ~DVA -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:59 PM To: Maven Users List Subject: RE: Accessing test.properties from within a test case class? It will be on the classpath, so load that property file as a resource from the cp. -Original Message- From: Allen, Daniel [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:45 PM To: Maven Users List Subject: Accessing test.properties from within a test case class? Hi, all. I feel like this must be a really obvious question, but I haven't found an example yet. When I started my project from an archetype (struts 2, specifically) my /test/resources folder got a file called test.properties. It seems pretty clear that this is where properties that my test cases will use should go, but I'm not sure how to access them from within the test case classes. In case specifics are needed, I want to test database-related functions, and am looking for the correct place to put the connection string, user name, etc, as well as the way to access them in Java code so that I can open connections accordingly. Thanks in advance, ~Dan Allen -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of any entity within the KBC Financial Products group of companies (together referred to as KBC FP). This message does not create any obligation, contractual or otherwise, on the part of KBC FP. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC FP would enter into a transaction, or prices at which similar transactions may be carried on KBC FP's own books. The information contained in this message is provided as is, without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to execute a plugin only once in multi-project parent pom
ok, created case http://jira.codehaus.org/browse/MNG-3508 Brian E. Fox wrote: You can set inherited=false in the parent so it won't go down to all the children. There is no way to currently tell a plugin to execute only once in a given build no matter where the build is executed. I tried to do this with the enforcer and ended up having to put caching logic into the plugin itself to deal with this. -Original Message- From: Ittay Dror [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 2:31 PM To: Maven Users List Subject: how to execute a plugin only once in multi-project parent pom Hi, I have a pom that acts both as parent and as multi-module. In it, I have a plugin execution. What I want is for the plugin to execute once when invoking maven on the parent pom (so it does not run for every module), and also have it executed when invoking maven on some child module (where only that module is executed) Thank you, Ittay -- Ittay Dror [EMAIL PROTECTED] Tikal http://www.tikalk.com Tikal Project http://tikal.sourceforge.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Ant Tasks in a CI Environment with IBM Jazz
Le mardi 08 avril 2008, Jason van Zyl a écrit : Whatever operations are performed on our side that switches the classloader should switch it back. The analysis below doesn't really help us identify where this is happening, but Herve can probably take a look. It might be in the task code, or in Maven itself. the switch is done in org.codehaus.plexus.org.codehaus.plexus#initializeClassWorlds(), called by org.codehaus.plexus.embed#start( ClassWorld ) The API does change the classloader without storing the previous one, and there is no API to switch it back. For Maven Ant Tasks, it should be easy to fix the problem: please open a Jira issue, and I'll fix it before Maven Ant Tasks 2.0.9 which should be released in a week or 2 AFAIK, the problem exists in embedder too, or I missed the code in embedder that switches the classloader back... Hervé On 7-Apr-08, at 11:22 PM, Thomas Tardy wrote: Hello, I'm struggeling with some problems using the Maven ant tasks in the CI environment with IBM Jazz. There are some ant tasks for IBM Jazz which are handling the connection between the build engine and the Jazz server. These Jazz ant tasks are working well as long as I haven't used the Maven ant task in the build script. One of the Jazz guys analyzed the problem as follows: [quote] I was able to get some understanding of this problem. Maven is switching out the context class loader on the main Ant thread when their task is invoked. Before the Maven task runs when everything works properly...the main ant thread has a class loader of... classLoaderLauncher$AppClassLoader (id=113) [EMAIL PROTECTED] After the Maven task runs the class loader is now... classLoaderRealmClassLoader (id=166) [EMAIL PROTECTED] EMF can no longer find the appropriate factory as it delegates to the class loader to find the EMF package. The NPE is then thrown as it attempts to use the null factory to get the item type in WebServicesSAXXHandler while marshalling the request to the server. I hacked into our task a trap of the class loader before the Maven call and then set it back the next time our task executed. Everything worked fine again. It seems ridiculous that Maven is switching the class loader for the main ant thread when their task executes...at the very least if this insanity is necessary they should be switching it back. It appears you can work around this problem by making your pom call into Maven before you call any of our ant tasks. We then appear to get initially loaded into their class loader correctly and everything works ok. [/quote] Why is the Maven ant task switching the class loader for the main ant thread? Is this a bug or works as designed? Thanks for your feedback! Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Missing artifact org.apache.maven.plugins:maven-jetty-plugin
I was attempting to use AppFuse. Created a project from an archetype and then tried mvn jetty:run-war. I got a BUILD ERROR - The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or no valid version could be found. So I checked. Sure enough, the plugin is missing from the repository. How do we request that it be fixed? I double checked this with two different archetypes on two different machines to make sure it was not a problem with AppFuse. I actually built a project with this archetype this weekend. Thank you for any help. Fred
Re: Missing artifact org.apache.maven.plugins:maven-jetty-plugin
Brier, Frederick (IHG Temp) wrote: I was attempting to use AppFuse. Created a project from an archetype and then tried mvn jetty:run-war. I got a BUILD ERROR - The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or no valid version could be found. So I checked. Sure enough, the plugin is missing from the repository. How do we request that it be fixed? I double checked this with two different archetypes on two different machines to make sure it was not a problem with AppFuse. I actually built a project with this archetype this weekend. Thank you for any help. you have declare the jetty plugin in your build/plugins tag! -- NO OOXML - Say NO To Microsoft Office broken standard http://www.noooxml.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
metadata -updater does not appear to be working!
According to the documentation the metadata-updater will do the following: metadata-updater - Updates artifact metadata files depending on the content of the repository. I have been testing this by deploying several artifacts to the repository and getting a specific timestamp and build number in the maven-metatadata.xml file. Next, I delete the latest (snapshot) build from the repo, including checksums. I run the repository scanner and the database-updater and this file is never fixed based on the actual contents of the file system. Archive updates it internal metadata, but not maven's metadata and thus maven fails to download the artifact.
Re: Missing artifact org.apache.maven.plugins:maven-jetty-plugin
This is not an official plugin, so it has a different groupId than the normal official plugins. Therefor you have to specify the groupId to be able to use it: org.mortbay.jetty:maven-jetty-plugin Brier, Frederick (IHG Temp) wrote: I was attempting to use AppFuse. Created a project from an archetype and then tried mvn jetty:run-war. I got a BUILD ERROR - The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or no valid version could be found. So I checked. Sure enough, the plugin is missing from the repository. How do we request that it be fixed? I double checked this with two different archetypes on two different machines to make sure it was not a problem with AppFuse. I actually built a project with this archetype this weekend. Thank you for any help. Fred -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Examples for scm:checkout Goal
Greetings: We've begun committing release notes to an svn repository. I'd like to extract the document during a release and bundle it with a project artifact via the assembly plugin. I'm attempting to use the scm plugin attached to the 'process-resources' phase in preparation for the assembly, but I think I'm making this too difficult. Can someone direct me to examples showing use of the scm:checkout goal? As simple as that might seem, none of the examples at http://maven.apache.org/scm/plugins/examples/scm-advance-features.html show use of scm:checkout and provide a clear relationship between 'developerConnectionUrl' and the supposedly required parameter 'baseDir'. I've assumed that 'baseDir' refers to a directory in the repository beneath the 'developerConnectionUrl' where the target file(s) are located. Now I've removed baseDir altogether from the plugin configuration, given a complete URL to the repository file in developerConnectionUrl, and get [ERROR] svn: PROPFIND request failed on '/docs/.../release-notes-pdf' svn: PROPFIND of '/docs/.../release-notes-pdf': authorization failed Thanks. Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Missing artifact org.apache.maven.plugins:maven-jetty-plugin
Thank you. I made a silly mistake. -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 5:57 PM To: Maven Users List Subject: Re: Missing artifact org.apache.maven.plugins:maven-jetty-plugin This is not an official plugin, so it has a different groupId than the normal official plugins. Therefor you have to specify the groupId to be able to use it: org.mortbay.jetty:maven-jetty-plugin Brier, Frederick (IHG Temp) wrote: I was attempting to use AppFuse. Created a project from an archetype and then tried mvn jetty:run-war. I got a BUILD ERROR - The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or no valid version could be found. So I checked. Sure enough, the plugin is missing from the repository. How do we request that it be fixed? I double checked this with two different archetypes on two different machines to make sure it was not a problem with AppFuse. I actually built a project with this archetype this weekend. Thank you for any help. Fred -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Examples for scm:checkout Goal
here is an example. http://svn.codehaus.org/mojo/trunk/mojo/pde-maven-plugin/src/it/m2eclipse/pom.xml -D On Tue, Apr 8, 2008 at 3:49 PM, Harper, Brad [EMAIL PROTECTED] wrote: Greetings: We've begun committing release notes to an svn repository. I'd like to extract the document during a release and bundle it with a project artifact via the assembly plugin. I'm attempting to use the scm plugin attached to the 'process-resources' phase in preparation for the assembly, but I think I'm making this too difficult. Can someone direct me to examples showing use of the scm:checkout goal? As simple as that might seem, none of the examples at http://maven.apache.org/scm/plugins/examples/scm-advance-features.html show use of scm:checkout and provide a clear relationship between 'developerConnectionUrl' and the supposedly required parameter 'baseDir'. I've assumed that 'baseDir' refers to a directory in the repository beneath the 'developerConnectionUrl' where the target file(s) are located. Now I've removed baseDir altogether from the plugin configuration, given a complete URL to the repository file in developerConnectionUrl, and get [ERROR] svn: PROPFIND request failed on '/docs/.../release-notes-pdf' svn: PROPFIND of '/docs/.../release-notes-pdf': authorization failed Thanks. Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use assembly and deploy togeather
On 08/04/2008, at 5:15 PM, Michael Mühlebach wrote:
I tried it with this command but my problem is the created zip file
does not contain the deployed jar file. It still has a -SNAPSHOT
postfix which is quite ugly.
On Tue, Apr 8, 2008 at 1:44 AM, Luke Daley [EMAIL PROTECTED] wrote:
On 07/04/2008, at 11:14 PM, Michael Mühlebach wrote:
I want to create an assembly and deploy it but I have some
troubles with
it.
I tried it with the command:
mvn assembly:single deploy
I got almost what I expected except: All artifacts from my project,
including the one I executed maven for, are snapshot versions! (have
the classifier -SNAPSHOT instead of a build date and number).
What have I done wrong or did I misunderstand the assembly/deploy
build
cycle?!
I am not sure exactly what you are trying to do, but if you are
trying to
create another build artifact (such as a distribution zip or
something) and
have it deployed along side your built jars (or whatever) then you
might
want to look at the assembly:attached goal.
http://maven.apache.org/plugins/maven-assembly-plugin/attached-
mojo.html
The name of the built assembly is defined by…
http://maven.apache.org/plugins/maven-assembly-plugin/single-
mojo.html#finalName
That documentation says that the default value for that is $
{project.build.finalName} which if you look at the maven model…
http://maven.apache.org/ref/2.0.8/maven-model/
maven.html#class_build(look for finalName)
Is ${artifactId}-${version}. You are building something with a
version of SNAPSHOT which has special significance with maven projects.
You mention build date and number, there is no reason you couldn't do
that by specifying the finalName parameter in the configuration of
your assembly:single execution. Maven doesn't support build numbers
out of the box (AFAIK), but there is a plugin http://
commons.ucalgary.ca/projects/maven-buildnumber-plugin/
introduction.html.
LD.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
exec:java in multi project environments
Hi, I'm having a bit of trouble with the exec-maven-plugin. I've got a project setup with two sub-modules, and when I run the exec plugin on a main class that is in one module that depends on another, I get an error that the dependancy module is not in the repository. I don't want to have to install the project just to exec it, and unit testing works with dependancies without installing, so I'm a bit puzzled. Any help would be greatly appreciated. Here is a more concrete example: MyProj +---ModuleA +---ModuleB ModuleB depends on ModuleA and has a class with a main function. If I run mvn compile exec:java - Dexec.mainClass=MyProj.ModuleB.MyClass INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) MyProj:ModuleA.jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=MyProj -DartifactId=ModuleA - Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=MyProj -DartifactId=ModuleA - Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] - DrepositoryId=[id] Path to dependency: 1) MyProj:ModuleA.jar:1.0-SNAPSHOT 2) MyProj:ModuleB.jar:1.0-SNAPSHOT -- Joshua ChaitinPollak | Software Engineer Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970
Re: Classpath Loader Differences between Surefire 2.3 and 2.4 causes tests to fail
Andreas Guther wrote: Does anyone have an idea how to solve this issue and get the classes back on the path under Surefire 2.4? This is a somewhat frequently asked question, so I've written a wiki article about it: http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+Surefire Executive summary: useSystemClassLoader changed between Surefire 2.3 and Surefire 2.4. The default was useSystemClassLoader=false, but now the default is useSystemClassLoader=true. If you're having problems, try turning it back off to see if that helps. I've also written another article about classpath ordering (not relevant to you, but it has come up a few times): http://docs.codehaus.org/display/MAVENUSER/Classpath+Ordering+Bugs+in+Maven+Surefire -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Classpath Loader Differences between Surefire 2.3 and 2.4 causes tests to fail
The solution to the problem is to configure Surefire 2.4.2 to not use
the System Classloader,
i.e in the following way:
configurationuseSystemClassLoaderfalse/useSystemClassLoader/confi
guration
Or in more details:
properties
maven-surefire-plugin-version2.4.2/maven-surefire-plugin-version
testing-testng-version5.7/testing-testng-version
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version${maven-surefire-plugin-version}/version
configuration
useSystemClassLoaderfalse/useSystemClassLoader
/configuration
/plugin
/plugins
/build
Dan Fabulich explained to me that this was the default behavior in
Surefire 2.3 and that it was reversed in Surefire 2.4.
-Original Message-
From: Andreas Guther [mailto:[EMAIL PROTECTED]
Sent: Monday, April 07, 2008 12:07 PM
To: Maven Users List
Subject: Classpath Loader Differences between Surefire 2.3 and 2.4
causes tests to fail
Hi,
We see a difference in classpath loading between Surefire 2.3 and 2.4.
If we run the attached test against Surefire 2.3 and TestNG 5.1 we get
the following output:
mvn test -Pthree
---
T E S T S
---
Running ShowClassPathTest
On my
path:file:/C:/dev/svn.markettools.com/repos/dev/projects/problem/target/
test-classes/
On my
path:file:/c:/m2/repo1/commons-collections/commons-collections/3.1/commo
ns-collections-3.1.jar
On my
path:file:/C:/dev/svn.markettools.com/repos/dev/projects/problem/target/
classes/
On my
path:file:/c:/m2/repo1/commons-io/commons-io/1.2/commons-io-1.2.jar
On my path:file:/c:/m2/repo1/org/testng/testng/5.1/testng-5.1-jdk15.jar
Number of elemenst on my path:5
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031
sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
If we run the same test with Surefire 2.4 and TestNG 5.7 we get a
totally different classpath:
mvn test -Pfour
---
T E S T S
---
Running TestSuite
[Parser] Running:
Command line suite
On my
path:file:/C:/Documents%20and%20Settings/aguther/Local%20Settings/Temp/s
urefirebooter7279.jar
On my path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/sunpkcs11.jar
On my path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/dnsns.jar
On my
path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/sunjce_provider.jar
On my
path:file:/C:/usr/local/java/jdk1.5.0_10/jre/lib/ext/localedata.jar
Number of elemenst on my path:5
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.235
sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Obviously in the second case none of the dependencies or compile
directories are available.
The different behavior gives us problems with the Web Framework we use
(Stripes 1.4) and the associated tests which are not able to find any
classes under Surefire 2.4. Stripes uses the following line to load the
classes: ClassLoader loader =
Thread.currentThread().getContextClassLoader();
Does anyone have an idea how to solve this issue and get the classes
back on the path under Surefire 2.4?
Thanks in advance for any help.
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: exec:java in multi project environments
Correction to my previous post: I realize now that the problem described below is actually caused by my helper script changing into the ModuleB directory before running the command below, which would understandably cause the problem described. HOWEVER, I am still having a problem, which is actually best described in this post: http://www.nabble.com/Maven-exec:java-ClassNotFoundException-td15613520s177.html Is there a solution to this? It sounds like if the class is not found, we'd like the plugin to not fail, but keep running, to allow the plugin to try again on the sub-modules. Is that possible? -Josh On Apr 8, 2008, at 11:01 PM, Joshua ChaitinPollak wrote: Hi, I'm having a bit of trouble with the exec-maven-plugin. I've got a project setup with two sub-modules, and when I run the exec plugin on a main class that is in one module that depends on another, I get an error that the dependancy module is not in the repository. I don't want to have to install the project just to exec it, and unit testing works with dependancies without installing, so I'm a bit puzzled. Any help would be greatly appreciated. Here is a more concrete example: MyProj +---ModuleA +---ModuleB ModuleB depends on ModuleA and has a class with a main function. If I run mvn compile exec:java - Dexec.mainClass=MyProj.ModuleB.MyClass INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) MyProj:ModuleA.jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=MyProj -DartifactId=ModuleA - Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=MyProj -DartifactId=ModuleA - Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) MyProj:ModuleA.jar:1.0-SNAPSHOT 2) MyProj:ModuleB.jar:1.0-SNAPSHOT -- Joshua ChaitinPollak | Software Engineer Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 -- Joshua ChaitinPollak | Software Engineer Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970
[ANNOUNCE] Apache Archiva 1.0.2 Released
The Apache Archiva team is pleased to announce the release of Archiva 1.0.2 Archiva is a build artifact repository manager for use with build tools such as Maven, Continuum and Ant. It has features like repository search and browse, securing repositories, identifying unknown artifacts and reporting of repository problems. Aside from these, it can also act as a nearby (proxy) cache of popular global repositories. The latest release is now available here: http://maven.apache.org/archiva/download.html If you have any questions, please consult: - the web site: http://maven.apache.org/archiva/ - the archiva-user mailing list: http://maven.apache.org/archiva/mail-lists.html New in Archiva 1.0.2 * Configurable Proxy Error Handling Two new options have been added to the proxy connector configuration page: - On remote error - gives control over whether to stop immediately, continue to try for a successful proxy, or ignore an error - Return error when - gives control over whether to return an existing artifact if present or fail regardless if a remote error occurs when updating an artifact Change Log for Archiva 1.0.2 === * [MRM-159] - should not respond with a 404 if proxying a file results in a remote error * [MRM-532] - Unable to specify the location of the index files through the web ui * [MRM-598] - Validation error on new repository creation and other fields under certain conditions * [MRM-608] - Unable to find project model for [...] if the initial import of the POM failed * [MRM-617] - Reporting does not work due to bug in client-side JavaScript validation * [MRM-618] - PLEXUS_BASE does not work for local databases * [MRM-622] - database not being updated with project model information * [MRM-626] - ClassCastException when saving proxy connector with property defined * [MRM-627] - Archiva doesn't download SNAPSHOTs for proxied repositories. * [MRM-642] - archiva-common tests rely on relative paths * [MRM-655] - The logs are duplicated in the archiva.log and wrapper.log file. * [MRM-659] - archiva cannot serve ejb artifacts from a maven1 repository * [MRM-661] - remote repository removals are not saved after restart * [MRM-664] - Cannot download a strut-module artifact in a Legacy repository * [MRM-674] - LayoutException when downloading SNAPSHOT test-sources * [MRM-683] - Archiva version missing from pages and logs * [MRM-687] - Project model cannot be added to database if it inherits groupId and/or version from parent POM * [MRM-689] - Incorrect war name in example for tomcat * [MRM-690] - using undefined appserver.base * [MRM-691] - Can't get any of the consumers to work without through a NPE * [MRM-701] - Buggy documentation on separating the base from the installation * [MRM-703] - Artifacts with extensions longer than fours characters breaks repository scanning. * [MRM-713] - extensionPattern in FilenameParser is incorrect * [MRM-715] - error adding artifacts to Lucene under some circumstances * [MRM-719] - NPE during repository scan * [MRM-725] - /archiva/browse URL does not work on WebSphere * [MRM-727] - Archiva does not download plugin artifacts in Geronimo * [MRM-734] - Unable to update metadata - No versions found for reference * [MRM-746] - unable to include *.xml in artifacts list as it picks up maven-metadata.xml * [MRM-750] - Adding a network proxy doesn't require an identifier * [MRM-755] - No content type for .pom files denoted in file archiva-mime-types.txt - workaround included * [MRM-758] - unable to schedule cron expressions that contain a comma * [MRM-761] - Exception when trying to retrieve a Maven 1 artifact of type zip * [MRM-762] - Footer doesn't stretch across repositoryScanning and database pages * [MRM-763] - Default cron expression for database update is invalid * [MRM-764] - default policies are not selected in the add proxy connector page * [MRM-504] - Find Artifact page needs more onscreen information/ instructions * [MRM-656] - Admin guide for installing WAR needs updating * [MRM-666] - Edit Managed Repository page should indicate the repo id being edited * [MRM-700] - Review the documentation on deploying to Archiva for inconsistent repository ids * [MRM-720] - Upgrade Lucene from 2.0 to 2.3.1 Thanks, The Apache Archiva team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Sonatype Nexus 1.0-beta-2 Released
Hi, The Sonatype gang are pleased to announce the release of Nexus 1.0- beta-2. We're pushing hard to try and get the 1.0 out the door. You can see Brian's blog entry here about it here: http://blogs.sonatype.com/brian/2008/04/08/1207707783272.html And you can download it here: http://nexus.sonatype.org/downloads/ Also please join us in IRC and our mailing lists: irc.codehaus.org:6667 #nexus [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding a Main-Class to a jar-with-dependencies jar?
Hey all, http://docs.codehaus.org/pages/viewpage.action?pageId=72602 shows how to set the Main-Class for a .jar file using the maven-jar-plugin and thats fine, but I was wondering if this could also be applied to the jar being made from the assembly plugin somehow? Do I need to make a custom assembly descriptor for this? Thanks, Mark -- It is easier to optimize correct code than to correct optimized code. -- Bill Harlan
Newer Jar Override
Hi All. The org.apache.maven.plugins:maven-checkstyle-plugin dependon upon checkstyle 4.1. I'd like to use checkstyle 4.4 (that matches by eclipse version). Is there any way to override it and get it to use 4.4 instead of 4.1? TIA, -Chris ** CAUTION - This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must: - Not use, copy, distribute or disclose it to anyone other than the addressee; - Notify the sender via return email; and - Delete the message (and any related attachments) from your computer immediately. Internet emails are not necessarily secure. Australian Associated Motors Insurers Limited ABN 92 004 791 744 (AAMI), and its related entities, do not accept responsibility for changes made to this message after it was sent. Unless otherwise stated, views expressed within this email are the author's own and do not represent those of AAMI. **
Re: exec:java in multi project environments
I've discovered my problem and submitted a patch for the exec-maven- plugin: http://jira.codehaus.org/browse/MEXEC-43 On Apr 8, 2008, at 11:01 PM, Joshua ChaitinPollak wrote: Hi, I'm having a bit of trouble with the exec-maven-plugin. I've got a project setup with two sub-modules, and when I run the exec plugin on a main class that is in one module that depends on another, I get an error that the dependancy module is not in the repository. I don't want to have to install the project just to exec it, and unit testing works with dependancies without installing, so I'm a bit puzzled. Any help would be greatly appreciated. Here is a more concrete example: MyProj +---ModuleA +---ModuleB ModuleB depends on ModuleA and has a class with a main function. If I run mvn compile exec:java - Dexec.mainClass=MyProj.ModuleB.MyClass INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) MyProj:ModuleA.jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=MyProj -DartifactId=ModuleA - Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=MyProj -DartifactId=ModuleA - Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) MyProj:ModuleA.jar:1.0-SNAPSHOT 2) MyProj:ModuleB.jar:1.0-SNAPSHOT -- Joshua ChaitinPollak | Software Engineer Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 -- Joshua ChaitinPollak | Software Engineer Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970
