Re: Metrics Gathering & Tracking
Rahul Thakur wrote: Jesse McConnell wrote: I was figuring we would add something like this as some kinda continuum extension for when the workflow is added to the continuum object. Is this going to be impelmented using plexus-spe or OS workflow? os-workflow is not what Continuum need, I tried that once (had a branch for it at one point). Plexus-spe should be a good start for Continuum, but it needs to be improved to be very useful. -- Trygve
cmd line property is ignored - bug? (and which jira component to file in?)
[based on the almost latest m2.0.5 branch]
I have this profile in my pom.xml:
development
true
true
${no.daisy.test}
So without my settings.xml "mvn install" doesn't run the tests.
But in my settings.xml I have a profile like this:
daisy_1_5
false
...
So now "mvn install" does run the tests.
However when I now try
mvn -Dmaven.test.skip install
The tests are still run,
while I expected my cmd line variable to overwrite my pom.xml and
setting.xml properties.
Is this a known bug? or shall I file a jira (and in which component)?
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r497679 - /maven/core-integration-testing/trunk/core-integration-tests/pom.xml
the test projects also get jarred, the problem I didn't see is that generated stuff like target also gets included. Still looking to a solution to reuse the tests in other environments like insie eclipse. On 1/18/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: What are you doing? The tests by themselves aren't of much use without the test projects. You JAR up the tests and they run against nothing. Jason. On 18 Jan 07, at 7:37 PM 18 Jan 07, [EMAIL PROTECTED] wrote: > Author: carlos > Date: Thu Jan 18 17:37:00 2007 > New Revision: 497679 > > URL: http://svn.apache.org/viewvc?view=rev&rev=497679 > Log: > jar the tests for use in other projects > > Modified: > maven/core-integration-testing/trunk/core-integration-tests/ > pom.xml > > Modified: maven/core-integration-testing/trunk/core-integration- > tests/pom.xml > URL: http://svn.apache.org/viewvc/maven/core-integration-testing/ > trunk/core-integration-tests/pom.xml? > view=diff&rev=497679&r1=497678&r2=497679 > == > > --- maven/core-integration-testing/trunk/core-integration-tests/ > pom.xml (original) > +++ maven/core-integration-testing/trunk/core-integration-tests/ > pom.xml Thu Jan 18 17:37:00 2007 > @@ -20,6 +20,17 @@ >never > > > + > +org.apache.maven.plugins > +maven-jar-plugin > + > + > + > + test-jar > + > + > + > + > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r497679 - /maven/core-integration-testing/trunk/core-integration-tests/pom.xml
What are you doing? The tests by themselves aren't of much use without the test projects. You JAR up the tests and they run against nothing. Jason. On 18 Jan 07, at 7:37 PM 18 Jan 07, [EMAIL PROTECTED] wrote: Author: carlos Date: Thu Jan 18 17:37:00 2007 New Revision: 497679 URL: http://svn.apache.org/viewvc?view=rev&rev=497679 Log: jar the tests for use in other projects Modified: maven/core-integration-testing/trunk/core-integration-tests/ pom.xml Modified: maven/core-integration-testing/trunk/core-integration- tests/pom.xml URL: http://svn.apache.org/viewvc/maven/core-integration-testing/ trunk/core-integration-tests/pom.xml? view=diff&rev=497679&r1=497678&r2=497679 == --- maven/core-integration-testing/trunk/core-integration-tests/ pom.xml (original) +++ maven/core-integration-testing/trunk/core-integration-tests/ pom.xml Thu Jan 18 17:37:00 2007 @@ -20,6 +20,17 @@ never + +org.apache.maven.plugins +maven-jar-plugin + + + + test-jar + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: short term branch for project/group keys
Hey Jesse, I am gonna fork a new branch tonight and get started on this change. Hopefully should be able to get the relevant stuff that we have already done merged on the core modules before we start playing with the other modules tomorrow :-) Cheers, Rahul Jesse McConnell wrote: I am loathe to let a branch lay around for a long time with minimal work being done actively on it and we learned what we wanted to from it in the short time we worked with it I think. my take-away was that the change the string based keys will be a good change but its large enough that it should be done in the context of some other refactoring and changes. as for the int->long id change, I think its a good thing and will focus us to address the database upgrading issue so its all good imo :) jesse On 1/16/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: Jesse and myself had a chat yesterday morning about the key-refactoring branch that we spun before Christmas last year, and we reckon that it might be an idea to get 1.1-alpha rolling and meantime gather more thoughts around Groupings (introduce versions/tags). We think having String-based keys for groups might be more feasible for v1.2. However, we are keen to bring over the API changes where the 'int' Ids are now converted to 'long'. Some other bits like breaking up the existing Project and ProjectGroup interfaces can be continued on the trunk itself after the merge. What do others think? Cheers, Rahul - Original Message - From: "Jesse McConnell" <[EMAIL PROTECTED]> To: Sent: Friday, December 22, 2006 8:30 AM Subject: short term branch for project/group keys >I am thinking about pulling a short term branch of continuum with > rahul and working on getting everything converted to using a string > based key project and project group reference in all apis and in all > of the UI decision making items. He has tomorrow off so I think that > unless anyone has any big issues with it we'll try and make that > branch and work on it tomorrow. > > the end result of it would be: > > * int id's for project and project group in the model are for internal > store usage > * name's for project and project group are for presentation purposes > only > * key's are for all api usage and passing around un URL's etc. > > some quick benefits are: > > * consistency across all apis and url manipulations > * ability to add quick url rewriting for direct linking of projects > foo.org/Doxia/Core > * common keys across running continuum instances for clustering > > jesse > > -- > jesse mcconnell > [EMAIL PROTECTED]
[jira] Subscription: Design & Best Practices
Issue Subscription Filter: Design & Best Practices (37 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-2477Implement repository security improvements for verification of downloaded artifacts http://jira.codehaus.org/browse/MNG-2477 MNG-2642maven-archetype-webapp does not produce Standard Directory Layout http://jira.codehaus.org/browse/MNG-2642 MNG-1305Document Maven's own development process http://jira.codehaus.org/browse/MNG-1305 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-1936pattern: for mojo parameters which have default values in the POM we need standard usage http://jira.codehaus.org/browse/MNG-1936 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1634move maven-core-it to integration-tests http://jira.codehaus.org/browse/MNG-1634 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-1452best practices: deployment of aggregate JARs produced by the assembly plug-in http://jira.codehaus.org/browse/MNG-1452 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-939 specify maven settings from command line http://jira.codehaus.org/browse/MNG-939 MNG-139 server definitions should be reusable http://jira.codehaus.org/browse/MNG-139 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-905 review clean repo install of m2 for download trimming http://jira.codehaus.org/browse/MNG-905 MNG-140 refactor maven-artifact http://jira.codehaus.org/browse/MNG-140 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1437How to make additions to the POM and have it be backward/forward compatible http://jira.codehaus.org/browse/MNG-1437 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-868 Use uniform format for and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
On 1/19/07, berndq <[EMAIL PROTECTED]> wrote: Hi Barrie, thanks for your help > Cant you just define multiple configurations, where each configuration > has the settings you want rather than lump them in the one section? Please paste your plugin definition in your pom. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
Hi Barrie, thanks for your help Cant you just define multiple configurations, where each configuration has the settings you want rather than lump them in the one section? this results in [INFO] [INFO] No assembly descriptors found. [INFO] [DEBUG] Trace org.apache.maven.BuildFailureException: No assembly descriptors found. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException: No assembly descriptors found. at org.apache.maven.plugin.assembly.AbstractAssemblyMojo.readAssemblies(AbstractAssemblyMojo.java:773) at org.apache.maven.plugin.assembly.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:233) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more for me. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r496027 - in /maven/plugins/trunk/maven-source-plugin/src: main/java/org/apache/maven/plugin/source/ test/java/org/apache/maven/plugin/source/ test/resources/unit/custom-configuration/
Jason,
Would you mind commenting on this check-in at:
http://jira.codehaus.org/browse/MSOURCES-6
I'm sure many of the voters are eager to try out the new code and see if
it has solved their problem, even if it means building the plugin from
themselves.
--
Dennis Lundberg
[EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sat Jan 13 19:36:16 2007
New Revision: 496027
URL: http://svn.apache.org/viewvc?view=rev&rev=496027
Log:
o little refactoring and did MSOURCES-11 and MSOURCES-6 but I need to add a
test for that yet.
Added:
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
- copied, changed from r495459,
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AggregatorSourceJarMojo.java
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/SourceJarMojo.java
- copied, changed from r495459,
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/JarDefaultSourceMojo.java
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/TestSourceJarMojo.java
- copied, changed from r495459,
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/JarTestSourceMojo.java
maven/plugins/trunk/maven-source-plugin/src/test/java/org/apache/maven/plugin/source/SourceJarMojoTest.java
- copied, changed from r495459,
maven/plugins/trunk/maven-source-plugin/src/test/java/org/apache/maven/plugin/source/JarDefaultSourceMojoTest.java
maven/plugins/trunk/maven-source-plugin/src/test/java/org/apache/maven/plugin/source/TestSourceJarMojoTest.java
- copied, changed from r495459,
maven/plugins/trunk/maven-source-plugin/src/test/java/org/apache/maven/plugin/source/JarTestSourceMojoTest.java
Removed:
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/JarDefaultSourceMojo.java
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/JarTestSourceMojo.java
maven/plugins/trunk/maven-source-plugin/src/test/java/org/apache/maven/plugin/source/JarDefaultSourceMojoTest.java
maven/plugins/trunk/maven-source-plugin/src/test/java/org/apache/maven/plugin/source/JarTestSourceMojoTest.java
Modified:
maven/plugins/trunk/maven-source-plugin/src/test/resources/unit/custom-configuration/custom-configuration-config.xml
maven/plugins/trunk/maven-source-plugin/src/test/resources/unit/default-configuration/default-configuration-config.xml
maven/plugins/trunk/maven-source-plugin/src/test/resources/unit/invalid-packaging/invalid-packaging-config.xml
Copied:
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
(from r495459,
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java)
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java?view=diff&rev=496027&p1=maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java&r1=495459&p2=maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java&r2=496027
==
---
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java
(original)
+++
maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java
Sat Jan 13 19:36:16 2007
@@ -31,10 +31,11 @@
import java.io.File;
import java.io.IOException;
+import java.util.Arrays;
import java.util.Iterator;
import java.util.List;
-public abstract class AbstractJarSourceMojo
+public abstract class AbstractSourceJarMojo
extends AbstractMojo
{
private static final String[] DEFAULT_INCLUDES = new String[]{"**/*",};
@@ -94,113 +95,145 @@
*/
protected String finalName;
-/** @see org.apache.maven.plugin.AbstractMojo#execute() */
-public abstract void execute()
-throws MojoExecutionException;
+//MAPI: how to programatically tell maven we will do aggregation, so that
I don't have to create a separate mojo.
+// we just want to do the right thing 99% of the time. Would be know
by running with other goals what to do.
+// sources/javadoc: what are the cases
+//
+//MAPI: how to make this backward compatible
-public MavenProject getProject()
-{
-return project;
-}
+/** @parameter expression="${aggregate}" default
Re: Spring Repo Sync
it's one automatically, no need to ask, thanks On 1/18/07, Ben Hale <[EMAIL PROTECTED]> wrote: We've posted new releases for spring-ldap 1.1.1, spring-ldap 1.1.2, and spring-webflow 1.0.1. Please sync the repository against the main maven repo. Thanks. -Ben -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Source Archives: Source Plugin vs. Assembly Plugin
Kenny, I definitely overlooked the generated sources. The rest of it seems pretty superficial, but there definitely doesn't seem to be a very good way to collect those generated sources via the assembly plugin. Thanks for the insight. On 1/18/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote: Hi, the sources and javadoc jars can be used for IDE's. For instance, in eclipse, if you have a jar classpath element, you only get the binary, and no javadoc or other functionality. If you attach the source or javadoc to that jar classpath entry, that helps with programming in terms of documentation and in terms of debugging and tracing. That's why those plugins exist. I think you're using the 'src' assembly descriptor. If so, here are the differences between using that and the source plugin: - the source plugin knows about all the project sources, even generated ones, and the assembly plugin doesn't. The descriptor has 'src/' hardcoded in it. The assembly plugin only knows files, directories, dependencies and modules. - The 'src' assembly descriptor in the assembly plugin packages up the 'src/' dir, harcoded. Say you have some plugin that generates sources (like antlr) hooked up in your pom that uses src/main/antlr/grammar.g to generate target/generated-sources/antlr/my/package/Parser.java. Now if you list the contents of the assembly archive it will be src/main/java/my/package/My.java src/main/resources/app.properties src/main/antlr/grammar.g The contents of the source jar will be: my/package/My.java my/package/Parser.java app.properties - The assembly descriptor generates a tar.bz2, tar.gz and a zip. The source plugin generates a jar. - The source:jar and javadoc:jar are both automatically executed during a release or deployment of a non-snapshot artifact, and both jar archives will be deployed. The assembly plugin will not automatically be called. As for javadoc, the javadoc plugin knows where it generated the javadoc api documentation and knows what to zip up. With the assembly plugin you'd have to make a custom descriptor, duplicating some configuration. Hope it's a bit clearer now. -- Kenney Gregory Kick wrote: > I originally started this thread on the users list and Franz suggested > that we move it over to the dev list. Does anybody have any thoughts > on all of this? > > -- Forwarded message -- > From: Gregory Kick <[EMAIL PROTECTED]> > Date: Jan 17, 2007 11:10 PM > Subject: Re: Source Archives: Source Plugin vs. Assembly Plugin > To: Maven Users List > > > Franz, > > On 1/14/07, franz see <[EMAIL PROTECTED]> wrote: >> >> Good day to you, Gregory, >> >> Actually, the plugin does not define the lifecycle. Rather, it's the >> packaging type which defines the default goal bindings to the lifecycle >> phases. > > That's what I meant. Sorry for misspeaking. > >> >> Regarding consolidating the functionality in order to minimize the effort >> across pugins - if you're referring to implementation-wise, I think >> they are >> using a common component for the assembly. > > I hadn't really looked into it in the source, but like I said in the > my message to Dennis, we end up with multiple goals with the same > parameters. Not a huge deal, but it seems a bit silly... > >> >> Also, IMHO, eventhough source and javadoc are both "auxiliary" artifacts, >> they're both common functionalities just like the jars, wars, etc. >> Thus, I >> don't find any fault with the existence of source:jar and javadoc:jar. >> The >> assembly plugin is usually used for the uncommon use cases. > > Yes, I think that that is what Dennis was saying as well. My thought > was that now that the assembly plugin seems to have matured into > something more stable, it might be worth using it in the common cases > as well. > >> >> As for knowing all the artifacts being generated by a build, maybe >> creating >> a report would be better ( though I am not sure how though :) ). > > Actually, I made one. It was a pain to get it to work correctly and > it's pretty hackish. I'd much rather just be able to manage the > assembly plugin and be done with it. > >> >> But if you want, you can take this up in the maven dev list to get more >> inputs :) > > Alright, lets see what they have to say. > >> >> Just my 2 cents worth. >> Franz >> >> >> Gregory Kick-2 wrote: >> > >> > Franz, >> > >> > The difference that I see between the sources and javadoc plugins and >> > jar, war, etc. is that plugins like the jar plugin actually define the >> > lifecycle for that particular packaging. Since source and javadoc >> > jars are "auxiliary" artifacts, it seems as though it would make more >> > sense to consolidate that functionality in order to minimize effort >> > across the plugins. Also, it seems like it would be much more >> > convenient to look look at the descriptorRefs tag and see __every__ >> > artifact that was being generated (aside from the default, "main" >> > artifact). >> > >> >
Re: Metrics Gathering & Tracking
On 1/18/07, Erik Bengtson <[EMAIL PROTECTED]> wrote: Please let me know if there are metrics you would like to collect from the store (JPOX). I will make a list of the various metrics I was thinking of collecting. We should probably define some sort of interface that anybody can implement and "add to the list" whenever there's more metrics to be gathered.
Re: Generating a Maven2 Repository RPM Mirror
archiva has already code that indexes the repo, you may take a look there On 1/18/07, Ole Ersoy <[EMAIL PROTECTED]> wrote: Hey Wayne, Thanks for the tip. I thought that was the case, just wanted to be sure. Yes, I am planning on generating an RPM mirror of the entire ibiblio repo. So I'll use your approach (Using a mojo) to write the "global" maven-metadata.xml file. Then suck that into a mojo, that generates the RPM mirror. Meanwhile hopefully archiva will address creating and updating this type of file on the fly, for this type of scenario. Thanks, - Ole --- Wayne Fay <[EMAIL PROTECTED]> wrote: > I'm not aware of any "file" which contains this kind > of information. > All of this information already exists in the local > repo itself -- the > repo is the documentation in and of itself -- you > just have to look at > every single file in the repo to build it up. The > checksums are in the > .sha1 and .md5 files and the *.pom files will give > you the information > you need about the artifactId, groupId, and version. > > So it sounds like step one of your project is to > write some code (Perl > etc) that scans the local repo and generates this > meta-data.xml file > you're looking for. Unless of course you're talking > about generating a > RPM mirror of the Maven repo hosted at ibiblio or > another site, which > would certainly complicate things a bit. > > Wayne > > On 1/17/07, Ole Ersoy <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I need to generate an RPM mirror of the maven > > repository. > > > > I was hoping to do this by reading something like > a > > meta-data.xml file in the Maven repository, that > > contains a list of all the projects in the > repository, > > their corresponding artifactId, groupId, and > version > > (And checksum would be really nice if there.). > > > > Anywone know if this type of information exists in > the > > Maven repository? > > > > Thanks, > > - Ole > > > > > > > > > > > > > Sucker-punch spam with award-winning protection. > > Try the free Yahoo! Mail Beta. > > > http://advision.webevents.yahoo.com/mailbeta/features_spam.html > > > > > - > > 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] > > TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating a Maven2 Repository RPM Mirror
Hey Wayne, Thanks for the tip. I thought that was the case, just wanted to be sure. Yes, I am planning on generating an RPM mirror of the entire ibiblio repo. So I'll use your approach (Using a mojo) to write the "global" maven-metadata.xml file. Then suck that into a mojo, that generates the RPM mirror. Meanwhile hopefully archiva will address creating and updating this type of file on the fly, for this type of scenario. Thanks, - Ole --- Wayne Fay <[EMAIL PROTECTED]> wrote: > I'm not aware of any "file" which contains this kind > of information. > All of this information already exists in the local > repo itself -- the > repo is the documentation in and of itself -- you > just have to look at > every single file in the repo to build it up. The > checksums are in the > .sha1 and .md5 files and the *.pom files will give > you the information > you need about the artifactId, groupId, and version. > > So it sounds like step one of your project is to > write some code (Perl > etc) that scans the local repo and generates this > meta-data.xml file > you're looking for. Unless of course you're talking > about generating a > RPM mirror of the Maven repo hosted at ibiblio or > another site, which > would certainly complicate things a bit. > > Wayne > > On 1/17/07, Ole Ersoy <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I need to generate an RPM mirror of the maven > > repository. > > > > I was hoping to do this by reading something like > a > > meta-data.xml file in the Maven repository, that > > contains a list of all the projects in the > repository, > > their corresponding artifactId, groupId, and > version > > (And checksum would be really nice if there.). > > > > Anywone know if this type of information exists in > the > > Maven repository? > > > > Thanks, > > - Ole > > > > > > > > > > > > > Sucker-punch spam with award-winning protection. > > Try the free Yahoo! Mail Beta. > > > http://advision.webevents.yahoo.com/mailbeta/features_spam.html > > > > > - > > 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] > > TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: [m2] Adding further dependency goals
Brian E. Fox wrote on Thursday, January 18, 2007 3:34 PM: >> This is true, I haven't used dependency:resolve until you > mentioned it. > I >> guess the only difference is that it doesn't show the scope of the >> dependencies, but this could be easily resolved. > > Heh, actually I just added that feature last night before reading > this thread. (mdep-57). Really cool :D - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Adding further dependency goals
Mark Hobson wrote on Thursday, January 18, 2007 2:52 PM: > On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: >>> Perhaps, but I was thinking about the number of goals once we >>> introduce tree and list goals for every scope. Would we name them >>> dependency:compile-tree, dependency:compile-list, etc.? That's ten >>> extra goals, I'm not sure if it's easier just to type >>> dependency:tree -Dscope=compile. >> >> 10? I just count 6 instead of two ... only 3 scopes make sense - or? > > I was thinking all five scopes for completeness (compile, test, > runtime, provided and system). > >> What about: >> >> dependency: -Dtype= >> >> then everybody has the possibility to configure a property in his >> settings for the preferred view type ... > > I did consider that too, although I don't users would have a preferred > view type - it normally depends on the task at hand. So we need the aliased command with predefined parameters? ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] help with maven API
Thanks Vincent it's awesome -- View this message in context: http://www.nabble.com/-m2--help-with-maven-API-tf3033510s177.html#a8433298 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Spring Repo Sync
We've posted new releases for spring-ldap 1.1.1, spring-ldap 1.1.2, and spring-webflow 1.0.1. Please sync the repository against the main maven repo. Thanks. -Ben smime.p7s Description: S/MIME cryptographic signature
DefaultArtifact.equals ignoring scope
Hi there, On my travels I noticed DefaultArtifact [1] equals and hashCode ignores scope - is that intentional? Could prove to be a problem when check to see if an artifact has moved scope. Mark [1] http://svn.apache.org/repos/asf/maven/components/trunk/maven-artifact/src/main/java/org/apache/maven/artifact/DefaultArtifact.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [m2] Adding further dependency goals
On 18/01/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: >This is true, I haven't used dependency:resolve until you mentioned it. I >guess the only difference is that it doesn't show the scope of the >dependencies, but this could be easily resolved. Heh, actually I just added that feature last night before reading this thread. (mdep-57). Cool, just tried it :) >Yeah that was my problem with the multiple goals, it would start to clutter >the plugin usage. I agree list is similar to resolve. Tree could also be >performed by resolve, but just with a different output format. Maybe list >and tree could be synonyms of resolve, implemented as a simple subclass? Definitely subclasses of resolve. I've been trying to layer the abstract classes in such a way that the parameters are as consistent as possible across all the goals, without implementation duplication. Okay, well I think the dependency plugin is the place for these new goals, so I'll aim to implement them there and reuse your abstract mojos as much as possible. Cheers for the feedback, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Loading a list of all installed repository dependencies
Hi, Does anyone know if there is a "Canned" way of loading all jar packaged artifacts in an M2 repository? I was hoping for something like a maven-metadata.xml file for the entire repository. Thanks, - Ole The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
RE: Re: [m2] Adding further dependency goals
>This is true, I haven't used dependency:resolve until you mentioned it. I >guess the only difference is that it doesn't show the scope of the >dependencies, but this could be easily resolved. Heh, actually I just added that feature last night before reading this thread. (mdep-57). >Yeah that was my problem with the multiple goals, it would start to clutter >the plugin usage. I agree list is similar to resolve. Tree could also be >performed by resolve, but just with a different output format. Maybe list >and tree could be synonyms of resolve, implemented as a simple subclass? Definitely subclasses of resolve. I've been trying to layer the abstract classes in such a way that the parameters are as consistent as possible across all the goals, without implementation duplication. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Want to Setup Internal Repository
Take a look at Archiva: http://maven.apache.org/archiva - still pretty alpha-ish, but we have managed to get it up and running. Works quite well. Mike. On 1/18/07, Fredy <[EMAIL PROTECTED]> wrote: Hi, I want to set up maven internal repository for my company for internal usage. I read from web page that mention not trying to rsync to central repo. What step should i do to enable me to setup internal repo? Any suggestion? Thanks, Fredy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Want to Setup Internal Repository
Hi, I want to set up maven internal repository for my company for internal usage. I read from web page that mention not trying to rsync to central repo. What step should i do to enable me to setup internal repo? Any suggestion? Thanks, Fredy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Adding further dependency goals
On 18/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Here's the output of the dep tree of a single artifact: = %< = [big snip] = %< = We cannot live without this anymore ... it made our release process quite easy and we can detect unwanted deps very early. Nice, looks very similar to the output of help:dependencies. We'd just need to include the filtering functionality really. If we merge help:dependencies with dependency:resolve then it looks like a fair amount of filtering options are already there, so it'd just be a matter of using them. What do you think? BTW: Did I mension, that there's another option to support colouring on ANSI terminals and the matching artifacts are highlighted visually? ;-) Sweet, who needs HTML reports? ;) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [m2] Adding further dependency goals
On 18/01/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: I guess I'm a little behind in this thread: 1st, I think dependency:list is effectively the same as the existing dependency:resolve is it not? The artifacts need to be resolved if you are going to include transitive stuff. This is true, I haven't used dependency:resolve until you mentioned it. I guess the only difference is that it doesn't show the scope of the dependencies, but this could be easily resolved. 2nd, I like this suggestion best so far: "dependency: -Dtype= then everybody has the possibility to configure a property in his settings for the preferred view type ..." Although I'm on the fence about having to make a separate goal for each. I think this is still very close to resolve. It would be nice if there was a way to alias a goal to something that exists and default the params without having to create a whole new class. Yeah that was my problem with the multiple goals, it would start to clutter the plugin usage. I agree list is similar to resolve. Tree could also be performed by resolve, but just with a different output format. Maybe list and tree could be synonyms of resolve, implemented as a simple subclass? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Adding further dependency goals
On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: > Perhaps, but I was thinking about the number of goals once we > introduce tree and list goals for every scope. Would we name them > dependency:compile-tree, dependency:compile-list, etc.? That's ten > extra goals, I'm not sure if it's easier just to type dependency:tree > -Dscope=compile. 10? I just count 6 instead of two ... only 3 scopes make sense - or? I was thinking all five scopes for completeness (compile, test, runtime, provided and system). What about: dependency: -Dtype= then everybody has the possibility to configure a property in his settings for the preferred view type ... I did consider that too, although I don't users would have a preferred view type - it normally depends on the task at hand. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Adding further dependency goals
On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: http://jira.codehaus.org/browse/MNG-2589 (and I detected that I wrote a stupid description ...) Thanks for that, I'm sure there's a few related issues regarding similar functionality I've seen before. > This goal would still help for > detecting unnecessary dependencies - if you're interested, check it > out at: > > http://jira.codehaus.org/browse/MNG-2676 I'll have a look at Friday, tomorrow we'll have release day ;-) Cool, any feedback welcome. There's a few more features I'd like to implement given time. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Source Archives: Source Plugin vs. Assembly Plugin
Hi, the sources and javadoc jars can be used for IDE's. For instance, in eclipse, if you have a jar classpath element, you only get the binary, and no javadoc or other functionality. If you attach the source or javadoc to that jar classpath entry, that helps with programming in terms of documentation and in terms of debugging and tracing. That's why those plugins exist. I think you're using the 'src' assembly descriptor. If so, here are the differences between using that and the source plugin: - the source plugin knows about all the project sources, even generated ones, and the assembly plugin doesn't. The descriptor has 'src/' hardcoded in it. The assembly plugin only knows files, directories, dependencies and modules. - The 'src' assembly descriptor in the assembly plugin packages up the 'src/' dir, harcoded. Say you have some plugin that generates sources (like antlr) hooked up in your pom that uses src/main/antlr/grammar.g to generate target/generated-sources/antlr/my/package/Parser.java. Now if you list the contents of the assembly archive it will be src/main/java/my/package/My.java src/main/resources/app.properties src/main/antlr/grammar.g The contents of the source jar will be: my/package/My.java my/package/Parser.java app.properties - The assembly descriptor generates a tar.bz2, tar.gz and a zip. The source plugin generates a jar. - The source:jar and javadoc:jar are both automatically executed during a release or deployment of a non-snapshot artifact, and both jar archives will be deployed. The assembly plugin will not automatically be called. As for javadoc, the javadoc plugin knows where it generated the javadoc api documentation and knows what to zip up. With the assembly plugin you'd have to make a custom descriptor, duplicating some configuration. Hope it's a bit clearer now. -- Kenney Gregory Kick wrote: I originally started this thread on the users list and Franz suggested that we move it over to the dev list. Does anybody have any thoughts on all of this? -- Forwarded message -- From: Gregory Kick <[EMAIL PROTECTED]> Date: Jan 17, 2007 11:10 PM Subject: Re: Source Archives: Source Plugin vs. Assembly Plugin To: Maven Users List Franz, On 1/14/07, franz see <[EMAIL PROTECTED]> wrote: Good day to you, Gregory, Actually, the plugin does not define the lifecycle. Rather, it's the packaging type which defines the default goal bindings to the lifecycle phases. That's what I meant. Sorry for misspeaking. Regarding consolidating the functionality in order to minimize the effort across pugins - if you're referring to implementation-wise, I think they are using a common component for the assembly. I hadn't really looked into it in the source, but like I said in the my message to Dennis, we end up with multiple goals with the same parameters. Not a huge deal, but it seems a bit silly... Also, IMHO, eventhough source and javadoc are both "auxiliary" artifacts, they're both common functionalities just like the jars, wars, etc. Thus, I don't find any fault with the existence of source:jar and javadoc:jar. The assembly plugin is usually used for the uncommon use cases. Yes, I think that that is what Dennis was saying as well. My thought was that now that the assembly plugin seems to have matured into something more stable, it might be worth using it in the common cases as well. As for knowing all the artifacts being generated by a build, maybe creating a report would be better ( though I am not sure how though :) ). Actually, I made one. It was a pain to get it to work correctly and it's pretty hackish. I'd much rather just be able to manage the assembly plugin and be done with it. But if you want, you can take this up in the maven dev list to get more inputs :) Alright, lets see what they have to say. Just my 2 cents worth. Franz Gregory Kick-2 wrote: > > Franz, > > The difference that I see between the sources and javadoc plugins and > jar, war, etc. is that plugins like the jar plugin actually define the > lifecycle for that particular packaging. Since source and javadoc > jars are "auxiliary" artifacts, it seems as though it would make more > sense to consolidate that functionality in order to minimize effort > across the plugins. Also, it seems like it would be much more > convenient to look look at the descriptorRefs tag and see __every__ > artifact that was being generated (aside from the default, "main" > artifact). > > Aside from it already being implemented, was there a specific reason > for sources and javadoc to create their own jars? > > On 1/12/07, franz see <[EMAIL PROTECTED]> wrote: >> >> Good day to you, Gregory, >> >> I think it is simply for ease of use. Intead of configuring the assembly >> plugin, you can simply do mvn sources:jar. Same goes for the other >> packaing >> goals ( jar:jar, javadoc:jar, ejb:ejb, ejb3:ejb3, war:war, ear:ear, etc >> ). >> Usually, you don'
Re: [m2] help with maven API
Hi again,
You could use the RegexBasedInterpolator class from plexus-utils.
Something like the following:
RegexBasedInterpolator interpolator = new RegexBasedInterpolator();
interpolator.addValueSource( new ObjectBasedValueSource( aProject ) );
interpolator.addValueSource( new MapBasedValueSource(
aProject.getProperties() ) );
String result = interpolator.interpolate( aStringWithInterpolatedProp,
"project" );
Cheers,
Vincent
2007/1/18, dvicente <[EMAIL PROTECTED]>:
Thanks Vincent, it works great but my second question is :
How to resolve maven properties resolution ?
if i configure my pom as :
org.apache.maven.plugins
maven-surefire-plugin
2.2
true
${project.build.directory}/site/sunfire-reports
when i use the getMavenPluginConfiguration method,
i get "${project.build.directory}/site/sunfire-reports" string.
it exists a method which can resolve "${project.build.directory}" string to
a real file path ?
Vincent Siveton wrote:
>
> Hi David,
>
> Have a glance to
>
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-ant-plugin/src/main/java/org/apache/maven/plugin/ant/AntBuildWriterUtil.java
>
> Specially #getMavenPluginConfiguration() HTH
>
> Cheers,
>
> Vincent
>
> 2007/1/18, dvicente <[EMAIL PROTECTED]>:
>>
>> Hello with all, I am improving my plugin Dashboard (
>> http://mojo.codehaus.org/dashboard-maven-plugin/
>> http://mojo.codehaus.org/dashboard-maven-plugin/ ).
>>
>> I have a small concern.
>> I wish to be able to recover the configuration of the plugin Surefire via
>> API Maven, in particular the property "reportsDirectory".
>>
>> What enabled me to avoid adding a parameter config on my plugin but
>> especially in the case of a multi-module project, it may be that this
>> value
>> is not the same one for each module and thus my paramétre would not be
>> good
>> any more from one module to another.
>>
>> I want to be able to be sure to be able to recover the absolute path
>> parameter "reportsDirectory" of Surefire for each module while passing by
>> the API one.
>>
>> If somebody has an idea of API which could do that? (Plexus, Maven
>> Model….)
>>
>> thank you in advance for your assistance
>> --
>> View this message in context:
>> http://www.nabble.com/-m2--help-with-maven-API-tf3033510s177.html#a8428681
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/-m2--help-with-maven-API-tf3033510s177.html#a8430267
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] help with maven API
Thanks Vincent, it works great but my second question is :
How to resolve maven properties resolution ?
if i configure my pom as :
org.apache.maven.plugins
maven-surefire-plugin
2.2
true
${project.build.directory}/site/sunfire-reports
when i use the getMavenPluginConfiguration method,
i get "${project.build.directory}/site/sunfire-reports" string.
it exists a method which can resolve "${project.build.directory}" string to
a real file path ?
Vincent Siveton wrote:
>
> Hi David,
>
> Have a glance to
> https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-ant-plugin/src/main/java/org/apache/maven/plugin/ant/AntBuildWriterUtil.java
>
> Specially #getMavenPluginConfiguration() HTH
>
> Cheers,
>
> Vincent
>
> 2007/1/18, dvicente <[EMAIL PROTECTED]>:
>>
>> Hello with all, I am improving my plugin Dashboard (
>> http://mojo.codehaus.org/dashboard-maven-plugin/
>> http://mojo.codehaus.org/dashboard-maven-plugin/ ).
>>
>> I have a small concern.
>> I wish to be able to recover the configuration of the plugin Surefire via
>> API Maven, in particular the property "reportsDirectory".
>>
>> What enabled me to avoid adding a parameter config on my plugin but
>> especially in the case of a multi-module project, it may be that this
>> value
>> is not the same one for each module and thus my paramétre would not be
>> good
>> any more from one module to another.
>>
>> I want to be able to be sure to be able to recover the absolute path
>> parameter "reportsDirectory" of Surefire for each module while passing by
>> the API one.
>>
>> If somebody has an idea of API which could do that? (Plexus, Maven
>> Model….)
>>
>> thank you in advance for your assistance
>> --
>> View this message in context:
>> http://www.nabble.com/-m2--help-with-maven-API-tf3033510s177.html#a8428681
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/-m2--help-with-maven-API-tf3033510s177.html#a8430267
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Metrics Gathering & Tracking
Please let me know if there are metrics you would like to collect from the store (JPOX). Quoting Hilco Wijbenga <[EMAIL PROTECTED]>: > Hi all, > > I would like to know your opinion regarding the possible introduction > of metrics gathering and tracking in Continuum. Continuum is perfectly > positioned to gather the metrics and store them in its database. > Graphs could then be generated based on this data to identify trends. > This in turn would allow developer teams to set goals and track > progress. > > The metrics would simply be the data that is created by the various > (mainly reporting) plugins that run during the build. Continuum > already does this for the surefire plugin. It's simply a matter of > finding the result file(s) and extracting the relevant metric(s). (I'm > currently thinking mainly of Maven2 builds.) > > What do you think? > > Cheers, > Hilco >
Re: Problems with ContinuumStoreTest
Marcelo Fukushima wrote: On 1/18/07, Erik Drolshammer <[EMAIL PROTECTED]> wrote: Hi! I'm trying to set up a developement environment for Continuum, but I'm experiencing some problems; *tags/continumm-1.0.3* #mvn install => " log4j:WARN Please initialize the log4j system properly. " Where can I configure log4j? What to configure? that message from log4j is just a warning... i dont think it should be there, but it doesnt affect your build - meaning you have a diff problem You are right. It was just horribly slow. (It hangs on log4j three times during the build). Any ideas on the new problem? [ERROR] BUILD ERROR [INFO] [INFO] One or more required plugin parameters are invalid/missing for 'plexus:runtime' [0] inside the definition for plugin: 'plexus-maven-plugin'specify the following: ... VALUE -OR- on the command line, specify: '-DappProperties=VALUE' [INFO] Total time: 3 minutes 30 seconds -- Regards Erik Drolshammer
Re: Problems with ContinuumStoreTest
that message from log4j is just a warning... i dont think it should be there, but it doesnt affect your build - meaning you have a diff problem On 1/18/07, Erik Drolshammer <[EMAIL PROTECTED]> wrote: Hi! I'm trying to set up a developement environment for Continuum, but I'm experiencing some problems; *tags/continumm-1.0.3* #mvn install => " --- T E S T S --- Running org.apache.maven.continuum.store.ContinuumStoreTest log4j:WARN No appenders could be found for logger (JPOX.MetaData). log4j:WARN Please initialize the log4j system properly. " Where can I configure log4j? What to configure? *trunk* #mvn install => The build hangs while displaying " --- T E S T S --- Running org.apache.maven.continuum.store.ContinuumStoreTest " Can anyone help meg? does it just hang? at my pc it takes a little while to start and it might take longer depending on your machine I'm using maven 2.0.4 in a Linux environment. -- Regards Erik Drolshammer -- []'s Marcelo Takeshi Fukushima
Problems with ContinuumStoreTest
Hi! I'm trying to set up a developement environment for Continuum, but I'm experiencing some problems; *tags/continumm-1.0.3* #mvn install => " --- T E S T S --- Running org.apache.maven.continuum.store.ContinuumStoreTest log4j:WARN No appenders could be found for logger (JPOX.MetaData). log4j:WARN Please initialize the log4j system properly. " Where can I configure log4j? What to configure? *trunk* #mvn install => The build hangs while displaying " --- T E S T S --- Running org.apache.maven.continuum.store.ContinuumStoreTest " Can anyone help meg? I'm using maven 2.0.4 in a Linux environment. -- Regards Erik Drolshammer
Re: [m2] help with maven API
Hi David, Have a glance to https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-ant-plugin/src/main/java/org/apache/maven/plugin/ant/AntBuildWriterUtil.java Specially #getMavenPluginConfiguration() HTH Cheers, Vincent 2007/1/18, dvicente <[EMAIL PROTECTED]>: Hello with all, I am improving my plugin Dashboard ( http://mojo.codehaus.org/dashboard-maven-plugin/ http://mojo.codehaus.org/dashboard-maven-plugin/ ). I have a small concern. I wish to be able to recover the configuration of the plugin Surefire via API Maven, in particular the property "reportsDirectory". What enabled me to avoid adding a parameter config on my plugin but especially in the case of a multi-module project, it may be that this value is not the same one for each module and thus my paramétre would not be good any more from one module to another. I want to be able to be sure to be able to recover the absolute path parameter "reportsDirectory" of Surefire for each module while passing by the API one. If somebody has an idea of API which could do that? (Plexus, Maven Model….) thank you in advance for your assistance -- View this message in context: http://www.nabble.com/-m2--help-with-maven-API-tf3033510s177.html#a8428681 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] help with maven API
Hello with all, I am improving my plugin Dashboard ( http://mojo.codehaus.org/dashboard-maven-plugin/ http://mojo.codehaus.org/dashboard-maven-plugin/ ). I have a small concern. I wish to be able to recover the configuration of the plugin Surefire via API Maven, in particular the property “reportsDirectory”. What enabled me to avoid adding a parameter config on my plugin but especially in the case of a multi-module project, it may be that this value is not the same one for each module and thus my paramétre would not be good any more from one module to another. I want to be able to be sure to be able to recover the absolute path parameter “reportsDirectory” of Surefire for each module while passing by the API one. If somebody has an idea of API which could do that? (Plexus, Maven Model….) thank you in advance for your assistance -- View this message in context: http://www.nabble.com/-m2--help-with-maven-API-tf3033510s177.html#a8428681 Sent from the Maven Developers mailing list archive at Nabble.com.
RE: Re: [m2] Adding further dependency goals
Hi Brian, Brian E. Fox wrote on Thursday, January 18, 2007 7:53 AM: > I guess I'm a little behind in this thread: > > 1st, I think dependency:list is effectively the same as the > existing dependency:resolve is it not? The artifacts need to > be resolved if you are going to include transitive stuff. Yes, quite similar. It just that you imply with "resolve" also the scope "test". So dependency:resolve would be equal to dependency:test -Dtype=list > 2nd, I like this suggestion best so far: > "dependency: -Dtype= > > then everybody has the possibility to configure a property in > his settings for the preferred view type ..." > > Although I'm on the fence about having to make a separate > goal for each. I think this is still very close to resolve. > It would be nice if there was a way to alias a goal to > something that exists and default the params without having > to create a whole new class. Yes. Definitely. Maybe it's already possible and we just did not find out. Don't know Plexus descriptor enough. OTOH the classes are quite lightwight i.e. have simply a ctor with default params for the super class. > The existing resolve goal needs to be tweaked a little to > allow it to function even if some artifacts can't be resolved > (a fail at end essentially) since its initial reason for > existence was to quickly force a download of everything > needed for going offline, or to test proxies etc. If you do > this on a tree that has internal dependencies, it will die > out before it completes unless you have already built it > (negating most cases of needing to resolve). Skipping those > artifacts would work around it. The change needed is to > remove the requiresDependencyResolution flag and > programaticaly resolve them...the code already exists since > the copy/unpack goals do it anyway. Good info. Thanks. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Adding further dependency goals
Hi Mark, Mark Hobson wrote on Wednesday, January 17, 2007 9:56 PM: > On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: [snip] >> I'll post tomorrow an output from the command line to demonstrate >> how it looks like. If your reactor build counts ~100 modules, the >> filter is quite helpful detecting single artifacts in the dep tree >> or the SNAPSHOTs you have to release (in which sequence). > > Thanks, that'd be good. Here's the output of the dep tree of a single artifact: = %< = $ mvn info:deps-runtime [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'info'. [INFO] [INFO] Building eIP EventMonitor CM Provider [INFO]task-segment: [info:deps-runtime] [INFO] [INFO] snapshot com.elsagsolutions.commons:es-commons-configuration:2.0.2-SNAPSHOT: checking for updates from elsag-repo-snapshot [INFO] [info:deps-runtime] [INFO] ip.evtmon:ip-evtmon-cm:jar:2.2.1-SNAPSHOT [INFO] javax.xml:jaxp-api:jar:1.3.2 [INFO] ip.commons:ip-commons:jar:2.2.1 [INFO] : commons-beanutils:commons-beanutils:jar:1.7.0 [INFO] : com.elsagsolutions.commons:es-commons-lang:jar:2.0.5 [INFO] : commons-lang:commons-lang:jar:2.1 [INFO] : commons-id:commons-id:jar:20060125.092202 [INFO] ip.extensions.filenet:ip-filenet-cm-commons:jar:2.2.1 [INFO] : ip.security:ip-security-commons:jar:2.2.1 [INFO] ip.evtmon:ip-evtmon-commons:jar:2.2.0 [INFO] javax.xml:jaxrpc-api:jar:1.1 [INFO] com.elsagsolutions.commons:es-commons-configuration:jar:2.0.2-SNAPSHOT [INFO] : commons-configuration:commons-configuration:jar:1.2 [INFO] : commons-collections:commons-collections:jar:3.2 [INFO] : xalan:xalan:jar:2.7.0 [INFO] log4j:log4j:jar:1.2.8 [INFO] commons-logging:commons-logging:jar:1.1 [INFO] com.thoughtworks.xstream:xstream:jar:1.2.1 [INFO] xpp3:xpp3_min:jar:1.1.3.4.O [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Thu Jan 18 08:56:09 CET 2007 [INFO] Final Memory: 4M/9M [INFO] = %< = now the same as test tree: = %< = $ mvn info:deps-test [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'info'. [INFO] [INFO] Building eIP EventMonitor CM Provider [INFO]task-segment: [info:deps-test] [INFO] [INFO] snapshot com.elsagsolutions.commons:es-commons-configuration:2.0.2-SNAPSHOT: checking for updates from elsag-repo-snapshot [INFO] [info:deps-test] [INFO] ip.evtmon:ip-evtmon-cm:jar:2.2.1-SNAPSHOT [INFO] javax.xml:jaxp-api:jar:1.3.2 [INFO] ip.commons:ip-commons:jar:2.2.1 [INFO] : commons-beanutils:commons-beanutils:jar:1.7.0 [INFO] : com.elsagsolutions.commons:es-commons-lang:jar:2.0.5 [INFO] : commons-lang:commons-lang:jar:2.1 [INFO] : commons-id:commons-id:jar:20060125.092202 [INFO] ip.extensions.filenet:ip-filenet-cm-commons:jar:2.2.1 [INFO] : ip.security:ip-security-commons:jar:2.2.1 [INFO] ip.evtmon:ip-evtmon-commons:jar:2.2.0 [INFO] javax.xml:jaxrpc-api:jar:1.1 [INFO] com.elsagsolutions.commons:es-commons-configuration:jar:2.0.2-SNAPSHOT [INFO] : commons-configuration:commons-configuration:jar:1.2 [INFO] : commons-collections:commons-collections:jar:3.2 [INFO] : xalan:xalan:jar:2.7.0 [INFO] log4j:log4j:jar:1.2.8 [INFO] com.elsagsolutions.commons:es-commons-test:jar:2.0.9 [INFO] : commons-io:commons-io:jar:1.3-RC1-20070102 [INFO] : cglib:cglib-nodep:jar:2.1_3 [INFO] : jmock:jmock:jar:1.1.0 [INFO] : junit:junit:jar:3.8.1 [INFO] commons-logging:commons-logging:jar:1.1 [INFO] com.thoughtworks.xstream:xstream:jar:1.2.1 [INFO] xpp3:xpp3_min:jar:1.1.3.4.O [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Thu Jan 18 09:00:06 CET 2007 [INFO] Final Memory: 4M/9M [INFO] = %< = or from one above with a SNAPSHOT filter: = %< = $ mvn info:deps-runtime -Dfilter=SNAPSHOT [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] eIP EventMonitor CM Provider Parent Project [INFO] eIP EventMonitor CM Provider [INFO] eIP EventMonitor
