Re: Inter Plugin communication
A Plugin, IMHO, is atomic. I don't think you can actually have 2 plugins inter-communicate (the way you need it), except for reading the configuration from pom.xml, which was on one of the threads on the user@ or dev@ list just a couple of days ago. What is your use-case - there might be another way of doing what you want to? Cheers, Rahul - Original Message - From: "Jimisola Laursen" <[EMAIL PROTECTED]> To: Sent: Friday, July 14, 2006 2:45 AM Subject: Inter Plugin communication Hi! Is it possible to communicate between plugins run in the same build? I would like a "Build Conext" where plugins can set properties/objects for use by plugins following in execution. E.g. Plugin A gathers some information that is input for plugin B. Now, I solve it by having plugin A write to file(s) and this/these then acts as input for plugin B. I notice in the generated plugin.xml (see below) that there are some "interesting" tags (like and ), but I can't seem to find information on these. "Use the source Luke" or is it available and if so where? Regards, Jimisola generate false true false false false true se.stickybit.maven.plugins.buildinfo.BuildInfoMojo java per-lookup once-per-session Regards, Jimisola -- View this message in context: http://www.nabble.com/Inter-Plugin-communication-tf1937787.html#a5309638 Sent from the Apache Maven Developers List forum 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: Plugins can't be built!
Hi, I have seen this one ... long time ago! Can you rename/remove the folder that maps to "org.apache.maven " groupId in your local repo, and try building again. I think its coming from an old version of a library Cheers, Rahul Dennis Lundberg wrote: Hi all Someone seems to have broken something in the trunk. A lot of plugins are failing in continuum. They all have similar error messages. Does anyone know what might be wrong? I get the same error when I try to build the plugins locally. I'm not sure if this is true for all plugins, but the ones I have tried so far all fail: javadoc, jar, source, deploy. [INFO] [plugin:descriptor] [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.extractParameters(JavaMojoDescriptorExtractor.java:431) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.createMojoDescriptor(JavaMojoDescriptorExtractor.java:303) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:500) at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:99) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) 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) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
There are currently 5 open issues for 1.6 and it has been like that for a while. I thought that I might try to convince them to release the current trunk as 1.6 so that projects, that can not use snapshots in releases, could start using it. The current trunk has some, but not all, Java 5 features implemented. Let's ask them and see if they will let us on as committers. If we can't find a similar project that does the same thing we can always fork it. [1]: http://xircles.codehaus.org -- Trygve Anyone subscribed to QDox udpates - any news on this? Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A plugins nature
One way could be to factor out the reusable bits out to a separate Component. That should make plugins lightweight and allow components to be used by more than just one Plugin. Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, July 11, 2006 1:19 PM Subject: Re: A plugins nature There shouldn't be any reason you can't test as POJOs now (as long as you add getters and setters). I was initially reluctant about the extent of using the testing harness for testing - they do seem more like integration tests, but it has really been used as an assistant for populating values (and probably doesn't even go far enough there - it could populate the default expressions for you, for example). Anyway, I'm interested to talk about this some more - the most recent plugin I worked on was the release plugin where all the code was outside the mojos and they were just a thin wrapper for the Maven specifics (like surefire, etc). I think this is the right level at design, but I'm not sure about packaging (do we always split it into two parts, or do we want to be able to use the java from a mojo jar as is?) - Brett On 11/07/2006 7:46 AM, Mike Perham wrote: I would like to see plugins be made a little more independent from Maven. You know how J2EE code is difficult to test due to the need for a container? Well, Maven is the container for plugins and that need for a container makes it more difficult than necessary to test and reuse plugins. There's no reason why plugins couldn't become POJOs which have a MOJO container configuration layer. Unit tests could easily instantiate the POJOs for simple testing and a more thorough system (like the maven-plugin-test-harness) could be used to integration test the whole plugin. -Original Message- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 4:34 PM To: Maven Developers List Subject: A plugins nature Hi, in the last weeks I have thought a little bit about Maven plugins. The initial question was my desire to reuse another plugin. There are good reasons for reusing plugins. As an example, think of a plugin, which creates a jar file. Might be the retro* plugins or something like that.I would think it makes sense to reuse the jar plugin in such a case. The problem with reusing plugins is that they consist in fact of two parts: One part is the lifecycle management. The other part is the actual code. For example, the jar plugin contains some rules which ensure that it is called in the "package" phase. Besides, there is code which actually creates a jar file based on a configuration. The point I am trying to make is that such a plugin should possibly be split into these two parts. If so, the implementation part might be reused, while the lifecycle management part might still perform its task. What do you think? Jochen -- 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: deploy:deploy-file
Hi, I have meant to ask this everytime I run into similar error with wagon providers. Why is it that the wagon provider lib needs to be copied to under M2 Home? Shouldn't this be downloaded to local repo and used from there? Is it something to do with Classworlds' realms. Cheers, Rahul - Original Message - From: "Allan Ramirez" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, July 11, 2006 3:15 AM Subject: Re: deploy:deploy-file Hi, This should be on the users mailing list. anyway, to answer your question, When using deploy-deploy-file goal and encountered this error "Error deploying artifact: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp" You only have to place the appropriate wagon provider to your %M2_HOME%/lib. In this case the provider needed is ftp, so we have to place the wagon-ftp jar to the lib of your m2 installation. If the error description is something like "Error deploying artifact: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp org/apache/commons/net/ftp/FTP" Place also the commons-net jar to %M2_HOME%/lib. You can find the wagon-ftp here http://www.ibiblio.org/maven2/org/apache/maven/wagon/wagon-ftp/ Cheers, allan Marcin Maciukiewicz wrote: Hi! I want to deploy my artifact via ftp. So this is my command: mvn -e -Durl=file://ftp://some-server/root-dir/ -Dfile=com.company.models.util_1.2.0.jar -DrepositoryId=ftp-company-snapshot -DgroupId=com.company.models -DartifactId=com.company.models.util -Dversion=1.2.0-SNAPSHOT -Dpackaging=jar -DgeneratePom=true deploy:deploy-file This the result: ... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp ... How to register wagon for ftp transport when using command line deployment as shown above? Thanks, Marcin. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype Component Development Questions
Hi, You should be able to create your own implementation of for Archetype ROLE and assign it a 'role-hint'. And, then use that 'role-hint' to obtain your custom implementation from the container. See sources for Plexus archiver - how DefaultArchiverManager performs component look up based on the role-hint and how different archiver implementations are set up in components.xml. http://svn.codehaus.org/plexus/trunk/plexus-components/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/manager/DefaultArchiverManager.java HTH, Rahul - Original Message - From: "Ole Ersoy" <[EMAIL PROTECTED]> To: Sent: Saturday, July 08, 2006 3:27 PM Subject: Archetype Component Development Questions Hi, It looks like the Archetype component is pluggable, since there's one named DefaultArchetype? Is there any documentation that describes how to make the substitution happen? I need to make one that I can substitute for the default, such that a multi project archetype istance can be created. So it will create both the parent project and the child projects. Is anyone working on something like this already? I tried using the same dependencies as the maven-archetype-core project, but they are not fetchable from the repository. Should I just install them manually? Thanks, - Ole __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: Reconfiguring a plugin from within another plugin?
Hi ,
I am not sure about 'updating' plugin configuration from another one;
but to obtain a reference to JAR plugin, you could try something like
below (from the maven-eclipse-plugin sources):
===
public static String getPluginSetting( MavenProject project, String
artifactId, String optionName,
String defaultValue )
{
for ( Iterator it =
project.getModel().getBuild().getPlugins().iterator(); it.hasNext(); )
{
Plugin plugin = (Plugin) it.next();
if ( plugin.getArtifactId().equals( artifactId ) )
{
Xpp3Dom o = (Xpp3Dom) plugin.getConfiguration();
if ( o != null && o.getChild( optionName ) != null )
{
return o.getChild( optionName ).getValue();
}
}
}
return defaultValue;
}
Russell, Mark wrote:
I have a custom plugin that generates a bunch of code, and the final jar
that includes this code needs to have certain manifest entries based on
the generated code.
Unfortunately the code it generates is somewhat variable so manually
setting the entries in the pom would be rather error prone (which is one
thing I'm expending a great deal of effort to prevent).
At the moment I'm hoping that I could somehow get a reference to the jar
plugin from within my custom code and modify its configuration or get
the pom configuration and modify it before the jar plugin is invoked.
Alternately I'll have to write a custom jar plugin that references a
singleton class to get some of its configuration (which I'd rather not
do since that is a really bad way to do things)
MAR
-Original Message-
From: Rinku [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 05, 2006 3:55 PM
To: Maven Developers List
Subject: Re: Reconfiguring a plugin from within another plugin?
What is your use case? - may be there is another way to do it.
Cheers,
Rahul
Russell, Mark wrote:
Is it possible to reconfigure a plugin from within another plugin? (ie
could a plugin bound to the initialize phase modify the configuration
of
a plugin bound to the package phase?)
If so, how would I do it?
MAR
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reconfiguring a plugin from within another plugin?
What is your use case? - may be there is another way to do it. Cheers, Rahul Russell, Mark wrote: Is it possible to reconfigure a plugin from within another plugin? (ie could a plugin bound to the initialize phase modify the configuration of a plugin bound to the package phase?) If so, how would I do it? MAR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] This Maven thing is killing us....
Just wondering if rather than having an list stuffed in each of elements, if we could have some sort of tag that can 'advise' Maven the choosing strategy for conflicting artifacts (pretty much like version ranges). For sake of an example: junit junit 3.8.2 <=3.8.2 . . . So, Maven can safely choose 3.8.2 for all varying versions JUnit less than or equal to 3.8.2, but not 4.0. The other thing is that when an artifact is published to a repo, the publisher can add some compatibility meta-data as well to indicate that the current version is incompatible with certain other versions or the artifacts. Just a thought... Cheers Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: [plexus-dev] Plexus Website (update)
Hi again, A quick update to let everyone know that we have posted some updates to Plexus website and would like to get some feedback on them. Please note that a few pages are still in the process of being updated. The website is accessible at: http://plexus.codehaus.org/index.html We appreciate all the feedback we can get to help us align the site content best to user expectations. Cheers, Rahul - Original Message - From: "Rinku" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, June 15, 2006 7:29 PM Subject: Re: Fw: [plexus-dev] Plexus Website Yep, I am on that task to get them organized and published. Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, June 15, 2006 6:09 PM Subject: Re: Fw: [plexus-dev] Plexus Website That's a good idea too :) I was actually thinking of taking the ideas from John's thread on the Maven documentation and applying the same principles, but it'd be good to hear what Maven plugin people think of the plexus docs. Perhaps best to get through the current round of polishing them up and actually publishing them along with the existing todo list before getting too much feedback that says "there's nothing there" :) - Brett Rinku wrote: Greetings everyone, We are keen to gather inputs for Plexus documentation/website from users on this list. Please see the attached emails below for a heads up. Ideas and suggestions are welcome; contributions are even better :-) Look forward to hear... cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 15, 2006 5:22 PM Subject: Re: [plexus-dev] Plexus Website Rinku wrote: Greetings, There's been a growing interest on IRC lately in Plexus and I quickly wanted to touch base on Plexus website and documentation: 1) Is anyone working on the website content to move from current Confluence base to APT based? If not, I am happy to pick this activity up. you are :) Everything in Confluence is in APT (most of it needs editing). I deleted all the Confluence content as it was outdated and/or needed significant editing. 2) Does any one have any thoughts, ideas that they would like to share or like to see included in the website? I like the trails approach. Let's just feed off the discussion on [EMAIL PROTECTED] for further ideas. There's a doc in SVN about "things that need to be documented too". - Brett -- Brett Porter <[EMAIL PROTECTED]> Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email - 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] - 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: [Proposal] Documenting Maven
Hi, Some sites: [A] http://java.sun.com/javase/ [B] http://ant.apache.org/ Some notes: 1) L.H.S nav categories are concise. For example, "Reference" in [A] above has links to all documentation resources. "Community" has all the stuff about forums, issues etc etc (can map to JIRA, mailing lists, irc) 2) I like Brett's idea on trails, +1. See below for another tail example; these are nicely categorised based on user's level of experience and also what they intend to do. http://java.sun.com/docs/books/tutorial/index.html 3) I like the idea of minimal clicks to the dowload pages for binary and sources , see [B]. Current Maven site is fine for binary download but I don't see any downloads for sources? Also, is there a way to track the Frequently Viewed Pages (FVP), the nav structure could be re-factored if any FVP are nested 'too' deep! But that will be something to monitor over time :-) The above are by no means definitive, just indicative. I am sure there are lots of other (and may be better) examples out there. cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, June 20, 2006 1:12 AM Subject: Re: [Proposal] Documenting Maven On 19 Jun 06, at 8:54 AM 19 Jun 06, Brett Porter wrote: On 19/06/2006 10:47 PM, Jason van Zyl wrote: Then I'll work with John and yourself to bring them back into the discussions on the mailing list. I'm curious to see what might fall out though I might just be setting myself up to be disappointed by lack of involvement but I'll give a shot. I think there are at least 5 people who are interested and would do something. As you said Raphael already did something. Where is his stuff? cool. That one is MNG-2143. There are a good set of categories in there for a set of index pages. Tim promised one in the past but I never saw it pop up. I've pinged him again already. Wendy has proposed using the wiki for the cookbook section John mentioned, IIUC. Wanted to investigate that further. Other people we might hear from are Rahul (who's working on Plexus docs) and Dennis (who's patched more Maven docs than anyone). I certainly think it is worth putting a call out and I'm sure you'll get a lot of opinions, however I'd just like to minimise the amount of rehashing we do which is why I'm trying to pull the previous stuff together first. Finishing it now... The opinions considered will be limited to those who actually gives us some favorite sites and example maven sites. I'll call that an opinion with substance. - 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] Jason van Zyl [EMAIL PROTECTED] - 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: Fw: [plexus-dev] Plexus Website
Yep, I am on that task to get them organized and published. Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, June 15, 2006 6:09 PM Subject: Re: Fw: [plexus-dev] Plexus Website That's a good idea too :) I was actually thinking of taking the ideas from John's thread on the Maven documentation and applying the same principles, but it'd be good to hear what Maven plugin people think of the plexus docs. Perhaps best to get through the current round of polishing them up and actually publishing them along with the existing todo list before getting too much feedback that says "there's nothing there" :) - Brett Rinku wrote: Greetings everyone, We are keen to gather inputs for Plexus documentation/website from users on this list. Please see the attached emails below for a heads up. Ideas and suggestions are welcome; contributions are even better :-) Look forward to hear... cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 15, 2006 5:22 PM Subject: Re: [plexus-dev] Plexus Website Rinku wrote: Greetings, There's been a growing interest on IRC lately in Plexus and I quickly wanted to touch base on Plexus website and documentation: 1) Is anyone working on the website content to move from current Confluence base to APT based? If not, I am happy to pick this activity up. you are :) Everything in Confluence is in APT (most of it needs editing). I deleted all the Confluence content as it was outdated and/or needed significant editing. 2) Does any one have any thoughts, ideas that they would like to share or like to see included in the website? I like the trails approach. Let's just feed off the discussion on [EMAIL PROTECTED] for further ideas. There's a doc in SVN about "things that need to be documented too". - Brett -- Brett Porter <[EMAIL PROTECTED]> Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: [plexus-dev] Plexus Website
Greetings everyone, We are keen to gather inputs for Plexus documentation/website from users on this list. Please see the attached emails below for a heads up. Ideas and suggestions are welcome; contributions are even better :-) Look forward to hear... cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 15, 2006 5:22 PM Subject: Re: [plexus-dev] Plexus Website Rinku wrote: Greetings, There's been a growing interest on IRC lately in Plexus and I quickly wanted to touch base on Plexus website and documentation: 1) Is anyone working on the website content to move from current Confluence base to APT based? If not, I am happy to pick this activity up. you are :) Everything in Confluence is in APT (most of it needs editing). I deleted all the Confluence content as it was outdated and/or needed significant editing. 2) Does any one have any thoughts, ideas that they would like to share or like to see included in the website? I like the trails approach. Let's just feed off the discussion on [EMAIL PROTECTED] for further ideas. There's a doc in SVN about "things that need to be documented too". - Brett -- Brett Porter <[EMAIL PROTECTED]> Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Documenting Maven
+1 for documentation reorganization on the Maven website. Also, quickly wanted to add that documenting Maven would, IMHO, encompass a number of other projects/sub-projects (For instance ones appearing in the top navigation on the Maven homepage). I think we need to include them in the scope as well. Thoughts? Cheers, Rahul John Casey wrote: Hi everyone, I know we've talked about this quite a bit already. Actually, I'm having trouble finding the past threads on this topic in my email...can someone who knows please link them in? Basically, I've talked to Brett, Jason, and a few other Maven developers, and I think it's time we started making website documentation a top priority for Maven. I doubt anyone will argue on that point, but what we really need to agree on is what to document (priorities), and how to represent it on the site (layout). I've been working on a proposal today, which would give my thoughts on both the layout and the content. It's mostly just a large outline; some of it represents a potential Table of Contents or something similar for the website, and some of it represents the types of documentation and particular qualities I think we need to address. I've put my ideas here: http://www.commonjava.org/~jdcasey/maven-documentation-proposal.html I apologize if it looks like I ripped off someone else's ideas...I honestly cannot find those old email threads, and I'm not entirely sure how closely this will track against the emergent consensus. I've separated the list into two broad categories: Core Documentation and Plugin Documentation. First, I'd like to summarize the core side, then I'll talk briefly about the plugins side. Core Documentation 1. We need to reorganize the website. For anyone who has spent any time supporting Maven, it's obvious that what information we do have on the website is nearly impossible to navigate. After looking at some other project websites, and remembering what I find that works well, I think it might be a good idea to represent the website as a set of manuals. Each manual would be linked using a top-level menu item, and would have a strong organization (Table of Contents) within. This concept is somewhat loosely applied in the list of items, which has headings like Overview Material, User's Guide, Getting Involved (which contains the Developer's Guide), Cookbook, Reference, etc. I'll let you all take a look at those collapsing lists for more detail. 2. We need to address the consistency of the site's navigation. The site feels like a bunch of nested websites that just happen to share the same logo and CSS. In many cases, traversing a level or two down results in a completely new set of navigational elements on the left! I think we need to make that left navigation consistent, and provide some sort of breadcrumb functionality to help give the current page context. Whether these breadcrumbs are in the form of a list at the top, or a folder analogy in the left navigation, or something else, is another question. Plugin Documentation 1. We need to publish and validate against some sort of plugin documentation standards. Plugins all need to provide some of the same basic elements of information in order to be usable. It's even simpler if these elements are consistently named across the set of plugins we index, since the user will always know what sorts of things to expect when he clicks on Overview. I think we should publish some sort of standard that addresses minimal information requirements in the following areas: * POM Information - We need to have some basic organizational information about the team that developed the plugin, along with the project information itself. - Contributors / Developers - SCM URLs - CI Information * Generated Plugin Documentation - This is derived from the annotations given to designate the different parts of a plugin, and should be adequate as "quick reference" information. - Mojo-level descriptions provided in the class-level javadoc of all mojo classes - Parameter-level descriptions provided in the field-level javadoc of all mojo parameters - NOTE that @readonly and @component should be suppressed from generated docs. - Minimum set of generated reports like: javadoc, changelog, etc. * Authored Documentation - This will be a set of documents in src/site/** which will give the user enough information to use the plugin effectively. It should include at minimum: - Overview (overview.html) - What does the plugin do? What are its features? (NOTE: could be changed to index.html...not sure) - Usage (usage.html) - Outlines configuration for "normal" use cases. - Examples (examples/**) - Provides a set of single-scenario documents that perform the following functions: 1. Provide a context for the plugin's usage - what problem are we trying to solve? 2. Follow a real-world exa
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: Eclipse/OSGi and Maven 2
Hi , You might want to have a look at Buckminster project under Eclipse as well as raise this on their lists/newsgroup. cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Friday, June 09, 2006 5:26 PM Subject: Re: Eclipse/OSGi and Maven 2 It's totally possible, but you're probably going to need a custom Maven installation at this point. - Brett Wendell Beckwith wrote: I recently raised from the dead the previous talk about mavenizing the development of eclipse (or rather OSGi bundles) plugins, The thread can be seen here, http://dev.eclipse.org/mhonarc/lists/pde-build-dev/maillist.html. My question for the devs is that if we need to modify m2's dependency resolution where do we start? Brett previously mentioned, http://dev.eclipse.org/mhonarc/lists/pde-build-dev/msg00075.html, that maven might be configured with an alternate resolver. Has this happened or are we breaking new ground here? Wb -- 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: maven-eclipse-plugin and Eclipse Plugin support
Hi Reinhard, Some notes inlined below: Reinhard Poetz wrote: Rinku wrote: So far I added the configuration parameter "pde". If set to true, the PluginNature and the schema and manifest builders are added to .project. I have a patch submitted for this for the maven-eclipse-plugin. Though not sure when that gets integrated into the plugin. IMHO you would not need a separate config param but just detect the natures being specified in the config and that should set up PDE project definition. My idea was consistency with the WTP configuration parameter, less typing and I'm sure that I will never remember the class name of the nature ;-) While I agree to the inability to remember the name of PDE natures, I am not really sure about having a WTP configuration parameter either. The current plugin implementation adds the list of natures specified from the plugin config. Not sure why we should deviate in case of adding the PDE Plugin nature? Having said that, if there is a better way to handle Eclipse project natures (in general) rather than specifying them as fully qualified names in the plugin config - then best to raise suggestions on this list :-) Additionally, instead of pointing to libraries in the local repository, I copy them to "target/osgi/lib" and point to them from within .classpath - unfortunatly PDE doesn't allow referencing libraries outside of the project (as you describe in 3). Yep, I noticed that too. Just curious why do want to copy them to the target/osgi/lib and then reference them from there. Why not copy them under the PDE project/osgi/lib directory (and may be add that folder to ignore list in for CVS/SVN). My initial idea was that a "mvn clean" should remove them. But I'm not sure about this. I think it would be nice to be able create symlinks to JARs in M2_REPO from a /lib directory (for example) and then copy the actual JARs when the Plugin is packaged(from a maven build). Though I am not sure how Eclipse PDE would handle symlinks. But I think its a cleaner way rather than copying around the whole shebang! I think you will need to update both .classpath and Manifest.mf (see 3) for the libs. Yes, the cocoon-maven-eclipse-plugin already does so. Cool! I haven't had a chance to look cocoon version's sources but keen to. Before I will provide a patch, I will implement what you describe in 2). I was thinking of keeping "Bundle-ClassPath" in sync with the libraries in "target/osgi/lib". You can also look under Apache Felix sources, they have a maven osgi plugin implemented, may be you can draw some ideas from there as well. Thanks for the pointer! Thanks for the note. I had indeed missed your response :-) Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: creating a new project with the MavenEmbedder
Hi Hermod,
Coincidently, there was a thread on maven-users list about delegating
goal to another mojo (see yesterday's posts). I have posted a similar
code snippet there that uses embedder, you might want give it a try if
you want to stick to released version.
HTH,
Rahul
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Tuesday, May 30, 2006 12:34 AM
Subject: RE: creating a new project with the MavenEmbedder
Hi
Ok, I'll get it from SVN and compile it. Thnx
Hermod
-Original Message-
From: Ovidio Mallo [mailto:[EMAIL PROTECTED]
Sent: Monday, May 29, 2006 1:58 PM
To: Maven Developers List
Subject: Re: creating a new project with the MavenEmbedder
Hi Hermod!
The class compiles against the current 2.1-SNAPSHOT version. The
previous
versions 2.0.3 and 2.0.4 seem to have a somewhat different API, so it
will
not compile with those. Prior to my original post on this subject, I was
trying to get the whole thing working with the version 2.0.4, but
failed,
so I'm not sure whether it is possible to achieve the same thing with
the old API.
Unfortunately, since the version 2.1-SNAPSHOT is probably not on the
central
repository, you probably have to compile it from the sources. That's at
least what I did.
Hope that helps!
Best regards,
Ovidio
[EMAIL PROTECTED] wrote:
Hi
Which version of the embedder is this? I get errors on the methods:
getUserSettingsPath and getGlobalSettingsPath - No such methods in the
Maven embedder (2.0.3).
Hermod
-Original Message-
From: Ovidio Mallo [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:36 PM
To: Maven Developers List
Subject: Re: creating a new project with the MavenEmbedder
Hi,
Thanks a lot, Kenney, for your explanation and code snippet! This is
exactly what I was looking for! I have filled in the tiny missing
details in your sample code to build up a working example which you
can find below. Just in case anyone else is interested in it.
One thing I noticed is that the example should not be run from
within a directory containing a pom.xml file since, otherwise,
this project file is interpreted as being the parent model file!
Well, again, thanks a lot!
Regards,
Ovidio
public class ProjectCreator {
public static void main(String[] args) throws Exception {
MavenEmbedder embedder = new MavenEmbedder();
embedder.setClassLoader(
Thread.currentThread().getContextClassLoader() );
embedder.setLogger( new MavenEmbedderConsoleLogger() );
embedder.start();
Settings settings = embedder.buildSettings(
embedder.getUserSettingsPath( null ),
embedder.getGlobalSettingsPath(),
false,
false,
false,
Boolean.FALSE );
Properties properties = new Properties();
properties.put( "groupId", "net.sytes.meco" );
properties.put( "artifactId", "new_project" );
MavenExecutionRequest request = new
DefaultMavenExecutionRequest()
.setBasedir( new File( "/tmp" ) )
.setGoals( Arrays.asList( new String[] {
"archetype:create" } ) )
.setLocalRepositoryPath( embedder.getLocalRepositoryPath(
settings ) )
.setSettings( settings )
.setProperties( properties )
.addEventMonitor(
new DefaultEventMonitor(
new ConsoleLogger( ConsoleLogger.LEVEL_DISABLED,
"logger" ) ) );
embedder.execute( request );
}
}
Kenney Westerhof wrote:
> On Sat, 27 May 2006, Ovidio Mallo wrote:
>
> Hi,
>
> Well, currently running archetype:create seems the simplest way to
me.
> The embedder is primarily meant to build projects, not to create
them.
>
> You might want to take a look at the maven-cli project. Some
plugins, like
> archetype, don't require an existing pom.xml.
>
> A sequence like this (more or less) should work for you:
>
> MavenEmbedder embedder = new MavenEmbedder();
>
> embedder.start();
>
> Settings settings = embedder.buildSettings(
> embedder.getUserSettingsPath( null ),
> embedder.getGlobalSettingsPath(),
> false,
> false,
> false,
> false );
>
> Properties properties = new Properties();
> // set archetype parameters in properties
>
> MavenExecutionRequest request = new DefaultMavenExecutionRequest()
> .setBasedir(..)
> .setGoals( Arrays.asList( new String[] { "archetype.create" } )
> .setLocalRepositoryPath( embedder.getLocalRepositoryPath(
settings )
> .setSettings( settings )
> .setProperties( properties );
>
> embedder.execute( request );
>
> .. and we don't set a pom file here.
>
> Good luck!
>
> -- Kenney
>
>
>
>>Hi everyone!
>>
>>I just wanted to ask whether there is a clean way to create a new
maven
>>project using the MavenEmbedder API. It is of course possible to
>>execute the "archetype:create" goal but the API seems to always
>>requ
Re: maven-eclipse-plugin and Eclipse Plugin support
Hi Reinhard, Some notes inlined.. 1) Running eclipse:eclipse should generate the project definition just as it does now, it detects if a "org.eclipse.pde.PluginNature" is specified for .project and setups the PDE nature (updates to .classpath) accordingly. 2) A Bundle Manifest writer could write out the Bundle Manifest. We could default some of the headers to 'sensible' default values (extracted from pom.xml), and allow for user to specify them via configuration for the Eclipse plugin. 3) Plugin dependencies could be copied from the local M2 repo to under /lib and Manifest updated for Bundle-Classpath values. I thought I'd rake up a discussion :-) As Cocoon 3.0 will be based on OSGi I need PDE support too. For the time being I started with a branch of the maven-eclipse-plugin within the Cocoon SVN tree (see http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-maven-eclipse-plugin/). The goal is providing a patch for the "offical" maven eclipse plugin within the next weeks. So far I added the configuration parameter "pde". If set to true, the PluginNature and the schema and manifest builders are added to .project. I have a patch submitted for this for the maven-eclipse-plugin. Though not sure when that gets integrated into the plugin. IMHO you would not need a separate config param but just detect the natures being specified in the config and that should set up PDE project definition. Additionally, instead of pointing to libraries in the local repository, I copy them to "target/osgi/lib" and point to them from within .classpath - unfortunatly PDE doesn't allow referencing libraries outside of the project (as you describe in 3). Yep, I noticed that too. Just curious why do want to copy them to the target/osgi/lib and then reference them from there. Why not copy them under the PDE project/osgi/lib directory (and may be add that folder to ignore list in for CVS/SVN). I think you will need to update both .classpath and Manifest.mf (see 3) for the libs. Before I will provide a patch, I will implement what you describe in 2). I was thinking of keeping "Bundle-ClassPath" in sync with the libraries in "target/osgi/lib". You can also look under Apache Felix sources, they have a maven osgi plugin implemented, may be you can draw some ideas from there as well. What do you think? Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-eclipse-plugin and Eclipse Plugin support
Hi, Not sure if there is some work in progress for Eclipse Plugin support but here are some quick notes on the following logged in JIRA http://jira.codehaus.org/browse/MECLIPSE-92 http://jira.codehaus.org/browse/MECLIPSE-103 1) Running eclipse:eclipse should generate the project definition just as it does now, it detects if a "org.eclipse.pde.PluginNature" is specified for .project and setups the PDE nature (updates to .classpath) accordingly. 2) A Bundle Manifest writer could write out the Bundle Manifest. We could default some of the headers to 'sensible' default values (extracted from pom.xml), and allow for user to specify them via configuration for the Eclipse plugin. 3) Plugin dependencies could be copied from the local M2 repo to under /lib and Manifest updated for Bundle-Classpath values. I thought I'd rake up a discussion :-) What do others think? Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (CONTINUUM-663) Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin
Hi Kenney, I wasn't aware I could create an SVN repo on codehaus. Thanks for the suggestion, though I am not sure how to use svnadmin and don't want to stuff up anything on the server :-). But definately sounds like a better solution and will read up on that, or if you have a resource handy please let me know. Thanks for that! Cheers, Rahul - Original Message - From: "Kenney Westerhof" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, May 02, 2006 8:47 PM Subject: Re: [jira] Commented: (CONTINUUM-663) Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin On Tue, 2 May 2006, Rinku wrote: Hi, You can always create a repository yourself using svnadmin, set file permissions accordingly, and people with a codehaus account can svn+ssh:// to it then. But samples are best just attached to jira using an archive, and updates attached as a patch. No need to version control this, right? -- Kenney Hi Vincent, I was hoping I escape getting beaten up for putting them there temporarily! :-) I don't think I can version control under public_html directory, can I? if it might be an issue, I am happy to remove them and look for an alternative. Let me know. Cheers, Rahul - Original Message - From: "Vincent Massol" <[EMAIL PROTECTED]> To: Sent: Tuesday, May 02, 2006 7:23 PM Subject: RE: [jira] Commented: (CONTINUUM-663) Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin > Hi Rahul > > Can I ask why you hijack the faqbot's project for this? :-) You have > an > account @ codehaus so you can put any file you want in there (in > your > public_html/ directory), for example. I think it's much cleaner this > way... > > Thanks > -Vincent > >> -Original Message- >> From: Rahul Thakur (JIRA) [mailto:[EMAIL PROTECTED] >> Sent: mardi 2 mai 2006 09:19 >> To: issues@maven.apache.org >> Subject: [jira] Commented: (CONTINUUM-663) Google Summer Of Code >> 2006 >> proposal for Continuum Eclipse Plugin >> >> [ http://jira.codehaus.org/browse/CONTINUUM- >> 663?page=comments#action_64536 ] >> >> Rahul Thakur commented on CONTINUUM-663: >> >> >> A quick note: >> SoC related updates can be checked out from: >> >> https://svn.codehaus.org/faqbot/trunk/sandbox/continuum-eclipse-plugin >> >> https://svn.codehaus.org/faqbot/trunk/sandbox/refactored-continuum-xfire >> >> >> > Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin >> > - >> > >> > Key: CONTINUUM-663 >> > URL: http://jira.codehaus.org/browse/CONTINUUM-663 >> > Project: Continuum >> > Type: New Feature >> >> > Environment: Maven 2.0.x, Continuum 1.0.x, Eclipse 3.2 >> > Reporter: Rahul Thakur >> > Attachments: >> > Continuum-Eclipse-plugin-Google-SOC2006-proposal.txt, >> Continuum-Eclipse-plugin-Google-SOC2006-proposal.txt >> > >> > Original Estimate: 8 weeks >> > Remaining: 8 weeks >> > >> > It is proposed for Google SOC 2006 to develop a Continuum Eclipse >> > Plugin >> that could be used by Eclipse users to manage project builds on a >> remote >> Continuum server. >> >> -- >> This message is automatically generated by JIRA. >> - >> If you think it was sent incorrectly contact one of the >> administrators: >>http://jira.codehaus.org/secure/Administrators.jspa >> - >> For more information on JIRA, see: >>http://www.atlassian.com/software/jira > > > > > > > ___ > Faites de Yahoo! votre page d'accueil sur le web pour retrouver > directement vos services préférés : vérifiez vos nouveaux mails, > lancez vos recherches et suivez l'actualité en temps réel. > Rendez-vous sur http://fr.yahoo.com/set > > - > 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] -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (CONTINUUM-663) Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin
Hi Vincent, I was hoping I escape getting beaten up for putting them there temporarily! :-) I don't think I can version control under public_html directory, can I? if it might be an issue, I am happy to remove them and look for an alternative. Let me know. Cheers, Rahul - Original Message - From: "Vincent Massol" <[EMAIL PROTECTED]> To: Sent: Tuesday, May 02, 2006 7:23 PM Subject: RE: [jira] Commented: (CONTINUUM-663) Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin Hi Rahul Can I ask why you hijack the faqbot's project for this? :-) You have an account @ codehaus so you can put any file you want in there (in your public_html/ directory), for example. I think it's much cleaner this way... Thanks -Vincent -Original Message- From: Rahul Thakur (JIRA) [mailto:[EMAIL PROTECTED] Sent: mardi 2 mai 2006 09:19 To: issues@maven.apache.org Subject: [jira] Commented: (CONTINUUM-663) Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin [ http://jira.codehaus.org/browse/CONTINUUM- 663?page=comments#action_64536 ] Rahul Thakur commented on CONTINUUM-663: A quick note: SoC related updates can be checked out from: https://svn.codehaus.org/faqbot/trunk/sandbox/continuum-eclipse-plugin https://svn.codehaus.org/faqbot/trunk/sandbox/refactored-continuum-xfire > Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin > - > > Key: CONTINUUM-663 > URL: http://jira.codehaus.org/browse/CONTINUUM-663 > Project: Continuum > Type: New Feature > Environment: Maven 2.0.x, Continuum 1.0.x, Eclipse 3.2 > Reporter: Rahul Thakur > Attachments: Continuum-Eclipse-plugin-Google-SOC2006-proposal.txt, Continuum-Eclipse-plugin-Google-SOC2006-proposal.txt > > Original Estimate: 8 weeks > Remaining: 8 weeks > > It is proposed for Google SOC 2006 to develop a Continuum Eclipse > Plugin that could be used by Eclipse users to manage project builds on a remote Continuum server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ___ Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Rendez-vous sur http://fr.yahoo.com/set - 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]
Classpath hell or artifact naming inconsistency?
Hi, I've been trying to get unit tests running for a continuum component while developing in Eclipse. With help from developers on IRC I did manage to get the unit tests running from within Eclipse. But on running them from command prompt, my unit tests still fail. I suspect it might be multiple versions of Plexus related JARs loaded on classpath due to different groupIds for testing, I have posted the relevant output after turning 'debug' on the maven build here : http://rafb.net/paste/results/w2SJPC20.html Appreciate any suggestions for workaround/fixes. Thanks, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How can I add a component/service to Continuum?
Hi, I have created a service/component which I would like to add to my local Continuum installation. Any idea how can achieve it? TIA, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2 trunk] build test failures
Hi, I revisited this again, put some system.out's in the org.apache.maven.it.Verifier source and skimmed thru SVN logs. After the last commit to "org.apache.maven.it.Verifier", the resolveCommandLineArg( String key ) call from executeHook(String filename) method blows up with a StringIndexOutOfBoundsException while attempting regexp replace (stack below). Commenting out that call (basically reverting to the last SVN revision) gets a successful build (not sure if its right, though)! Attached is a quick test to simulate the issue. I have tried swapping the JDKs 1.5.0 and 1.6.0 - same result. I made some minor changes to the code while testing this out so the stacktrace below might not reflect actual line numbers, but you'll get the idea :-) Cheers, Rahul Error Stacktrace: org.apache.maven.it.VerificationException: java.lang.StringIndexOutOfBoundsException: String index out of range: 1 at org.apache.maven.it.Verifier.executeHook(Verifier.java:367) at org.apache.maven.it.Verifier.main(Verifier.java:863) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1 at java.lang.String.charAt(String.java:566) at java.util.regex.Matcher.appendReplacement(Matcher.java:696) at java.util.regex.Matcher.replaceAll(Matcher.java:806) at java.lang.String.replaceAll(String.java:2028) at org.apache.maven.it.Verifier.resolveCommandLineArg(Verifier.java:699) at org.apache.maven.it.Verifier.executeHook(Verifier.java:356) ... 1 more << Error Stacktrace - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Saturday, April 01, 2006 2:09 PM Subject: Re: [m2 trunk] build test failures Rahul Thakur wrote: Hey everyone, I am noticing quite a few IT test failures on the latest SVN snapshot from trunk, wondering if there are any refactorings/major changes taking place?? Here's the bunch that failed: 69/100 passed Failed tests: [it0099, it0092, it0089, it0088, it0087, it0086, it0077, it0073, it0071, it0068, it0067, it0064, it0062, it0051, it0049, it0041, it0035, it0034, it0030, it0029, it0021, it0020, it0018, it0013, it0009, it0008, it0007, it0005, it0004, it0003, it0002] I am on WinXP, JDK build 1.6.0-beta2-b76 and of course latest Maven 2.1-SNAPSHOT. Is that Mustang you're using? If so have you tried a JVM used by most mortals? :-) Any one else noticing? Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r384810 - /maven/pom/asf/pom.xml
Are you using Eclipse to commit? I have noticed this behaviour with Eclipse when committing to CVS (not sure about SVN). If I commit a resource with $Id$ using tortoiseSVN for first ever commit, the $Id$ gets interpolated correctly for all subsequent commits (even from within Eclipse)... Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Saturday, March 11, 2006 1:21 PM Subject: Re: svn commit: r384810 - /maven/pom/asf/pom.xml SVN is meant to fill it in, and I had svn:keywords set correctly, but it wasn't working. I think it would leave the $$ on there anyway so I Realised it wasn't what I wanted. - Brett dan tran wrote: Hi Brett, What is $Revision$ ? -D On 3/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: brett Date: Fri Mar 10 07:17:04 2006 New Revision: 384810 URL: http://svn.apache.org/viewcvs?rev=384810&view=rev Log: try using keyword Modified: maven/pom/asf/pom.xml Modified: maven/pom/asf/pom.xml URL: http://svn.apache.org/viewcvs/maven/pom/asf/pom.xml?rev=384810&r1=384809&r2=384810&view=diff == --- maven/pom/asf/pom.xml (original) +++ maven/pom/asf/pom.xml Fri Mar 10 07:17:04 2006 @@ -24,7 +24,7 @@ define the settings common to all projects at Apache --> org.apache apache - 1 + $Revision$ pom The Apache Software Foundation - 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: Making the current web site suck less
Since we talk about 'latest and greatest', I wonder why javadocs published online cannot serve as 'latest and greatest' docs? I am +1 to Carlos' idea about documenting almost all methods. If we were to publish API docs for Maven and Plugins on the website (some separate URL) with every Maven release build or every nightly build, at least they would always reflect the 'latest and greatest' for the code. Cheers, Rahul Brian K. Wallace wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wendy Smoak wrote: On 3/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: * I'm still a little torn on where plugin docs go. No hurry on this, but something to ponder. We definitely need to make the references for those integrate better. Site/skin inheritance will help No matter where they go, I think they need to be updated more often. Random example... the assembly plugin docs are wrong, and have been that way for months. (it's descriptorId, not maven.assembly.descriptorId.) * http://maven.apache.org/plugins/maven-assembly-plugin/howto.html I would like to see the "latest and greatest" docs on the main site. Yes, they'll be ahead of the released version, but not by much, and (hopefully) not for long.When the answer to a lot of "X doesn't work" questions is "It's fixed in the trunk, use a snapshot," it would be nice to have the snapshot docs available in a centralized place. This also makes it more fun to contribute to the documentation, because you get to see your work "in print" right away. Thanks for updating the main site. :) -- Wendy While I agree that it would be nice to have the 'latest and greatest' docs on the main site, I don't believe having them as the only documentation is a good idea at all. The documentation should be able to evolve after a release to make them better, but having documentation online that applies to "trunk" code and not released code tends to equate "bad documentation" (the docs say I can do X. "oh, that's in the trunk, use a snapshot"). If you aren't going to have two sets - one for released code and one for trunk code, only go with released code. If there are changes that can be made to make the released code's documentation better between releases, by all means - make it live as soon as practical. My .02 Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEDjrpaCoPKRow/gARAiGlAJ98kZI0ItEEusrpmgIAT/jaQBaLXgCfbUhi 8iPFWc+Loyp9VtbXHxd6eqY= =cs6U -END PGP SIGNATURE- - 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: making docs and tests suck less
Hi, My response inline... Tim O'Brien wrote: Developers don't write great documentation. Don't raise the bar so high that people are discouraged from submitting doco-less patches. Just create a structure to address documentation deficiency. Sorry, but IMHO that's too much of a generalization on developer's 'documentation' skills and I don't agree... and definately not for for a project like Maven. Ideas jotted in Brett's email are worth implementing and I commend him and the team on putting them forth for a discussion here. I am sure Maven community will notice if the bar is set too high! 1. Create a documentation posse - identify people who will focus solely on doco, reduce the barriers for them to commit. Or, move documentation to an external project with lower barriers to entry. -1 for external project, documentation is intrinsic to the project, not sure what's the benefit of having another external project. 2. Consider a separate list - people removed from the development process produce better documentation. -1, user and dev lists are suited enough for doc related questions/discussions. Enough mails are floating on these lists to gather ideas and content for documentation. I am not aware of an instance where this generalization above about producing better documentation by people not in development applies. 3. Add "Waiting for Documentation" as a stage in a customized JIRA workflow. Instead of creating separate issues for "Document what I just did in the Site Plugin", give developers the opportunity to just mark something as implemented but undocumented (otherwise know n as useless and invisible) [snip] Cheers, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 Command mvn -P
The '-P' switch is used to activate build profiles. See this to view all goals for a plugin: http://docs.codehaus.org/display/MAVENUSER/FAQs?showComments=true&showCommentArea=true#FAQs-Howtolistallgoalsavailableforacertainplugin%3F HTH, Rahul - Original Message - From: "Dave Maung" <[EMAIL PROTECTED]> To: Sent: Saturday, January 21, 2006 11:57 AM Subject: Maven 2 Command mvn -P I am starting to try maven 2. The command that I always use was mvn -P plugin to see list of sub goals avaiable. However in Maven 2, this feature doesn't work anymore. example: mvn -P scm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 Embedder source
If you check out Maven 2 sources, embedder module is included. http://maven.apache.org/source-repository.html Cheers, Rahul - Original Message - From: "Dave Maung" <[EMAIL PROTECTED]> To: Sent: Saturday, January 21, 2006 10:54 AM Subject: Maven2 Embedder source Hi, Where can I Maven 2 Embedder source code? In Maven homepage, I dont see any information to download the Maven 2 Embeeder source. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Integration testing location
Hi, Has this discussion thread reached a decision yet? Jason's idea of pre/post phase decorators sounds great. My understanding was that the decorators will be able to address cases like pre-pre-compile etc... - so basically, upto the user to use 'n' number of phase decorators. I think its a great feature to have in Maven. I'd suppose a change like this would be targeted for 2.1, right? Cheers, Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Thursday, December 29, 2005 4:04 PM Subject: Re: [discussion] Integration testing location Brett Porter wrote: If we just do pre/post, won't the next point be that pre-pre-compile is needed? I imagine that 90% of what people do will be covered by the standard lifecycle, 5% of people might make custom lifecycle and 5% might need to do some really weird stuff with a big pile of rope like the pre-pre-compile. I think the majority of people would use the standard lifecycle where possible and resort to the less encourage approached only where absolutely necessary. If all we have is two cases which might require lifecycle alterations then the pre/post decoration maybe not be required. But it's the things that we can't think about that we should try to account for. Sometimes you may not want to create a plugin to trigger a customized lifecycle for a simple decoration. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Simplex sigillum veri. (Simplicity is the seal of truth.) - 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: Mapping complex object in Mojo Configuration
Hi Mark,
The problem is not with the multiple nested tags. The inner
nested tag rightly maps to a Configuration class in the Mojo,
the problem is with assigning one of the fields in the Configuration POJO of
type java.lang.Class which should pick value from 'implementation', it fails to
load the class.
Thanks for the note though!
Cheers,
Rahul
- Original Message -
From: "Mark Struberg" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Tuesday, January 03, 2006 11:45 PM
Subject: Re: Mapping complex object in Mojo Configuration
Maybe it is a really complex problem, but
maybe there is only a problem with the 2 nested
entries?
org.codehaus.cargo
cargo-maven2-plugin
-->
true
-->
com.effacy.sample.EffacyTomcatConfiguration
${project.build.directory}/tomcat5x/container
standalone
May u please check if it works when u change the 2nd
tag in for example?
txs in advance and best regards,
struberg
org.codehaus.cargo:cargo-maven2-plugin. Reason:
Unable to parse the
created DOM for plugin configuration
--- Brett Porter <[EMAIL PROTECTED]> schrieb:
Good point. It's probably looking in the plexus
classloader.
I'd need to investigate further how to get the
correct classloader. If
you'd like to do so yourself, the class to change is
plexus/plexus-containers/plexus-container-default/src/main/java/org/codehaus/plexus/component/configurator/basic/ClassConverter.java
Cheers,
Brett
Rinku wrote:
> Hi ,
>
> I did relevant updates to m2 sources on local and
updated m2 install for
> plexus-container-default verison
1.0-alpha-10-SNAPSHOT. But still
> running into a ClassNotFound error. Looks like its
coming from
> Classworld libs.
>
> I have posted the stacktrace at:
> http://www.rafb.net/paste/results/tke4hi45.html
>
> Could this be a Realm related issue with
Classworlds (sorry, not very
> well-versed with Classworlds). I am sure that
implementation class I am
> specifying is available via dependencies in
project's pom.xml. Am I
> missing something here or could this be a bug?
>
> Cheers for any help!
>
> Rahul
>
>
> - Original Message - From: "Brett Porter"
<[EMAIL PROTECTED]>
> To: "Maven Developers List"
> Sent: Tuesday, January 03, 2006 10:46 AM
> Subject: Re: Mapping complex object in Mojo
Configuration
>
>
>> There is no plexus converter for String -> Class.
We should probably
>> have one, so I'll add it now.
>>
>> You'll need to use a String and do the forName
yourself in the mean time.
>>
>> - Brett
>>
>> Rahul Thakur wrote:
>>> Hi,
>>>
>>> I am following the mini guide to set up a
complex mapping for a Mojo.
>>>
http://maven.apache.org/guides/mini/guide-configuring-plugins.html
>>>
>>> The POJO that models the complex type for Mojo
configuration has a field
>>> 'implementation' of type java.lang.Class.
>>>
>>> When I run the Mojo, I get an error:
>>> Cause: Cannot assign configuration entry
'implementation' to 'class
>>> java.lang.Class' from
'com.effacy.sample.EffacyTomcatConfiguration',
>>> which is of type class java.lang.String
>>>
>>> The Plugin configuration for my Mojo is as
follows:
>>>
>>>org.codehaus.cargo
>>>
cargo-maven2-plugin
>>>
>>> true
>>>
>>>
>>>
com.effacy.sample.EffacyTomcatConfiguration
>>>
>>>
>>>
${project.build.directory}/tomcat5x/container
>>>standalone
>>>
>>>
>>>
>>>
>>> I am not sure what's wrong here?? I am
reproducing the stacktrace below
>>> and would appreciate any pointers.
>>>
>>> Thanks in advance,
>>>
>>> Rahul
>>>
>>>
>>> Cause: Cannot assign configuration entry
'implementation' to 'class
>>> java.lang.Class' from
'com.effacy.sample.EffacyTomcatConfiguration',
>>> which is of type class java.lang.String
>>> [INFO]
>>>
>>>
>>>
>>> [INFO] Trace
>>>
org.apache.maven.lifecycle.LifecycleExecutionException:
Error
>>> configuring:
org.codehaus.cargo:cargo-maven2-plugin. Reason:
Unable to
>>> parse the created DOM for plugin configuration
>>>at
>>>
org.apache.maven.lifecycle
Re: Mapping complex object in Mojo Configuration
Hi Dan,
I believe this is slightly different - I am trying to set a field for a complex
type ( the field is of type 'java.lang.Class'). The complex type itself gets
instantiated fine but the issue comes when attempting to setup the field. Brett
drilled down the issue to be missing convertor impl (String -> Class) in plexus
container, and now it seems to a related to ClassLoader.
But even in case of what you are referring to you should be able to specify an
'implementation' attribute for your complex type and specify the implementing
class from a different package.
Cheers,
Rahul
- Original Message -
From: "dan tran" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Tuesday, January 03, 2006 12:59 PM
Subject: Re: Mapping complex object in Mojo Configuration
I think i ran to this before. The configuraiton object must be in the same
packge of your mojo.
Not sure if this helps thou.
-Dan
On 1/2/06, Rinku <[EMAIL PROTECTED]> wrote:
Hi ,
I did relevant updates to m2 sources on local and updated m2 install for
plexus-container-default verison 1.0-alpha-10-SNAPSHOT. But still running
into a
ClassNotFound error. Looks like its coming from Classworld libs.
I have posted the stacktrace at:
http://www.rafb.net/paste/results/tke4hi45.html
Could this be a Realm related issue with Classworlds (sorry, not very
well-versed with Classworlds). I am sure that implementation class I am
specifying is available via dependencies in project's pom.xml. Am I
missing
something here or could this be a bug?
Cheers for any help!
Rahul
- Original Message -
From: "Brett Porter" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Tuesday, January 03, 2006 10:46 AM
Subject: Re: Mapping complex object in Mojo Configuration
> There is no plexus converter for String -> Class. We should probably
> have one, so I'll add it now.
>
> You'll need to use a String and do the forName yourself in the mean
time.
>
> - Brett
>
> Rahul Thakur wrote:
>> Hi,
>>
>> I am following the mini guide to set up a complex mapping for a Mojo.
>> http://maven.apache.org/guides/mini/guide-configuring-plugins.html
>>
>> The POJO that models the complex type for Mojo configuration has a
field
>> 'implementation' of type java.lang.Class.
>>
>> When I run the Mojo, I get an error:
>> Cause: Cannot assign configuration entry 'implementation' to 'class
>> java.lang.Class' from 'com.effacy.sample.EffacyTomcatConfiguration',
>> which is of type class java.lang.String
>>
>> The Plugin configuration for my Mojo is as follows:
>>
>>org.codehaus.cargo
>>cargo-maven2-plugin
>>
>> true
>>
>>
>> com.effacy.sample.EffacyTomcatConfiguration
>>
>>${project.build.directory}/tomcat5x/container
>>standalone
>>
>>
>>
>>
>> I am not sure what's wrong here?? I am reproducing the stacktrace below
>> and would appreciate any pointers.
>>
>> Thanks in advance,
>>
>> Rahul
>>
>>
>> Cause: Cannot assign configuration entry 'implementation' to 'class
>> java.lang.Class' from 'com.effacy.sample.EffacyTomcatConfiguration',
>> which is of type class java.lang.String
>> [INFO]
>>
>>
>> [INFO] Trace
>> org.apache.maven.lifecycle.LifecycleExecutionException: Error
>> configuring: org.codehaus.cargo:cargo-maven2-plugin. Reason: Unable to
>> parse the created DOM for plugin configuration
>>at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:559)
>>
>>at
>>
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(
DefaultLifecycleExecutor.java:485)
>>
>>at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java:455)
>>
>>at
>>
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:303)
>>
>>at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments
(DefaultLifecycleExecutor.java:270)
>>
>>at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:139)
>>
>>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java
:322)
>>at org.apache.maven.DefaultMaven.execut
Re: Mapping complex object in Mojo Configuration
Hi ,
I did relevant updates to m2 sources on local and updated m2 install for
plexus-container-default verison 1.0-alpha-10-SNAPSHOT. But still running into a
ClassNotFound error. Looks like its coming from Classworld libs.
I have posted the stacktrace at:
http://www.rafb.net/paste/results/tke4hi45.html
Could this be a Realm related issue with Classworlds (sorry, not very
well-versed with Classworlds). I am sure that implementation class I am
specifying is available via dependencies in project's pom.xml. Am I missing
something here or could this be a bug?
Cheers for any help!
Rahul
- Original Message -
From: "Brett Porter" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Tuesday, January 03, 2006 10:46 AM
Subject: Re: Mapping complex object in Mojo Configuration
There is no plexus converter for String -> Class. We should probably
have one, so I'll add it now.
You'll need to use a String and do the forName yourself in the mean time.
- Brett
Rahul Thakur wrote:
Hi,
I am following the mini guide to set up a complex mapping for a Mojo.
http://maven.apache.org/guides/mini/guide-configuring-plugins.html
The POJO that models the complex type for Mojo configuration has a field
'implementation' of type java.lang.Class.
When I run the Mojo, I get an error:
Cause: Cannot assign configuration entry 'implementation' to 'class
java.lang.Class' from 'com.effacy.sample.EffacyTomcatConfiguration',
which is of type class java.lang.String
The Plugin configuration for my Mojo is as follows:
org.codehaus.cargo
cargo-maven2-plugin
true
com.effacy.sample.EffacyTomcatConfiguration
${project.build.directory}/tomcat5x/container
standalone
I am not sure what's wrong here?? I am reproducing the stacktrace below
and would appreciate any pointers.
Thanks in advance,
Rahul
Cause: Cannot assign configuration entry 'implementation' to 'class
java.lang.Class' from 'com.effacy.sample.EffacyTomcatConfiguration',
which is of type class java.lang.String
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error
configuring: org.codehaus.cargo:cargo-maven2-plugin. Reason: Unable to
parse the created DOM for plugin configuration
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
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:249)
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:589)
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.PluginConfigurationException: Error
configuring: org.codehaus.cargo:cargo-maven2-plugin. Reason: Unable to
parse the created DOM for plugin configuration
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1056)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:596)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530)
... 16 more
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Cannot assign configuration entry 'implementation' to 'class
java.lang.Class' from 'com.effacy.sample.EffacyTomcatConfiguration',
which is of type class java.lang.String
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.fromExpression(AbstractConfigurationConverter.java:149)
at
org.codehaus.plexus.component.configurator.converter
[m2] maven-eclipse-plugin: .wtpmodules gets generated even when pom packaging is not war/ear
Hi, I am wondering if there is a reason why the maven-eclipse-plugin generates a .wtpmodule (and WST natures in .project) even when no war/ear/wjb packaging is specified in pom.xml? Is this correct behaviour ? I think by default packaging should default to 'jar' and not generate any config for WTP. Could anyone please let me know if my understanding is incorrect. Thanks in advance. Cheers, Rahul
Re: [m2] Unable setup under (XmlPullParserException: Unrecognised tag)
Hi John,
ok, I see what you mean:
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
Can atleast be allowed in profiles.xml. I have a use-case
where it would make sense to have them in profiles.xml.
The use-case is as follows:
Lets says I have a web-project that sets up profiles.xml for target build
environments that it can be deployed on. Target environments can each have
different J2EE containers.
Now this is what happens when I put my project up for builds/deploys.
1) Set up a build control project, a minimal pom.xml that has contains SCM
connection to my web-project above.
2) checksout profiles.xml first so now the build control project has a
minimal pom + profiles.xml.
3) checks out the web-project under ${basedir}/target
4) I can activate a particular profile, based on which some operations can
be done by a custom Plugin before an embedded instance of maven is spawned
and some goals (specific to that profile) are delegated down to the checked
out project.
I got steps - 1, 2, 3 working and 4 working partially (delegation) but I am
hitting a blocker with the profiles :-( and can't reuse them.
Would it make sense to introduce to external profiles.xml so
these can be selectively included when a profile is activated. I would like
to invite a discussion on this and see if it merits it.
Thoughts please?
Cheers,
Rahul
- Original Message -
From: "John Casey" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Tuesday, December 20, 2005 6:01 AM
Subject: Re: [m2] Unable setup under
(XmlPullParserException: Unrecognised tag)
You cannot specify anything but properties, repositories, and
pluginRepositories (IIRC) outside of the POM itself. This is to help
ensure that POMs remain portable.
Rinku wrote:
Hi , I am trying to introduce selective dependencies based on profile
activation for a project, but i am encountering an exception (stacktrace
below)
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException:
Unrecognised tag: 'dependencies' (position: START_TAG seen
...\r\n... @12:19)
at
org.apache.maven.profiles.io.xpp3.ProfilesXpp3Reader.parseProfile(ProfilesXpp3Reader.java:577)
at
org.apache.maven.profiles.io.xpp3.ProfilesXpp3Reader.parseProfilesRoot(ProfilesXpp3Reader.java:617)
at
org.apache.maven.profiles.io.xpp3.ProfilesXpp3Reader.read(ProfilesXpp3Reader.java:1126)
at
org.apache.maven.profiles.DefaultMavenProfilesBuilder.buildProfiles(DefaultMavenProfilesBuilder.java:47)
at
org.apache.maven.project.DefaultMavenProjectBuilder.loadProjectExternalProfiles(DefaultMavenProjectBuilder.java:1013)
... 18 more
Has any one tried setting up dependencies in Profiles? The profiles.xml
that I am using looks as follows:
tc-int
target
tc-int
org.codehaus.cargo
cargo-core-container-tomcat
..
Am I missing something here? I am referring to the POM descriptor online
to create profiles. Much appreciate pointers and thanks in advance for
any! Cheers, Rahul
-
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]
[m2] Unable setup under (XmlPullParserException: Unrecognised tag)
Hi , I am trying to introduce selective dependencies based on profile activation for a project, but i am encountering an exception (stacktrace below) Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'dependencies' (position: START_TAG seen ...\r\n ... @12:19) at org.apache.maven.profiles.io.xpp3.ProfilesXpp3Reader.parseProfile(ProfilesXpp3Reader.java:577) at org.apache.maven.profiles.io.xpp3.ProfilesXpp3Reader.parseProfilesRoot(ProfilesXpp3Reader.java:617) at org.apache.maven.profiles.io.xpp3.ProfilesXpp3Reader.read(ProfilesXpp3Reader.java:1126) at org.apache.maven.profiles.DefaultMavenProfilesBuilder.buildProfiles(DefaultMavenProfilesBuilder.java:47) at org.apache.maven.project.DefaultMavenProjectBuilder.loadProjectExternalProfiles(DefaultMavenProjectBuilder.java:1013) ... 18 more Has any one tried setting up dependencies in Profiles? The profiles.xml that I am using looks as follows: tc-int target tc-int org.codehaus.cargo cargo-core-container-tomcat .. Am I missing something here? I am referring to the POM descriptor online to create profiles. Much appreciate pointers and thanks in advance for any! Cheers, Rahul
Re: [jira] Moved: (ARCHETYPE-16) archetype-plugin copies sub-packaged source template files into wrong location
Hi, I submitted a patch for this one. Can we close this if it looks good? Cheers Rahul - Original Message - From: "John Casey (JIRA)" <[EMAIL PROTECTED]> To: Sent: Thursday, November 24, 2005 4:49 PM Subject: [jira] Moved: (ARCHETYPE-16) archetype-plugin copies sub-packaged source template files into wrong location [ http://jira.codehaus.org/browse/ARCHETYPE-16?page=all ] John Casey moved MNG-1480 to ARCHETYPE-16: -- Version: (was: 2.0) Complexity: (was: Novice) Key: ARCHETYPE-16 (was: MNG-1480) Project: Maven Archetype (was: Maven 2) archetype-plugin copies sub-packaged source template files into wrong location -- Key: ARCHETYPE-16 URL: http://jira.codehaus.org/browse/ARCHETYPE-16 Project: Maven Archetype Type: Bug Environment: WindowsXP, Sun JDK1.4.2_08, Maven2.0 Reporter: YOKOTA Takehiko Attachments: MNG-1480.diff, Sample-archetype.zip When generating project skelton using archetype-plugin and a custom archetype which has sub-packaged source template files, the plugin copies the source template files into wrong location. For example, let a custom archetype have the following source template files: archetype-resources/src/main/java/App.java archetype-resources/src/main/java/impl/AppImpl.java I expect the source files copied as the following: PROJECTTOP/src/main/java/PACKAGE/App.java PROJECTTOP/src/main/java/PACKAGE/impl/AppImpl.java But the actual result is like the following: PROJECTTOP/src/main/java/PACKAGE/App.java PROJECTTOP/src/main/java/impl/PACKAGE/AppImpl.java AFAIK, Maven1.x's genapp plugin behaves like I expect. Can you fix the behavior If possible? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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]
[m2] Archetype-core: invalid POM
Hi, for the following dependencies are missing in archetype-core POM. I ran "mvn eclipse:eclipse" and got the following error message: Project ID: org.apache.maven:maven-archetype-core POM Location: D:\oss\maven\archetype\maven-archetype-core\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.codehaus.plexus:plexus-utils [1] 'dependencies.dependency.version' is missing for org.codehaus.plexus:plexus-container-default Reason: Failed to validate POM Cheers, Rahul
Re: Continuum Build: Integration Test failures
and here's the log for the second failure... cheers, Rahul - Original Message - From: "Emmanuel Venisse" <[EMAIL PROTECTED]> To: Sent: Monday, September 19, 2005 1:30 AM Subject: Re: Continuum Build: Integration Test failures The problem is due to a missing pom in local repo : [WARNING] * Using defaults for missing POM org.apache.maven.plugins:maven-clean-plugin:pom:2.0-beta-2-SNAPSHOT * Emmanuel Emmanuel Venisse wrote: I see failures in the continuous integration environment however - there may be something else wrong. I will have a look tomorrow. yes, it's a strange failure appeared after the clean repo and full checkout process. I fixed all test yesterday. We have perhaps a bad jar downloaded in the repo of ci platform, because I tryied to build all with a clean repo like it's done on the ci platform and all build fine here. Will check after a new full clean/checkout process. Emmanuel --- Battery: org.apache.maven.continuum.it.ShellIntegrationTest --- testBasic(org.apache.maven.continuum.it.ShellIntegrationTest) [ stdout ] --- [WARNING] The specified JAR repository doesn't exist or is not a directory: 'C:\continuum\continuum-core-it\target\level1\level2\plexus-home\lib'. 2005-08-25 08:24:31,796 [main] DEBUG PlexusContainer- Found 3 components to load on start 2005-08-25 08:24:31,796 [main] INFO PlexusContainer- Loading on start [role]: [org.apache.maven.continuum.Continuum] 2005-08-25 08:24:31,796 [main] INFO JdoFactory - Initializing JDO. 2005-08-25 08:24:31,796 [main] INFO JDO- PersistenceManagerFactory - Vendor: JPOX Version: 1.1.0-beta-4-SNAPSHOT 2005-08-25 08:24:31,796 [main] INFO JDO- PersistenceManagerFactory initialised for datastore URL=jdbc:derby:C:\continuum\continuum-core-it\target\level1\level2\plexus-home/database;create=true driver=org.apache.derby.jdbc.EmbeddedDriver userName=sa 2005-08-25 08:24:31,796 [main] INFO RAMJobStore- RAMJobStore initialized. 2005-08-25 08:24:31,796 [main] INFO StdSchedulerFactory- Quartz scheduler 'scheduler1' initialized from an externally provided properties instance. 2005-08-25 08:24:31,796 [main] INFO StdSchedulerFactory- Quartz scheduler version: 1.4.5 2005-08-25 08:24:31,796 [main] INFO QuartzScheduler- Scheduler scheduler1_$_NON_CLUSTERED started. 2005-08-25 08:24:31,796 [main] INFO Continuum - Initializing Continuum. 2005-08-25 08:24:31,796 [main] INFO Continuum - Showing all projects: 2005-08-25 08:24:31,812 [main] INFO RDBMS - RDBMS Adapter initialised : CloudscapeAdapter : Apache Derby version=10.0.2.1, major=10, minor=0, revision=2 Identifier Names : UPPERCASE Driver name=Apache Derby Embedded JDBC Driver, version=10.0.2.1, major=10, minor=0 Identifier Max Lengths : Table=128 Column=30 Constraint=18 Index=18 Delimeters=" Identifier Support in DDL : catalog=false schema=true 2005-08-25 08:24:31,812 [main] INFO SCHEMA - Initialising Catalog "", Schema "SA" using "SchemaTable" auto-start option 2005-08-25 08:24:31,843 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.ProjectDependency since it was managed previously 2005-08-25 08:24:31,843 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.Profile since it was managed previously 2005-08-25 08:24:31,843 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.scm.ScmResult since it was managed previously 2005-08-25 08:24:31,843 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.ProjectDeveloper since it was managed previously 2005-08-25 08:24:31,843 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.ProjectNotifier since it was managed previously 2005-08-25 08:24:31,843 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.BuildResult since it was managed previously 2005-08-25 08:24:31,859 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.system.Installation since it was managed previously 2005-08-25 08:24:31,859 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.scm.ChangeSet since it was managed previously 2005-08-25 08:24:31,859 [main] INFO JDO- Managing Persistence
Re: Continuum Build: Integration Test failures
ok, I am still getting integration test failures. I cleaned my local repo recently while building m2 snapshot and removed the plugin-registry.xml as suggested. Please find attached the updated test reports (i am attaching these in 2 email as mail server rejects messages over a certain size). Cheers, Rahul - Original Message - From: "Emmanuel Venisse" <[EMAIL PROTECTED]> To: Sent: Monday, September 19, 2005 1:30 AM Subject: Re: Continuum Build: Integration Test failures The problem is due to a missing pom in local repo : [WARNING] * Using defaults for missing POM org.apache.maven.plugins:maven-clean-plugin:pom:2.0-beta-2-SNAPSHOT * Emmanuel Emmanuel Venisse wrote: I see failures in the continuous integration environment however - there may be something else wrong. I will have a look tomorrow. yes, it's a strange failure appeared after the clean repo and full checkout process. I fixed all test yesterday. We have perhaps a bad jar downloaded in the repo of ci platform, because I tryied to build all with a clean repo like it's done on the ci platform and all build fine here. Will check after a new full clean/checkout process. Emmanuel --- Battery: org.apache.maven.continuum.it.MavenOneIntegrationTest --- testBasic(org.apache.maven.continuum.it.MavenOneIntegrationTest) [ stdout ] --- [WARNING] The specified JAR repository doesn't exist or is not a directory: 'C:\continuum\continuum-core-it\target\level1\level2\plexus-home\lib'. 2005-08-25 08:22:00,031 [main] DEBUG PlexusContainer- Found 3 components to load on start 2005-08-25 08:22:00,031 [main] INFO PlexusContainer- Loading on start [role]: [org.apache.maven.continuum.Continuum] 2005-08-25 08:22:00,031 [main] INFO JdoFactory - Initializing JDO. 2005-08-25 08:22:00,031 [main] INFO JDO- PersistenceManagerFactory - Vendor: JPOX Version: 1.1.0-beta-4-SNAPSHOT 2005-08-25 08:22:00,031 [main] INFO JDO- PersistenceManagerFactory initialised for datastore URL=jdbc:derby:C:\continuum\continuum-core-it\target\level1\level2\plexus-home/database;create=true driver=org.apache.derby.jdbc.EmbeddedDriver userName=sa 2005-08-25 08:22:00,046 [main] INFO RAMJobStore- RAMJobStore initialized. 2005-08-25 08:22:00,046 [main] INFO StdSchedulerFactory- Quartz scheduler 'scheduler1' initialized from an externally provided properties instance. 2005-08-25 08:22:00,046 [main] INFO StdSchedulerFactory- Quartz scheduler version: 1.4.5 2005-08-25 08:22:00,046 [main] INFO QuartzScheduler- Scheduler scheduler1_$_NON_CLUSTERED started. 2005-08-25 08:22:00,046 [main] INFO Continuum - Initializing Continuum. 2005-08-25 08:22:00,046 [main] INFO Continuum - Showing all projects: 2005-08-25 08:22:00,062 [main] INFO RDBMS - RDBMS Adapter initialised : CloudscapeAdapter : Apache Derby version=10.0.2.1, major=10, minor=0, revision=2 Identifier Names : UPPERCASE Driver name=Apache Derby Embedded JDBC Driver, version=10.0.2.1, major=10, minor=0 Identifier Max Lengths : Table=128 Column=30 Constraint=18 Index=18 Delimeters=" Identifier Support in DDL : catalog=false schema=true 2005-08-25 08:22:00,062 [main] INFO SCHEMA - Initialising Catalog "", Schema "SA" using "SchemaTable" auto-start option 2005-08-25 08:22:00,140 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.Profile since it was managed previously 2005-08-25 08:22:00,140 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.ProjectGroup since it was managed previously 2005-08-25 08:22:00,140 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.ProjectDeveloper since it was managed previously 2005-08-25 08:22:00,140 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.ProjectNotifier since it was managed previously 2005-08-25 08:22:00,140 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.BuildDefinition since it was managed previously 2005-08-25 08:22:00,140 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.project.ProjectDependency since it was managed previously 2005-08-25 08:22:00,140 [main] INFO JDO- Managing Persistence of org.apache.maven.continuum.model.scm.ChangeSet since it was managed previously
Re: [vote] New Web Site CSS
+1 +1 ;-) dat iz neat might I say ! Cheers, Rahul Brett Porter wrote: Hi, Previously we polled for responses on an improved CSS and the opinions were that "31" was the best by far. We've had this turned into CSS which is applied to 2 pages that cover all styles here: http://people.apache.org/~brett/web-dev/ http://people.apache.org/~brett/web-dev/download.html [ ] +1 - Go ahead with it as is [ ] +0 - Go ahead with it, but I have some feedback that I'd like incorporated/discussed [ ] -0 - I have feedback I think must be addressed before we do this, but in general agree with the redesign [ ] -1 - I'm opposed to this design/any redesign This vote will run until the end of next Monday. (I will be running this by the Apache PRC as well) Cheers, Brett - 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] Release Maven 2.0 Beta 1
+1 Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, September 13, 2005 1:52 PM Subject: [vote] Release Maven 2.0 Beta 1 Hi, I'd like to release the (overdue) Maven 2.0 Beta 1, SCM and the plugins at Apache according to our roadmap. Plan here: http://docs.codehaus.org/display/MAVEN/Maven+2.0+beta+1+Release+Plan I will continue to update it with dependencies that are ready and any adjustments - please watch the page if you are interested. The beta release will mark a point of prioritising backwards compatibility and minimising new features to those already in JIRA for beta-2 and only those that won't change the way things currently work. 72 hours to vote! +1 from me Cheers, Brett - 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: SVN Build Error
I have been following similar thread(s) for a few days now - m2 build is broken. I am still getting lot of exceptions when I try to build SVN snapshots and I blew up my local repository before I did the last couple of builds, so not sure what's going wrong there. I am wondering - did your local build succeed? Cheers, Rahul - Original Message - From: "Trygve Laugstøl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Friday, September 02, 2005 11:23 PM Subject: Re: SVN Build Error - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (MNG-490) Creating an archetype with a different folder structure for java and test sources still results in default (src/main/java) folder being generated.
Hi, Wondering if this can be closed? I had submitted a patch that fixed this. Cheers, Rahul - Original Message - From: "Brett Porter (JIRA)" <[EMAIL PROTECTED]> To: Sent: Friday, August 26, 2005 3:24 PM Subject: [jira] Updated: (MNG-490) Creating an archetype with a different folder structure for java and test sources still results in default (src/main/java) folder being generated. [ http://jira.codehaus.org/browse/MNG-490?page=all ] Brett Porter updated MNG-490: - Fix Version: (was: 2.0-beta-1) 2.0-beta-2 Creating an archetype with a different folder structure for java and test sources still results in default (src/main/java) folder being generated. -- Key: MNG-490 URL: http://jira.codehaus.org/browse/MNG-490 Project: Maven 2 Type: Bug Environment: Windows XP, JDK 1.5.0, Maven2 SVN Reporter: Rahul Thakur Fix For: 2.0-beta-2 Attachments: DefaultArchetype.diff Creating an archetype with a different folder structure for java and test sources still results in default (src/main/java) folder being generated, even though these are being created empty. I created an archetype and need to follow a set folder structure (all java sources to sit under folder "src" and tests under "test" folder respectively) Also the Archetype plugin makes an assumption that the archetype resources will always reside under "archetype-resources/". User should be able to override this and specify a custom name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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: [continuum build - SUCCESS - update] Tue Aug 23 22:30:00 GMT 2005
Hi, What platform are Continuum builds succeeding on? I am using XP and update and build M2 prior to updating and building Continuum, but never get a successful build :-( Anyone building on XP ? or is it known that build still has errors on XP. Cheers, Rahul - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Wednesday, August 24, 2005 10:37 AM Subject: [continuum build - SUCCESS - update] Tue Aug 23 22:30:00 GMT 2005 Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20050823.223000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050823.223000.txt
Re: Automate testing
Has anyone checked out Jameleon for integration testing? http://jameleon.sourceforge.net/ Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, August 23, 2005 10:26 PM Subject: Re: Automate testing Steve Loughran wrote: I think httpunit has a better reputation in the past for quality/features; it even handles things like javascript. Yes - I always read them interchangably unfortunately, but I definitely prefer httpunit. - Brett - 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: [proposal] plugin oversight
+1 I agree with the "plugin care" assessment idea. Reckon that quarterly summary by plugin maintainer should keep things tight (hopefully!) Happy to adopt a "lesser plugin of Maven" ;-). Cheers, Rahul - Original Message - From: "Vincent Massol" <[EMAIL PROTECTED]> To: "'Maven Developers List'" Sent: Tuesday, August 16, 2005 9:11 AM Subject: RE: [proposal] plugin oversight -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: lundi 15 août 2005 23:06 To: Maven Developers List Subject: Re: [proposal] plugin oversight +1 I think that this is key. It is also a good way to distribute the work, and incentivise people... As long as some people don't end up with the garbage can! I think it's better to say "these plugins need adoption" then just to assign them all to one person. Yes, that's true. However the real issue is commitment over time. When we assigned the m1 plugins to people everything was working fine initially. It's just that over time your itches change and you stop supporting some plugins. We've not been careful with this. We should have had regular "plugin care" assessments. I'm +1 too with all that's below. -Vincent Eric On Aug 14, 2005, at 4:18 PM, Brett Porter wrote: > Ah, unloved plugins. We've known for a while that this is a problem in > Maven. Sometimes they remain stable, sometimes not but either way > nobody > is looking at them. I just got prodded to review the ejb plugin (which > I've never worked on) and saw that of the 10 outstanding issues 6 were > dupes or won't fix, 2 had apparently working patches and the other 2 > were trivial. Vincent is looking at applying, testing and releasing > this > now. > > A while back we assigned plugin maintainers to all the plugins (and I > got lumped with the ones nobody wanted). I did a particularly poor job > of looking after my plugins that I no longer use, let alone those I > never did. All plugins should be like clover, getting buglist > attention > and releases when appropriate. > > I'd like to make sure we don't repeat the mistakes with Maven2, so > here > is what I'm proposing: > > - We get volunteers for people to be plugin maintainers. This just > means > managing the buglist and applying patches, not necessarily having > to fix > issues (though it would be helpful!) They should also watch out for > highly voted for or particularly often duplicated issues to get > them fixed. > - In the month leading up to Maven's report to the board (every 3 > months), each plugin maintainer should ensure the buglist is up to > date > and post a summary to the dev list. This really doesn't take more than > an hour every 3 months, maybe less if you are already on top of it - > you'd just be pasting the little component window out of JIRA for > each, > which you can have set up on a dashboard. > - If ever a maintainer wants to step down, they can, and we'll > distribute the plugins among the others. > - We do this for Maven2 plugins now, and keep m1 as is until they are > built on top of the m2 plugins > > I'm BCC'ing the mojo community as I'd like to see a similar practice > there. Please reply to dev@maven.apache.org only. > > What do folks think? Is it too heavy handed, or just enough to > ensure it > gets done? Is quarterly enough? > > I'm also open to suggestions on how to manage JIRA. I think the > project-per-plugin approach is pretty good, once past the hurdle of > setting it up. I wouldn't want to recreate for the Maven2 plugins > so my > hope is that come the final release, we can have m1 using the m2 > plugin > where possible, or otherwise dev on the m1 plugin ceases (we get > all the > bugs fixed and closed, and leave it as is). > > - Brett > > - > 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] - 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: Continuum White Site
Hi Brett, Some suggestions on the HTML site: 1) User Administration Could we be able to create: - Groups - Users (Administrator/superuser always exists) - assign users to groups - set up group policies pertaining to project builds (RO/X access) - assign groups to projects (or vice versa) - assign a group manager, who is one of the group users and is able to add new users to the group. Some notes on how this translates to a practical use case: - 'Administrator' for Continuum build system can create other groups and users. - Administrator can associate projects to groups. - Clients/organisations are the groups that an Administrator can set up and set one of the users as the 'Manager'. - Respective group managers can themselves manage who they want to add to the group from with the organisation. - Administrator can set up Group policies - Read only / Execute access to group members. Ideal if a company wants its clients to keep track of project builds on a regular basis. 2) I like the way the 'generated artifacts' are hyperlinked on the build details page - is it possible not to have the Reports inlined on the same page but on different page (JUnit, site reports) 3) Build History: Is there a way to specify a threshold number of build details to keep in history and let continuum delete/archive older ones automatically apart from being able to delete manually. ohh...btw, Continuum logo is neat :-) ! Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: Sent: Sunday, August 07, 2005 8:02 PM Subject: Continuum White Site Hi, I have put this up here: http://people.apache.org/~brett/white-site/ This is how I see continuum 1.0 looking. There are a few notes still to be reconciled, and I haven't added the project group (should basically be like the project page itself) or general configuration page (not much to this I don't think). Can I get some feedback on things that are good/bad. Hopefully we can work towards a version we agree on, and that will set the mark for what Continuum 1.0 should look like. Note that this is all just rough HTML - so comment on the content, not the presentation :) Thanks, Brett
Re: Maven2 and JMX?
I have created this: http://jira.codehaus.org/browse/MNG-647 I think this would be a nice feature, and definately a cool one to have in Continuum as well. Unfortunately, I still haven't gotten my hands on a sane snapshot build on win XP for continuum :(((, so not sure if support for JMX is already there. Cheers, Rahul - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, July 26, 2005 2:03 PM Subject: Re: Maven2 and JMX? Not presently. We have some events during the code that could potentially have a JMX listener. Feel free to file a new feature request in JIRA, however without a number of votes or a patch submission I'm not sure if there'd be time to implement this in the near future. - Brett Loïc Lefèvre wrote: Hello, I was asking myself: "Will I be able to monitor maven 2 through JMX?" For example to trace its execution during a long build, a cache regeneration... About continuum, do you know if it is monitorable also? Thanks for your answers, Loïc - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] latest Snapshost build broken
Hi, On Windows XP I am getting lot of build errors (too many to reproduce) while building latest SVN snapshot. I tried building on Linux as well and I got a build failure with the error below. Any ideas? Cheers, Rahul [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error configuring plugin for execution of 'plugin:descriptor'. [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for execution of 'plugin:descriptor'. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:335) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:150) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:136) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:109) at org.apache.maven.DefaultMaven.processProject(DefaultMaven.java:283) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:192) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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:303) at org.codehaus.classworlds.Launcher.launch(Launcher.java:243) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:416) at org.codehaus.classworlds.Launcher.main(Launcher.java:363) Caused by: org.apache.maven.plugin.PluginConfigurationException: Cannot resolve plugin dependencies at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:559) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:459) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:330) ... 15 more Caused by: org.apache.maven.artifact.resolver.TransitiveArtifactResolutionException: Unable to read the metadata file marmalade:marmalade-compat-ant:1.0-alpha-3:jar from the specified remote repositories: http://repo1.maven.org/maven2, http://repo1.maven.org/maven2/plugins Path to dependency: 1) org.apache.maven.plugins:maven-plugin-plugin:maven-plugin:2.0-beta-1-SNAPSHOT 2) org.apache.maven:maven-plugin-tools-marmalade:jar:2.0-beta-1-SNAPSHOT 3) org.apache.maven:maven-script-marmalade:jar:2.0-beta-1-SNAPSHOT 4) plexus:plexus-marmalade-factory:jar:1.0-alpha-5 at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:201) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:204) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:204) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:204) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:171) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:159) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:132) at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:524) ... 17 more Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:80) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186) ... 25 more Caused by: org.apache.maven.project.ProjectBuildingException: Failed to parse model from file '/home/www/sites/.m2/repository/marmalade/marmalade-parent/1.0-alpha-3/marmalade-parent-1.0-alpha-3.pom'. Error: 'Unrecognised tag: 'repository' (position: START_TAG seen ...\n ... @17:15) ' at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java
snapshot build failure
Hi, I am attempting to build Continuum from a latest svn snapshot, but the build fails. Pls find attached the surefire test report for the failure. Cheers, Rahul --- Battery: org.apache.maven.continuum.store.JdoContinuumStoreTest --- testUpdateMavenTwoProject(org.apache.maven.continuum.store.JdoContinuumStoreTest) testAddProject(org.apache.maven.continuum.store.JdoContinuumStoreTest) testGetNonExistingProject(org.apache.maven.continuum.store.JdoContinuumStoreTest) testProjectCRUD(org.apache.maven.continuum.store.JdoContinuumStoreTest) testGetAllProjects(org.apache.maven.continuum.store.JdoContinuumStoreTest) testRemoveProject(org.apache.maven.continuum.store.JdoContinuumStoreTest) testGetLatestBuildForProject(org.apache.maven.continuum.store.JdoContinuumStoreTest) testBuild(org.apache.maven.continuum.store.JdoContinuumStoreTest) testTheAssociationBetweenTheProjectAndItsBuilds(org.apache.maven.continuum.store.JdoContinuumStoreTest) testGetLatestBuild(org.apache.maven.continuum.store.JdoContinuumStoreTest) [ stdout ] --- [INFO] Initializing JDO. [ stderr ] --- [ stacktrace ] --- junit.framework.ComparisonFailure: expected:<...5> but was:<...4> at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.maven.continuum.store.AbstractContinuumStoreTest.testGetLatestBuild(AbstractContinuumStoreTest.java:601) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) 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.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:230) at org.codehaus.surefire.battery.JUnitBattery.execute(JUnitBattery.java:204) at org.codehaus.surefire.Surefire.executeBattery(Surefire.java:187) at org.codehaus.surefire.Surefire.run(Surefire.java:136) at org.codehaus.surefire.Surefire.run(Surefire.java:60) 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.surefire.SurefireBooter.run(SurefireBooter.java:83) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:237) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:266) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:150) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:136) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:109) at org.apache.maven.DefaultMaven.processProject(DefaultMaven.java:261) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:180) at org.apache.maven.cli.MavenCli.main(MavenCli.java:279) 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:303) at org.codehaus.classworlds.Launcher.launch(Launc
