Re: [vote] move maven-archiver from components to shared
+1, nice. s/ On 6/12/06, Brett Porter [EMAIL PROTECTED] wrote: I propose that we move v2.1 of maven-archiver to the /shared/ area of SVN. I think we should leave it on the branch for now, though. This will allow it it's own release cycle, so that plugins can depend on it sooner than Maven releases. Nothing in Maven itself depends on it. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move maven-archiver from components to shared
+1 fabrizio On 6/12/06, Brett Porter [EMAIL PROTECTED] wrote: I propose that we move v2.1 of maven-archiver to the /shared/ area of SVN. I think we should leave it on the branch for now, though. This will allow it it's own release cycle, so that plugins can depend on it sooner than Maven releases. Nothing in Maven itself depends on it. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.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: [vote] [m1] release xdoc-plugin-1.10
+1 Arnaud On 6/12/06, Lukas Theussl [EMAIL PROTECTED] wrote: Thanks Dennis! See my comments in-line. - There is no longer a pdf.gif file under /images/. This was deleted by Arnaud in rev 386905 (http://svn.apache.org/viewvc?view=revrevision=386905), and moved to the pdf plugin. Is there an issue with that? - The Downloads link always shows up in the left hand navbar. I built the beanutils page myself and I do not see the Download link. This link is only generated when the property 'maven.xdoc.distributionUrl' is defined, however, I don't think this behavior has changed since xdoc-1.9.2. - On some components [beanutils] the title is missing Downloads after the project name, on the downloads page. - On some components [beanutils] the title is missing Source repository after the project name, on the scm-usage page. Do you have a component where there is a title? - I don't see one anywhere, but you have that problem already on your current site (eg http://jakarta.apache.org/commons/beanutils/dependencies.html) which was built with xdoc-plugin-1.9.2 (I presume). It's due to an issue with your custom site.jsl (commons-site.jsl) file, it doesn't take into account that the standart Maven-generated pages are fully internationalized. I'd have to take a closer look to see how to fix it, but anyway, this is not an issue caused by xdoc-plugin-1.10. - The Development process link in the navbar now goes to a generated page, which contains a link, instead of going to the url directly. See http://jira.codehaus.org/browse/MPXDOC-170, apparently I forgot to add it to the changes.xml file. Will do. - The file rename from cvs-usage to scm-usage will mean some work for us, but the change is well documented and it is the right thing to do. :) You didn't cast a vote but IMO these are all non-blocking issues (if issues at all), so I take it that we can go ahead with the release? Thanks again for the testing and the feedback, -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move maven-archiver from components to shared
+1 Emmanuel Brett Porter a écrit : I propose that we move v2.1 of maven-archiver to the /shared/ area of SVN. I think we should leave it on the branch for now, though. This will allow it it's own release cycle, so that plugins can depend on it sooner than Maven releases. Nothing in Maven itself depends on it. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
suggestion for mvn --help message
Hi . I'm still new to maven. A problem which I and other encounter is : Where to get information about what I can do with maven, wehre to look it up? My first attempt (most unix users will do) mvn --help. Which prints nice information but not: Which plugins are availible and where to get the description of them.. You can (as I did) ask the mailinglist to get the answer: mvn help:describe -Dplugin=.. -DFull=true or mvn help:describe -DArtifactId=.. -DGroupId=.. -DFull=true What about adding this command as hint to mvn --help? === this is now === usage: mvn [options] [goal(s)] [phase(s)] Options: -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksumsWarn if checksums don't match -P,--activate-profilesComma-delimited list of profiles to activate -ff,--fail-fast Stop at first failure in reactorized builds -fae,--fail-at-endOnly fail the build afterwards; allow all non-impacted builds to continue -B,--batch-mode Run in non-interactive (batch) mode -fn,--fail-never NEVER fail the build, regardless of project result -up,--update-plugins Synonym for cpu -N,--non-recursiveDo not recurse into sub-projects -npr,--no-plugin-registry Don't use ~/.m2/plugin-registry.xml for plugin versions -U,--update-snapshots Update all snapshots regardless of repository policies -cpu,--check-plugin-updates Force upToDate check for any relevant registered plugins -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins -D,--define Define a system property -X,--debugProduce execution debug output -e,--errors Produce execution error messages -f,--file Force the use of an alternate POM file. -h,--help Display help information -o,--offline Work offline -r,--reactor Execute goals for project found in the reactor -s,--settings Alternate path for the user settings file -v,--version Display version information == why not add === --show-plugininfo/ [or --show-new-user-info ?] which prints something like To get the description of a plugin try mvn help:describe -DFull=true plugin where plugin is either -Dplugin or -DartifactId=maven-pluginname-plugin -DgroupId=org.apache.maven.plugins To get a list of plugins goto http://maven.apache.org/plugins/index.html or have a look at the maven 2 repo directory http://www.ibiblio.org/maven2/org/apache/maven/plugins/ ... [Wht This would help any newbe to get started as having plugnis and a build cycle description is the main feature of maven, isn't it? Another thing: If you are looking for pom.xml and some description, you are out of luck. You have to click on Guides-References- Project Descriptor. What do you think? Greetings Marc Weber - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move maven-archiver from components to shared
On Mon, 12 Jun 2006, Brett Porter wrote: +1 I propose that we move v2.1 of maven-archiver to the /shared/ area of SVN. I think we should leave it on the branch for now, though. This will allow it it's own release cycle, so that plugins can depend on it sooner than Maven releases. Nothing in Maven itself depends on it. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: clover and cpd plugin clashes
-Original Message- From: Mike Perham [mailto:[EMAIL PROTECTED] Sent: mardi 30 mai 2006 17:56 To: Vincent Massol Subject: RE: clover and cpd plugin clashes I would argue that the modified Clover code should not be reported on at all. Agreed You wouldn't want JXR, javancss, etc to report on that source because it does not actually reflect the code in your module. That's how I arrived at my conclusion. We agree on this. Can you give me an example of the workaround you are suggesting? I was just saying that you should not run the checks inside the custom lifecycle spawned by the clover plugin. The Clover plugin generates instrumented code and database data during the execution of the clover:instrument goal. Put the execution of this goal inside an execution and do all your checks in another execution.. Now I do agree that m2 needs a better way of doing this and I think I've already raised some jira on this (I'm too lazy to search for it right now). One solution is to have the same mechanism for reporting plugins than we have for build plugins and thus have the ability to have executions there too. Let's continue this discussion on the maven list. Thanks -Vincent -Original Message- So this is an interesting bug. I have clover and pmd:cpd-check configured. Clover injects a block of source into every source file for instrumentation purposes. cpd sees this block of code as copy/pasted code because it occurs in every source file and fails my build. Who's in the wrong here? I'm inclined to say it's a Clover plugin bug because it should not be exposing its modified code as source to be examined by other plugins. Maybe the faulty is CPD because it should accept to ignore some specified blocks of code? :-) What we should do is disable the CPD check in the custom lifecycle spawned by the clover plugin. Why don't you simply remote the cpd-check from your clover execution? -Vincent __ _ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move maven-archiver from components to shared
+1 (Non-binding) But that pops up the question: When can we expect the move? Regards, Jochen Brett Porter wrote: I propose that we move v2.1 of maven-archiver to the /shared/ area of SVN. I think we should leave it on the branch for now, though. This will allow it it's own release cycle, so that plugins can depend on it sooner than Maven releases. Nothing in Maven itself depends on it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move maven-archiver from components to shared
On Mon, 12 Jun 2006, Jochen Wiedmann wrote: +1 (Non-binding) But that pops up the question: When can we expect the move? The vote has to pass first. I expect Brett to announce the move in the resulting mail. All in all I'd say about 2 days from now. :) -- Kenney Regards, Jochen Brett Porter wrote: I propose that we move v2.1 of maven-archiver to the /shared/ area of SVN. I think we should leave it on the branch for now, though. This will allow it it's own release cycle, so that plugins can depend on it sooner than Maven releases. Nothing in Maven itself depends on it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move maven-archiver from components to shared
+1 On 6/12/06, Brett Porter [EMAIL PROTECTED] wrote: I propose that we move v2.1 of maven-archiver to the /shared/ area of SVN. I think we should leave it on the branch for now, though. This will allow it it's own release cycle, so that plugins can depend on it sooner than Maven releases. Nothing in Maven itself depends on it. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.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]
plugin extensions
Hi, I was wondering if the pluginextensionstrue couldn't be auto-detected by maven by looking at the components.xml in the plugin's jar or something similar, or wheter it could on by default. It seems that when a plugin defines packaging/lifecycle extensions and you do not specify extensionstrue/extensions you get a ComponentLookupException (Error looking up lifecycle mapping ...). I haven't looked at the code yet but I'm wondering why this manual step is necessary. The project model descriptor says it's disabled by default for performance reasons. I don't understand why this can have a performance impact, since maven-core also defines lifecycle mappings, and a plugin's components.xml is processed anyway (again, I haven't looked at the code). Btw, what's happened to the idea of having a discussion queue of 5 items for design issues? -- Kenney -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion for mvn --help message
I agree some further plugin information would be useful - I raised a similar issue the other day: http://jira.codehaus.org/browse/MNG-2310 Mark On 12/06/06, Marc Weber [EMAIL PROTECTED] wrote: Hi . I'm still new to maven. A problem which I and other encounter is : Where to get information about what I can do with maven, wehre to look it up? My first attempt (most unix users will do) mvn --help. Which prints nice information but not: Which plugins are availible and where to get the description of them.. You can (as I did) ask the mailinglist to get the answer: mvn help:describe -Dplugin=.. -DFull=true or mvn help:describe -DArtifactId=.. -DGroupId=.. -DFull=true What about adding this command as hint to mvn --help? === this is now === usage: mvn [options] [goal(s)] [phase(s)] Options: -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksumsWarn if checksums don't match -P,--activate-profilesComma-delimited list of profiles to activate -ff,--fail-fast Stop at first failure in reactorized builds -fae,--fail-at-endOnly fail the build afterwards; allow all non-impacted builds to continue -B,--batch-mode Run in non-interactive (batch) mode -fn,--fail-never NEVER fail the build, regardless of project result -up,--update-plugins Synonym for cpu -N,--non-recursiveDo not recurse into sub-projects -npr,--no-plugin-registry Don't use ~/.m2/plugin-registry.xml for plugin versions -U,--update-snapshots Update all snapshots regardless of repository policies -cpu,--check-plugin-updates Force upToDate check for any relevant registered plugins -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins -D,--define Define a system property -X,--debugProduce execution debug output -e,--errors Produce execution error messages -f,--file Force the use of an alternate POM file. -h,--help Display help information -o,--offline Work offline -r,--reactor Execute goals for project found in the reactor -s,--settings Alternate path for the user settings file -v,--version Display version information == why not add === --show-plugininfo/ [or --show-new-user-info ?] which prints something like To get the description of a plugin try mvn help:describe -DFull=true plugin where plugin is either -Dplugin or -DartifactId=maven-pluginname-plugin -DgroupId=org.apache.maven.plugins To get a list of plugins goto http://maven.apache.org/plugins/index.html or have a look at the maven 2 repo directory http://www.ibiblio.org/maven2/org/apache/maven/plugins/ ... [Wht This would help any newbe to get started as having plugnis and a build cycle description is the main feature of maven, isn't it? Another thing: If you are looking for pom.xml and some description, you are out of luck. You have to click on Guides-References- Project Descriptor. What do you think? Greetings Marc Weber - 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: Merge it0105 and it0107 to 2.0.x branch
I think the question here is, should we merge the itxxx folders and then just have the test deactivated in the branch? that would make the differencies between trunk and branch minimal which I see as a good thing (TM) On 6/12/06, Brett Porter [EMAIL PROTECTED] wrote: jerome lacoste wrote: Someone might want to create a test case for a branch issue without looking at the trunk. And it's better to keep itest ids synchronized. That would be against our development practices we agreed on a while back (everything goes through trunk). The only scenario would be something that only ever works on the branch, not the trunk, I'd question the value of such a thing. - Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.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: Merge it0105 and it0107 to 2.0.x branch
On Mon, 12 Jun 2006, Carlos Sanchez wrote: Just tossing in an idea: Perhaps a more sophisticated system where you specify which version of maven is needed for the it test - especially useful for new feature testing that's not available in some versions of m2. So instead of #commenting out you have lines like it [2.0.4) This would imply that the it tests are not on trunk or branch but a new top level project. -- Kenney I think the question here is, should we merge the itxxx folders and then just have the test deactivated in the branch? that would make the differencies between trunk and branch minimal which I see as a good thing (TM) On 6/12/06, Brett Porter [EMAIL PROTECTED] wrote: jerome lacoste wrote: Someone might want to create a test case for a branch issue without looking at the trunk. And it's better to keep itest ids synchronized. That would be against our development practices we agreed on a while back (everything goes through trunk). The only scenario would be something that only ever works on the branch, not the trunk, I'd question the value of such a thing. - Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.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] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MRM
What is the current status likely availability date for MRM? Is it recommended to use Maven Proxy in the interim? If so, what repository names should be set up for Proxy to allow for a amooth transition to MRM? Thanks, David ___ David Beckedorff Senior Developer CellExchange, Inc. [EMAIL PROTECTED] Office: (617)528-2196 Cell: (781)820-0567
Re: Please sync Lucene to ibiblio
done On 6/11/06, Martin Cooper [EMAIL PROTECTED] wrote: I've just deployed Lucene Core 1.9.1 and 2.0.0 to the ASF M2 repo: http://www.apache.org/dist/maven-repository/org/apache/lucene/lucene-core/ Please sync to ibiblio. TIA. -- Martin Cooper -- 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: Please sync Lucene to ibiblio
Could you also sync http://www.apache.org/dist/maven-repository/org/apache/bcel/bcel/ cheers -- Torsten On 6/13/06, Carlos Sanchez [EMAIL PROTECTED] wrote: done On 6/11/06, Martin Cooper [EMAIL PROTECTED] wrote: I've just deployed Lucene Core 1.9.1 and 2.0.0 to the ASF M2 repo: http://www.apache.org/dist/maven-repository/org/apache/lucene/lucene-core/ Please sync to ibiblio. TIA. -- Martin Cooper -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please sync Lucene to ibiblio
yep all apache was synced On 6/12/06, Torsten Curdt [EMAIL PROTECTED] wrote: Could you also sync http://www.apache.org/dist/maven-repository/org/apache/bcel/bcel/ cheers -- Torsten On 6/13/06, Carlos Sanchez [EMAIL PROTECTED] wrote: done On 6/11/06, Martin Cooper [EMAIL PROTECTED] wrote: I've just deployed Lucene Core 1.9.1 and 2.0.0 to the ASF M2 repo: http://www.apache.org/dist/maven-repository/org/apache/lucene/lucene-core/ Please sync to ibiblio. TIA. -- Martin Cooper -- 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] - 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: Please sync Lucene to ibiblio
Great, thanks :) On 6/13/06, Carlos Sanchez [EMAIL PROTECTED] wrote: yep all apache was synced On 6/12/06, Torsten Curdt [EMAIL PROTECTED] wrote: Could you also sync http://www.apache.org/dist/maven-repository/org/apache/bcel/bcel/ cheers -- Torsten On 6/13/06, Carlos Sanchez [EMAIL PROTECTED] wrote: done On 6/11/06, Martin Cooper [EMAIL PROTECTED] wrote: I've just deployed Lucene Core 1.9.1 and 2.0.0 to the ASF M2 repo: http://www.apache.org/dist/maven-repository/org/apache/lucene/lucene-core/ Please sync to ibiblio. TIA. -- Martin Cooper -- 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse/OSGi and Maven 2
Does maven currently support or can be extend to support the notion of Repository Groups? Background on why this would be needed: To properly deal with OSGi bundles, you really need a set of bundles you will compile against. If you take an eclipse install for example there could be 130+ osgi bundles in the eclipse/plugins folder. The eclipse compiler needs to be told the target, eclipse install, it will use for resolving dependencies. If the bundle you are compiling calls out a dependency on version 3.2.0 of the org.eclipse.core.runtime bundle then resolution is easy as the compiler plugin simply needs to see if it has the org.eclipse.core.runtime plugin with that version in its bundle map. However if the bundle you are compiling instead uses a package import dependency (i.e. org.apache.commons.logging) then the compiler need to review all of the bundles that export java packages and chose the best match for which bundle it will add to the classpath for compilation. When targeting an eclipse install on the filesystem then this can work with changing/extending maven however installing and deploying still need work. If instead maven had the notion of Repository Groups then a repo group org.eclipse.platform-3.2 could be specified and this group would have pointers, symlinks, etc to the component artifacts in the group which may be in 1 or more repos. Repo groups would allow users to essentially define their own software stacks such as spring-webapp-2.0 as a repo group and adding this dependency to your pom would transitively resolved when the group was resolved and add spring-2.0, commons-logging-1.1, log4j-1.2.13 and hibernate-3.1.3 to the classpath for the project. Wb On 6/9/06, Brett Porter [EMAIL PROTECTED] wrote: Wendell Beckwith wrote: I'm working with limited knowledge from both sides (always a combo for success) but can you clarify what you mean by a custom maven install? Are you talking just for the dependency resolution stuff or are we going to need to change so much about maven that's darn near a fork? Yep, you'll need to put a JAR into $M2_HOME/lib or similar that contains the alternate dependency resolver. It can be completely separated, I think. However, we generally don't want to have to modify the Maven install, so if this is a common case we may want to support it via the POM. The extensions tag is there for that purpose, but we may not find it is loaded early enough for the dependency resolver. Regardless, it will be possible to do this, and we can work to making it cleaner afterwards. - Brett
MRM Build Broken
What is the fix for this? I'm using maven-2.0.4. [INFO] Installing D:\MRM\maven-repository-manager-site\maven-repository-application\target\m aven-repository-application-1.0-SNAPSHOT.jar to C:\Documents and Settings\dbeckedorff\.m2\re pository\org\apache\maven\repository\maven-repository-application\1.0-SNAPSH OT\maven-reposit ory-application-1.0-SNAPSHOT.jar [INFO] [INFO] Building Maven Repository Manager Artifact Applet [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] 'sign' was specified in an execution, but not found in the plugin [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: 'sign' was specified in an execution , but not found in the plugin at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindExecutionToLifecycle (Defa ultLifecycleExecutor.java:1337) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(De fault LifecycleExecutor.java:1238) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappin gs(De faultLifecycleExecutor.java:982) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifec ycleE xecutor.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFail ures( DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Defa ultLi fecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycle Execu tor.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) [INFO] [INFO] Total time: 37 seconds [INFO] Finished at: Mon Jun 12 13:43:29 EDT 2006 [INFO] Final Memory: 9M/17M [INFO] ___ David Beckedorff Senior Developer CellExchange, Inc. [EMAIL PROTECTED] Office: (617)528-2196 Cell: (781)820-0567
Re: [vote] [m1] release xdoc-plugin-1.10
Lukas Theussl wrote: Thanks Dennis! See my comments in-line. - There is no longer a pdf.gif file under /images/. This was deleted by Arnaud in rev 386905 (http://svn.apache.org/viewvc?view=revrevision=386905), and moved to the pdf plugin. Is there an issue with that? Nope, no problem. Just something I noticed that's all. - The Downloads link always shows up in the left hand navbar. I built the beanutils page myself and I do not see the Download link. This link is only generated when the property 'maven.xdoc.distributionUrl' is defined, however, I don't think this behavior has changed since xdoc-1.9.2. Beanutils has a dependency on maven-xdoc-plugin 1.9.2 so you need to either change the version to 1.10-SNAPSHOT or remove the dependency. I forgot to mention that. I just did a maven clean site and I still get the Downloads link when building it using the 1.10-SNAPSHOT version. I read about the property in the docs. Beanutils does not have that property though. - On some components [beanutils] the title is missing Downloads after the project name, on the downloads page. - On some components [beanutils] the title is missing Source repository after the project name, on the scm-usage page. Do you have a component where there is a title? - I don't see one anywhere, but you have that problem already on your current site (eg http://jakarta.apache.org/commons/beanutils/dependencies.html) which was built with xdoc-plugin-1.9.2 (I presume). It's due to an issue with your custom site.jsl (commons-site.jsl) file, it doesn't take into account that the standart Maven-generated pages are fully internationalized. I'd have to take a closer look to see how to fix it, but anyway, this is not an issue caused by xdoc-plugin-1.10. Commons email has the title. You might be right on track about the jsl file. The component sites that work properly have a new and improved way of applying the jsl file. So it's probably something wrong with the old way. I'll dig into it and see if I can find out why it happens. - The Development process link in the navbar now goes to a generated page, which contains a link, instead of going to the url directly. See http://jira.codehaus.org/browse/MPXDOC-170, apparently I forgot to add it to the changes.xml file. Will do. That explains it. - The file rename from cvs-usage to scm-usage will mean some work for us, but the change is well documented and it is the right thing to do. :) You didn't cast a vote but IMO these are all non-blocking issues (if issues at all), so I take it that we can go ahead with the release? Oh, sorry! I forgot that I am supposed to vote now :) If the Downloads link problem above and another problem I found (will send another mail about that) can be solved, I'm +1. The rest seems to be Commons specific, which shouldn't hold back the release of the xdoc plugin. Thanks again for the testing and the feedback, -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
I decided to try out a Sourceforge project that I work on, but it failed miserably with the new plugin. Just to make sure it wasn't something specific to that project I checked out another Sourceforge project that you are all familiar with: maven-plugins. Steps to reproduce: * check out maven-plugins from sourceforge.net * cd maven-plugins\tasks * maven site This is the results I get: ... xdoc:generate-from-pom: [echo] Generating xdocs from POM ... BUILD FAILED File.. C:\Documents and Settings\dlg01\.maven\cache\maven-xdoc-plugin-1.10-SNAPSHOT\plugin.jelly Element... velocity:merge Line.. 728 Column 13 Invocation of method 'anonymousAccessCVS' in class org.apache.maven.xdoc.util.ScmUtil threw exception class java.lang.NoClassDefFoundError : org/codehaus/plexus/util/StringUtils Total time: 31 seconds Finished at: Mon Jun 12 23:16:16 CEST 2006 This might be a regression issue, since I'm still using Maven 1.0.2. Lukas Theussl wrote: Hi again, This is a big one so I do it separately. The xdoc-plugin-1.10 has been feature complete since a while, but with the re-introduction of xerces into the core and the upcoming dom4j upgrade (which it should be compatible with), it is only now that I'd like to release it. There are quite a few changes since the last version so I'd appreciate some sincere testing, even though I've had already feedback from a few people who had used the snapshots successfully. The future docs are here: http://people.apache.org/~ltheussl/maven-stage-site/maven-1.x/plugins/xdoc/ One thing that is left to do is get the dtd file on the main apache site ( http://jira.codehaus.org/browse/MPXDOC-192 ), can somebody tell me what needs to be done for that? +1 from me and 72h to vote. Cheers, -Lukas snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
I just did a maven clean site and I still get the Downloads link when building it using the 1.10-SNAPSHOT version. Ok, I can reproduce it now using maven-1.0.2, I don't see it with m1.1-beta-3. Certainly a jelly issue, I'll look into it. -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
In the Jelly release bundled in maven 1.0.x there was some bugs in the empty() function. cheers Arnaud On 6/12/06, Lukas Theussl [EMAIL PROTECTED] wrote: I just did a maven clean site and I still get the Downloads link when building it using the 1.10-SNAPSHOT version. Ok, I can reproduce it now using maven-1.0.2, I don't see it with m1.1-beta-3. Certainly a jelly issue, I'll look into it. -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
I cannot reproduce this one, neither with m1.0.2 nor m11b3. I'd be surprised, too, as the xdoc-plugin doesn't use plexus. Can you run with -e, to see the full stack trace? -Lukas Dennis Lundberg wrote: I decided to try out a Sourceforge project that I work on, but it failed miserably with the new plugin. Just to make sure it wasn't something specific to that project I checked out another Sourceforge project that you are all familiar with: maven-plugins. Steps to reproduce: * check out maven-plugins from sourceforge.net * cd maven-plugins\tasks * maven site This is the results I get: ... xdoc:generate-from-pom: [echo] Generating xdocs from POM ... BUILD FAILED File.. C:\Documents and Settings\dlg01\.maven\cache\maven-xdoc-plugin-1.10-SNAPSHOT\plugin.jelly Element... velocity:merge Line.. 728 Column 13 Invocation of method 'anonymousAccessCVS' in class org.apache.maven.xdoc.util.ScmUtil threw exception class java.lang.NoClassDefFoundError : org/codehaus/plexus/util/StringUtils Total time: 31 seconds Finished at: Mon Jun 12 23:16:16 CEST 2006 This might be a regression issue, since I'm still using Maven 1.0.2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
Looks like it could be jelly related as well. BUILD FAILED org.apache.velocity.exception.MethodInvocationException: Invocation of method 'anonymousAccessCVS' in class org.apache.maven.xdoc.util.ScmUtil threw except ion class java.lang.NoClassDefFoundError : org/codehaus/plexus/util/StringUtils at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:246) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:175) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:327) at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:51) at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:95) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:70) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:181) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:89) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230) at org.apache.velocity.Template.merge(Template.java:256) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450) at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:226) at org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:108) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:92) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:84) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) 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:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) File.. C:\Documents and Settings\dlg01\.maven\cache\maven-xdoc-plugin-1.10-SNAPSHOT\plugin.jelly Element... velocity:merge Line.. 728 Column 13
Re: [vote] [m1] release xdoc-plugin-1.10
Right on,
I replaced
j:if test=${!empty(context.getVariable('maven.xdoc.distributionUrl'))}
by
j:if test=${context.getVariable('maven.xdoc.distributionUrl') != null
and context.getVariable('maven.xdoc.distributionUrl') != ''}
and now it works also with m1.0.2. The point is: the empty function is
used all over the place in the xdoc plugin (plugin.jelly, site.jsl,
various templates), do I have to replace it everywhere?
-Lukas
Arnaud HERITIER wrote:
In the Jelly release bundled in maven 1.0.x there was some bugs in the
empty() function.
cheers
Arnaud
On 6/12/06, Lukas Theussl [EMAIL PROTECTED] wrote:
I just did a maven clean site and I still get the Downloads link
when building it using the 1.10-SNAPSHOT version.
Ok, I can reproduce it now using maven-1.0.2, I don't see it with
m1.1-beta-3. Certainly a jelly issue, I'll look into it.
-Lukas
-
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: [vote] [m1] release xdoc-plugin-1.10
I'm not what were the cases when the empty function failed.
I remember that it didn't work on empty lists.
It seems that there was also a problem with if the parameter is null.
I don't know if we can have the same error somewhere else.
Arnaud
On 6/13/06, Lukas Theussl [EMAIL PROTECTED] wrote:
Right on,
I replaced
j:if test=${!empty(context.getVariable('maven.xdoc.distributionUrl'))}
by
j:if test=${context.getVariable('maven.xdoc.distributionUrl') != null
and context.getVariable('maven.xdoc.distributionUrl') != ''}
and now it works also with m1.0.2. The point is: the empty function is
used all over the place in the xdoc plugin (plugin.jelly, site.jsl,
various templates), do I have to replace it everywhere?
-Lukas
Arnaud HERITIER wrote:
In the Jelly release bundled in maven 1.0.x there was some bugs in the
empty() function.
cheers
Arnaud
On 6/12/06, Lukas Theussl [EMAIL PROTECTED] wrote:
I just did a maven clean site and I still get the Downloads link
when building it using the 1.10-SNAPSHOT version.
Ok, I can reproduce it now using maven-1.0.2, I don't see it with
m1.1-beta-3. Certainly a jelly issue, I'll look into it.
-Lukas
-
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: [result] Re: [vote] Dennis Lundberg as a Maven Plugins committer
Thank you for giving me this opportunity. I hope that I can be of use to the Maven community. On the practical side, my commit privileges are working - I just made my first commit. Who can I contact to get some more privileges in JIRA? I'd like to assign issues to myself. Are there any special docs that are required reading for a new committer? I have found this one: http://maven.apache.org/guides/development/guide-m2-development.html -- Dennis Lundberg Brett Porter wrote: 12 x +1 Welcome, Dennis! - Brett Brett Porter wrote: Dennis is already a committer over at Jakarta Commons and has been doing a good job submitting patches to Maven plugins and documentation, and has been hanging around here for the longest time. I propose we give him commit access to apply his own patches, and hopefully a few more besides :) [ ] +1 [ ] +0 [ ] -1 Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
I'd rather suspect a classloader issue. Can you send me the list of your installed plugins (maven -i)? Because of the single classloader, another plugin can load the required class (StringUtils), which in the xdoc plugin, should be from commons.lang.StringUtils. -Lukas Dennis Lundberg wrote: Looks like it could be jelly related as well. BUILD FAILED org.apache.velocity.exception.MethodInvocationException: Invocation of method 'anonymousAccessCVS' in class org.apache.maven.xdoc.util.ScmUtil threw except ion class java.lang.NoClassDefFoundError : org/codehaus/plexus/util/StringUtils at - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [result] Re: [vote] Dennis Lundberg as a Maven Plugins committer
Done. Your account dennislundberghttp://jira.codehaus.org/secure/admin/user/ViewUser.jspa?name=dennislundbergis now in the group maven-developers. Welcome Arnaud On 6/13/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Thank you for giving me this opportunity. I hope that I can be of use to the Maven community. On the practical side, my commit privileges are working - I just made my first commit. Who can I contact to get some more privileges in JIRA? I'd like to assign issues to myself. Are there any special docs that are required reading for a new committer? I have found this one: http://maven.apache.org/guides/development/guide-m2-development.html -- Dennis Lundberg Brett Porter wrote: 12 x +1 Welcome, Dennis! - Brett Brett Porter wrote: Dennis is already a committer over at Jakarta Commons and has been doing a good job submitting patches to Maven plugins and documentation, and has been hanging around here for the longest time. I propose we give him commit access to apply his own patches, and hopefully a few more besides :) [ ] +1 [ ] +0 [ ] -1 Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
Installed plugins: maven-abbot-plugin-1.1 maven-announcement-plugin-1.4 maven-ant-plugin-1.9 maven-antlr-plugin-1.2.1 maven-appserver-plugin-2.0 maven-artifact-plugin-1.4.1 maven-ashkelon-plugin-1.2 maven-aspectj-plugin-3.2 maven-aspectwerkz-plugin-1.2 maven-caller-plugin-1.1 maven-castor-plugin-1.2 maven-changelog-plugin-1.8.2 maven-changes-plugin-1.6 maven-checkstyle-plugin-2.5 maven-clean-plugin-1.3 maven-clover-plugin-1.6 maven-console-plugin-1.1 maven-cruisecontrol-plugin-1.6 maven-dashboard-plugin-1.6 maven-developer-activity-plugin-1.5.2 maven-dist-plugin-1.6.1 maven-docbook-plugin-1.2 maven-ear-plugin-1.6 maven-eclipse-plugin-1.9 maven-ejb-plugin-1.5 maven-faq-plugin-1.4 maven-file-activity-plugin-1.5.2 maven-genapp-plugin-2.2 maven-gump-plugin-1.4 maven-hibernate-plugin-1.2 maven-html2xdoc-plugin-1.3.1 maven-idea-plugin-1.6 maven-j2ee-plugin-1.5.1 maven-jalopy-plugin-1.3.1 maven-jar-plugin-1.6.1 maven-java-plugin-1.5 maven-javacc-plugin-1.1 maven-javadoc-plugin-1.7 maven-jboss-plugin-1.5 maven-jbuilder-plugin-1.5 maven-jcoverage-plugin-1.0.9 maven-jdee-plugin-1.1 maven-jdepend-plugin-1.5 maven-jdeveloper-plugin-1.4 maven-jdiff-plugin-1.5 maven-jellydoc-plugin-1.3.1 maven-jetty-plugin-1.1 maven-jira-plugin-1.3 maven-jnlp-plugin-1.4.1 maven-junit-doclet-plugin-1.2 maven-junit-report-plugin-1.5 maven-jxr-plugin-1.4.2 maven-latex-plugin-1.4.1 maven-latka-plugin-1.4.1 maven-license-plugin-1.2 maven-linkcheck-plugin-1.4.1-SNAPSHOT maven-multichanges-plugin-1.1 maven-multiproject-plugin-1.3.1 maven-native-plugin-1.1 maven-nsis-plugin-1.1 maven-pdf-plugin-2.2.1 maven-plugin-plugin-1.7 maven-pmd-plugin-1.6 maven-pom-plugin-1.5 maven-rar-plugin-1.0 maven-release-plugin-1.5-SNAPSHOT maven-repository-plugin-1.2 maven-scm-plugin-1.6 maven-shell-plugin-1.1 maven-simian-plugin-1.4 maven-site-plugin-1.7 maven-struts-plugin-1.3 maven-tasklist-plugin-2.4 maven-test-plugin-1.6.2 maven-tjdo-plugin-1.0.0 maven-uberjar-plugin-1.2 maven-vdoclet-plugin-1.2 maven-war-plugin-1.6.1 maven-webserver-plugin-2.0 maven-wizard-plugin-1.1 maven-xdoc-plugin-1.10-SNAPSHOT -- Dennis Lundberg Lukas Theussl wrote: I'd rather suspect a classloader issue. Can you send me the list of your installed plugins (maven -i)? Because of the single classloader, another plugin can load the required class (StringUtils), which in the xdoc plugin, should be from commons.lang.StringUtils. -Lukas Dennis Lundberg wrote: Looks like it could be jelly related as well. BUILD FAILED org.apache.velocity.exception.MethodInvocationException: Invocation of method 'anonymousAccessCVS' in class org.apache.maven.xdoc.util.ScmUtil threw except ion class java.lang.NoClassDefFoundError : org/codehaus/plexus/util/StringUtils at - 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: [vote] [m1] release xdoc-plugin-1.10
Ok, I get the same error when downgrading the jxr plugin to your version 1.4.2, it works with the latest 1.5. Don't ask me why... You might consider upgrading a number of plugins anyway, just be careful with artifact: 1.5.2 is the highest that works with m1.0.2. -Lukas Dennis Lundberg wrote: Installed plugins: maven-abbot-plugin-1.1 maven-announcement-plugin-1.4 maven-ant-plugin-1.9 maven-antlr-plugin-1.2.1 maven-appserver-plugin-2.0 maven-artifact-plugin-1.4.1 maven-ashkelon-plugin-1.2 maven-aspectj-plugin-3.2 maven-aspectwerkz-plugin-1.2 maven-caller-plugin-1.1 maven-castor-plugin-1.2 maven-changelog-plugin-1.8.2 maven-changes-plugin-1.6 maven-checkstyle-plugin-2.5 maven-clean-plugin-1.3 maven-clover-plugin-1.6 maven-console-plugin-1.1 maven-cruisecontrol-plugin-1.6 maven-dashboard-plugin-1.6 maven-developer-activity-plugin-1.5.2 maven-dist-plugin-1.6.1 maven-docbook-plugin-1.2 maven-ear-plugin-1.6 maven-eclipse-plugin-1.9 maven-ejb-plugin-1.5 maven-faq-plugin-1.4 maven-file-activity-plugin-1.5.2 maven-genapp-plugin-2.2 maven-gump-plugin-1.4 maven-hibernate-plugin-1.2 maven-html2xdoc-plugin-1.3.1 maven-idea-plugin-1.6 maven-j2ee-plugin-1.5.1 maven-jalopy-plugin-1.3.1 maven-jar-plugin-1.6.1 maven-java-plugin-1.5 maven-javacc-plugin-1.1 maven-javadoc-plugin-1.7 maven-jboss-plugin-1.5 maven-jbuilder-plugin-1.5 maven-jcoverage-plugin-1.0.9 maven-jdee-plugin-1.1 maven-jdepend-plugin-1.5 maven-jdeveloper-plugin-1.4 maven-jdiff-plugin-1.5 maven-jellydoc-plugin-1.3.1 maven-jetty-plugin-1.1 maven-jira-plugin-1.3 maven-jnlp-plugin-1.4.1 maven-junit-doclet-plugin-1.2 maven-junit-report-plugin-1.5 maven-jxr-plugin-1.4.2 maven-latex-plugin-1.4.1 maven-latka-plugin-1.4.1 maven-license-plugin-1.2 maven-linkcheck-plugin-1.4.1-SNAPSHOT maven-multichanges-plugin-1.1 maven-multiproject-plugin-1.3.1 maven-native-plugin-1.1 maven-nsis-plugin-1.1 maven-pdf-plugin-2.2.1 maven-plugin-plugin-1.7 maven-pmd-plugin-1.6 maven-pom-plugin-1.5 maven-rar-plugin-1.0 maven-release-plugin-1.5-SNAPSHOT maven-repository-plugin-1.2 maven-scm-plugin-1.6 maven-shell-plugin-1.1 maven-simian-plugin-1.4 maven-site-plugin-1.7 maven-struts-plugin-1.3 maven-tasklist-plugin-2.4 maven-test-plugin-1.6.2 maven-tjdo-plugin-1.0.0 maven-uberjar-plugin-1.2 maven-vdoclet-plugin-1.2 maven-war-plugin-1.6.1 maven-webserver-plugin-2.0 maven-wizard-plugin-1.1 maven-xdoc-plugin-1.10-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
If the Downloads link problem above and another problem I found (will send another mail about that) can be solved, I'm +1. The rest seems to be Commons specific, which shouldn't hold back the release of the xdoc plugin. I deployed another snapshot, please test. Cheers, -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
Do you have a component where there is a title? - I don't see one anywhere, but you have that problem already on your current site (eg http://jakarta.apache.org/commons/beanutils/dependencies.html) which was built with xdoc-plugin-1.9.2 (I presume). It's due to an issue with your custom site.jsl (commons-site.jsl) file, it doesn't take into account that the standart Maven-generated pages are fully internationalized. I'd have to take a closer look to see how to fix it, but anyway, this is not an issue caused by xdoc-plugin-1.10. Commons email has the title. Commons email doesn't use a custom jsl file at all, it just imports an external css file in xdocs/style/project.css. What's the reason for using commons-site.jsl anyway? -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] release xdoc-plugin-1.10
We got rid of using the custom jsl and are moving to the way that commons email etc do it. On 6/13/06, Lukas Theussl [EMAIL PROTECTED] wrote: Do you have a component where there is a title? - I don't see one anywhere, but you have that problem already on your current site (eg http://jakarta.apache.org/commons/beanutils/dependencies.html) which was built with xdoc-plugin-1.9.2 (I presume). It's due to an issue with your custom site.jsl (commons-site.jsl) file, it doesn't take into account that the standart Maven-generated pages are fully internationalized. I'd have to take a closer look to see how to fix it, but anyway, this is not an issue caused by xdoc-plugin-1.10. Commons email has the title. Commons email doesn't use a custom jsl file at all, it just imports an external css file in xdocs/style/project.css. What's the reason for using commons-site.jsl anyway? -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris
Re: MRM Build Broken
Build your maven-jar-plugin from svn then try to build mrm again. -allan David Beckedorff wrote: What is the fix for this? I'm using maven-2.0.4. [INFO] Installing D:\MRM\maven-repository-manager-site\maven-repository-application\target\m aven-repository-application-1.0-SNAPSHOT.jar to C:\Documents and Settings\dbeckedorff\.m2\re pository\org\apache\maven\repository\maven-repository-application\1.0-SNAPSH OT\maven-reposit ory-application-1.0-SNAPSHOT.jar [INFO] [INFO] Building Maven Repository Manager Artifact Applet [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] 'sign' was specified in an execution, but not found in the plugin [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: 'sign' was specified in an execution , but not found in the plugin at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindExecutionToLifecycle (Defa ultLifecycleExecutor.java:1337) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(De fault LifecycleExecutor.java:1238) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappin gs(De faultLifecycleExecutor.java:982) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifec ycleE xecutor.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFail ures( DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Defa ultLi fecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycle Execu tor.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) [INFO] [INFO] Total time: 37 seconds [INFO] Finished at: Mon Jun 12 13:43:29 EDT 2006 [INFO] Final Memory: 9M/17M [INFO] ___ David Beckedorff Senior Developer CellExchange, Inc. [EMAIL PROTECTED] Office: (617)528-2196 Cell: (781)820-0567 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dealing with XML content filters
Hi, I have a use case where I am trying to figure what might be an ideal (if not best) way to deal with it. For an EJB3 project I need to toy around with a META-INF/persistence.xml which contains all the entity mappings. There are two constraints: 1) Developers using Eclipse should not have to tweak any values manually in the xml above. I'd like them to be able to simply run the maven eclipse:eclipse goal and refresh the projects and it should work. 2) When the application is deployed on the an integration or production environment, the persistence.xml should reflect the correct DB connection and other property values. I could achieve this by using filters for different profiles but for the (1) constraint above :-( Ideally I just want to maintain only one common persistence.xml *or* a common source that can generate the persistence.xml. I had a fleeting look at Modello and Doxia but I am probably way off-track here. Any ideas? Appreciate any pointers. Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [result] Re: [vote] Dennis Lundberg as a Maven Plugins committer
Dennis Lundberg wrote: Are there any special docs that are required reading for a new committer? I have found this one: http://maven.apache.org/guides/development/guide-m2-development.html That's pretty much it. We have a draft development process on the wiki too. -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge it0105 and it0107 to 2.0.x branch
I don't see the need for either, since the trunk set is a superset of what is on the branch. Kenney Westerhof wrote: On Mon, 12 Jun 2006, Carlos Sanchez wrote: Just tossing in an idea: Perhaps a more sophisticated system where you specify which version of maven is needed for the it test - especially useful for new feature testing that's not available in some versions of m2. So instead of #commenting out you have lines like it [2.0.4) This would imply that the it tests are not on trunk or branch but a new top level project. -- Kenney I think the question here is, should we merge the itxxx folders and then just have the test deactivated in the branch? that would make the differencies between trunk and branch minimal which I see as a good thing (TM) On 6/12/06, Brett Porter [EMAIL PROTECTED] wrote: jerome lacoste wrote: Someone might want to create a test case for a branch issue without looking at the trunk. And it's better to keep itest ids synchronized. That would be against our development practices we agreed on a while back (everything goes through trunk). The only scenario would be something that only ever works on the branch, not the trunk, I'd question the value of such a thing. - Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.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] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
