Re: Listeners for build events
Some questions: - Should the continuous integration tool not take the responsibility for performing the labelling, since it checked out the code, reports and notifies interested parties on success or failure of the compilation and tests against that code ? - In my mind the fact that I have built and run my tests successfully does not necessarily equate to me making a release. Any thoughts ? - Lastly, how can I automate the act of labelling if this is not part of the continuous build process? Ahmed http://www.nabble.com/forum/ViewPost.jtp?post=2736062framed=y -- View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5271292 Sent from the Continuum - Dev forum at Nabble.com.
Re: Listeners for build events
On 7/11/06, Ahmed Omarjee [EMAIL PROTECTED] wrote: Some questions: - Should the continuous integration tool not take the responsibility for performing the labelling, since it checked out the code, reports and notifies interested parties on success or failure of the compilation and tests against that code ? Not neccessary, IMO since it already has some other mean to do it - In my mind the fact that I have built and run my tests successfully does not necessarily equate to me making a release. Any thoughts ? behind the scene, release plugin, in general, label the source, validate the build. It can be reused for other purposes where label is required for each build. - Lastly, how can I automate the act of labelling if this is not part of the continuous build process? Create continuum shell project and configure this command to run mvn scm:tag -Dtag=sometag scm:bootstrap -Dgoals=install never try it thou You may need to write a custom plugin to automate the tagname generation. Ahmed http://www.nabble.com/forum/ViewPost.jtp?post=2736062framed=y -- View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5271292 Sent from the Continuum - Dev forum at Nabble.com.
Re: Listeners for build events
Ahmed Omarjee wrote: Hi, I have a requirement to perform other operations before checkout of a project, as well as after a successful or failed build. The context of why I need this is as follows; I am using PVCS at a corporate client, and have already begun writing a maven-scm-plugin for PVCS (I can't sit around waiting for Serena to contribute their plugin). Using agile methodology, I would normally perform a checkout, start the build process (if changes are detected), and on successful build apply a label to the source repository. But alas, PVCS does not have metadata locally thus a label can not be applied to the version that was originally checked out, which may result in inconsistencies. A solution we have come it with (read hack), is : - label the repository before checkout with a tag (eg. Building #123 - 01/07/2006 9:00) - checkout using that label - perform the build - and on success rename the label (which strangely PVCS supports) (eg. Build #123 - 01/07/2006 9:00) - and on failure the label is removed (which strangely PVCS also supports) Sounds good as long as all of the steps are optional and configurable. If only we could have listeners to some important events such as build start, on success, on failure, build finished, etc. this could be pluggable behaviour. Correct, this will happen before a build is even started. I don't mind having a look at this and take up the challenge of maybe implementing it, but I need some guidance and advice on the appropriateness of this as a solution. That would be great if you would like to take a look just beware that it won't be a trivial task and will take a while. This is something that has been requested several times and is something I think would be nice to add. To get started check out the Continuum code from trunk [1] and try to build it with ./build.sh. You might have to download some dependencies from Sun or likewise places but Maven should inform you. [1]: https://svn.apache.org/repos/asf/maven/continuum/trunk/ -- Trygve
Re: Continuum Security design
I've updated the wiki with my latest thoughts. I suggest this reading http://acegisecurity.org/docbook/acegi.html#domain-acls which explains how to add instance based security with ACLs. It's a good option and allows fine grained permissions for user, project and type of operation. On 7/11/06, Jesse McConnell [EMAIL PROTECTED] wrote: well, here are my thoughts on the matter summed up after some subsequent discussion on this between joakim, carlos and myself: If continuum is to scale up to multiple projects, say continuum building in the same instance along side maven and the maven repository manager then we are going to need a simple fine grained security mechanism that isn't clunky to use. the perhaps ill chosen 'unholy marriage of security strategies' phrase above basically refers to the current implementation of groups and roles. We have role based security for all of the different types functionalities, and then it has been kicked around to have group based access to different projects...and these groups are made up of sets of roles. Perhaps there was some misunderstanding on the specifics but at least my thoughts on the matter are that we are best served with a straight forward role based security model where access to special views and the ability to perform certain actions are governed by individual roles on a per project basis. ie, if there is a role for 'FORCE_BUILDS' then there ought to be one of these roles for each project in continuum, in the above example we might have 'CONTINUUM_FORCE_BUILD', MAVEN_FORCE_BUILD' and 'MRM_FORCE_BUILD'. Each user would have the ability to be assigned these roles and would then have that access for each of the particular projects. If we have this simple role based approach then all of the security checks, which as joakim mentioned are the vast majority of usage for the security', are very simple role checks. It becomes then a matter of figuring out the best way to manage these roles and there are lots of different examples of that out in the wild, be they the ability to make profiles of roles that can be applied to users, to long lists of checkboxes (not so fun). Joakim had mentioned that the roles would likely be dynamic based on the projects as they were added in and that we could put in some simple dynamic filters or profiles that would initialize the project and a user with the necessary settings and then further access could be pushed out from there.. I talked to trygve about this a bit and he mentioned that jason has put some rbac (http://en.wikipedia.org/wiki/RBAC) code into plexus sometime ago...and that is ultimately where any of this needs to end up so that other projects can have immediate access to the different security mechanisms. carlos, joakim...I miss anything in this? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Continuum Security design
Carlos Sanchez wrote: http://docs.codehaus.org/display/CONTINUUM/Security Please take a look and provide feedback on the semantics of what to secure and to what level. Some discussion with Jesse McConnell about the security ... [11:01:38] jerdfelt jmcconnell: do you see the comment in it's fully rendered splendor? [11:02:21] jmcconnell jerdfelt: yep, much better :) [11:03:28] jmcconnell jerdfelt: and I agree totally, that my thought as well [11:04:37] jmcconnell only question is if the roles should be provided globally or on a per project basis [11:04:57] jerdfelt per project. [11:05:07] jerdfelt but when you add the 'group' wrinkle, things get odd. [11:05:12] jmcconnell ya [11:05:53] jmcconnell when you kick this up a lvl it gets messy [11:06:22] jmcconnell kinda like groups should be a part of projects [11:07:16] jmcconnell and you can maintain one user having access to multiple projects and being a member of different groups in different projects [11:08:28] jmcconnell suppose the thing to do is respond to that mail [11:08:31] jerdfelt jmcconnell: yes, the ability to belong to multiple groups is needed. [11:08:54] jmcconnell multiple groups in a projects or multiple projects/one group each [11:09:21] jerdfelt ah, the many to many, many to one, one to many question. [11:09:35] jerdfelt Each group needs to support multiple projects. [11:09:43] jmcconnell if we get to that point then we ought to toss the group concept and go straight to project roles [11:09:57] jmcconnell with profiles that can be applied topeople to easily manage the roles they have [11:10:09] jerdfelt ah. profiles. good idea. [11:10:26] jerdfelt cept, we could call them groups to the users. ;-) [11:10:29] jmcconnell the groups concept doesn't scale with this [11:10:55] jmcconnell right, but the group membership does nothing except toggle the appropriate roles [11:11:24] jerdfelt question is, should the profile be enforced? [11:11:48] jmcconnell and when rendering we check if their role config matchs any known 'groups' and if not then render as 'custom' [11:11:49] jerdfelt or is it just the ability to set a large set of permissions on a one time basis. [11:12:12] jmcconnell the latter [11:12:24] jmcconnell makes it easier to setup a user's roles [11:12:26] jerdfelt we could create virtual users that are actually groups. map them to a user via a role. (ick) [11:13:35] jmcconnell well, if this is the way to go then its simply a matter of how best to manage all the possibloe rolls across all the projects...when it comes to a particular security check it is a simple role check and that is it [11:13:37] jerdfelt is there an upper limit on role names? [11:13:57] jerdfelt i want it to be a simple role check at the code level. [11:14:07] jmcconnell jerdfelt: exactly [11:14:20] jmcconnell manageing the users role is just a UI issue at that point [11:14:29] jmcconnell unless we have this group concept in place as well [11:14:36] jerdfelt wonder if I should just copy/paste this IRC discussion into the continuum-dev list. ;-) [11:14:55] jmcconnell which kinda seems like an unholy marriage of security strategies [11:15:00] jerdfelt I see the group concept as needed from a user point of view. [11:15:01] jmcconnell jerdfelt: yes, we should - Joakim Erdfelt
Re: svn commit: r420933 - in /maven/continuum/branches/continuum-acegi/continuum-webapp/src/main/resources: commons-logging.properties log4j.properties
*the onlooking crowd gasps* Trygve pulled out the veto! :) Regardless, I agree. I'm pretty sure Continuum already has a log4j configuration in it's application.xml that can include both these configurations. On 12/07/2006 5:04 AM, Trygve Laugstøl wrote: Trygve Laugstøl wrote: [EMAIL PROTECTED] wrote: Author: carlos Date: Tue Jul 11 10:29:53 2006 New Revision: 420933 URL: http://svn.apache.org/viewvc?rev=420933view=rev Log: Add logging config files -1 to the log4j configuration -1 might be a bit strong, I just meant to say that we configure logging through Plexus. -- Trygve -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/
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 dev@maven.apache.org 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: A plugins nature
Hi, Kenney, On 7/11/06, Kenney Westerhof [EMAIL PROTECTED] wrote: This is not a maven mojo problem but a plugin design problem. Most plugins, like the jar plugin and the surefire plugin, to name some, are rather empty. The jar plugin just extracts information from the MavenProject, giving it to maven-archiver (plexus-archiver under water), and later updates the MavenProject with the newly created archive. The same goes for the surefire plugin. I am sorry, but in the particular case of the jar plugin, I disagree. The jar plugin is setting the standards, in terms of configuration, in terms of defaults, and such things. It is hardly possible to reuse them. Take the following example: I want my project to create two jar files. One with Java 5 classes. The other created by retrotranslator with Java 1.4 classes. Obviously, I want both jar files to be identical, the exception being the modified classes. This cannot be done with the Maven archiver. Sorry for going into these details, which I would like to avoid. I just would like to make the point, that even what you consider as rather empty might be worth reusing. Jochen -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please review javadoc plugin documentation
Hi Everyone, I've made some changes in the javadoc plugin docs. Could someone please review it? :-) Thanks, Odea - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please review maven-idea-plugin documentation
I've just finished updating the documentation for the maven-idea-plugin. Your feedback is highly appreciated. Thanks. ^_^ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A plugins nature
Rinku wrote:
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.
This something that we always have been stressing. For the same reasons
it is important that plugins use as much of the expressions as possible
instead of just ${project} and pick out the pieces it needs.
--
Trygve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review javadoc plugin documentation
Maria Odea Ching wrote: Hi Everyone, I've made some changes in the javadoc plugin docs. Could someone please review it? :-) Can you publish the documentation somewhere and also inclue a small summary of what you've changed to make it easier to check it? You should have an Apache account and home directory you can use for deployment. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review javadoc plugin documentation
Okay, will do :) Thanks.. Trygve Laugstøl wrote: Maria Odea Ching wrote: Hi Everyone, I've made some changes in the javadoc plugin docs. Could someone please review it? :-) Can you publish the documentation somewhere and also inclue a small summary of what you've changed to make it easier to check it? You should have an Apache account and home directory you can use for deployment. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review javadoc plugin documentation
Maria Odea Ching wrote: Okay, will do :) Thanks.. Could you also fix your clock? It seems to be set for the wrong timezone, or something ... either way, it's about 15 hours fast. Richard -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Review of install plugin
Hi everyone, Just updated the docs of the install plugin. I hope you dont mind if you take a look and give me some feedback about it. Thanks Cheers, allan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: General issue with clover plugin requiring creative thinking...
I have found this aspect of clover a great frustration and would welcome any attempt to separate such 'instrument and compile' tasks from the main project build activities. John -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 11 July 2006 06:20 To: Maven Developers List Subject: Re: General issue with clover plugin requiring creative thinking... On 11/07/2006 3:14 PM, Vincent Massol wrote: One solution would be to create a profile for the main lifecycle and another one for the clover lifecycle but that's not very handy for end users I think. I'll try experimenting with this later on but I think it would only be a hack and not a proper solution. Is there anything better I could do? Not that I can think of that doesn't involve core changes (ie, 2.1). - 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: General issue with clover plugin requiring creative thinking...
If it's a matter of sharing information maybe the ability to store data in a sort of temporary HashMap sort of session? Ie clover could do something like: session.store(CLOVER_INSTRUMENTED_SOURCE_DIR, target/src/clover-generated); And the next guy that needs it could pick it up...Probably not easy to do though since it's likely that mvn will be invoked multiple times. On 7/11/06, John Allen [EMAIL PROTECTED] wrote: I have found this aspect of clover a great frustration and would welcome any attempt to separate such 'instrument and compile' tasks from the main project build activities. John -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 11 July 2006 06:20 To: Maven Developers List Subject: Re: General issue with clover plugin requiring creative thinking... On 11/07/2006 3:14 PM, Vincent Massol wrote: One solution would be to create a profile for the main lifecycle and another one for the clover lifecycle but that's not very handy for end users I think. I'll try experimenting with this later on but I think it would only be a hack and not a proper solution. Is there anything better I could do? Not that I can think of that doesn't involve core changes (ie, 2.1). - 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] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Review Javadoc Plugin Documentation
Hi Everyone, I've made some changes in the javadoc plugin. Could someone please review it? :) Thanks, Odea - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
examples filename standard?
src/site/apt/example/ like-this.apt likeThis.apt likethis.apt I know it's anal but can a benevolent dictator just declare one as the standard? I prefer to former but don't care one way or the other. javadoc and install currently have all three represented. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: examples filename standard?
First one (consistent with yours, and consistent with what's already in maven/site). /me dictates benevolently (if anyone feels strongly enough for another, we can take it to a vote :) - Brett On 12/07/2006 12:12 AM, Mike Perham wrote: src/site/apt/example/ like-this.apt likeThis.apt likethis.apt I know it's anal but can a benevolent dictator just declare one as the standard? I prefer to former but don't care one way or the other. javadoc and install currently have all three represented. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Review of install plugin
Done, with small changes. -Original Message- From: Allan Ramirez [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 11, 2006 10:31 PM To: Maven Developers List Subject: Review of install plugin Hi everyone, Just updated the docs of the install plugin. I hope you dont mind if you take a look and give me some feedback about it. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
(Fwd) Change config of plugin outside of pom.xml
Sorry for cross-posting this mail, I didn't get an answer on user mailing list.
Is it possible to
overvrite plugin configuration outside of the pom.xml? I have nested elements
in my plugin
configuration, so I can't use a simple property that can be replaced?
Regards, carsten
--- Forwarded message follows ---
Date sent: Mon, 10 Jul 2006 14:17:02 +0200
From: Karkola Carsten [EMAIL PROTECTED]
Subject:Change config of plugin outside of pom.xml
To: users@maven.apache.org
Send reply to: Maven Users List users@maven.apache.org
Priority: normal
[ Double-click this line for list subscription options ]
Hallo,
what is the best way to change a plugin config outside of the POM, so
developers can add some properties without the need to checkout/change
the pom of the project.
So I have a plugin with a config like
plugin
groupIdfoo/groupId
artifactIdmyplugin/artifactId
configuration
jvargs
jvarg-Xms512m/jvarg
/jvargs
/configuration
/plugin
and a developer likes to add an additional
jvarg-Xdebug/jvarg
Under
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
I found this sentence, but I don't understand it:
The properties section allows you to specify free-form key-value pairs which
will be included in the interpolation process for the POM. This allows you to
specify a plugin configuration in the form of ${profile.provided.path}.
Does it mean I can add some property to my settings.xml like
build.plugin.foo.configuration.jvargs.jvarg-Xdebug/... ?!
Regards, carsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End of forwarded message ---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Review Javadoc Plugin Documentation
Done. -Original Message- From: Maria Odea Ching [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 11, 2006 8:17 PM To: dev@maven.apache.org Subject: Review Javadoc Plugin Documentation Hi Everyone, I've made some changes in the javadoc plugin. Could someone please review it? :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Listeners for build events
On 7/11/06, Ahmed Omarjee [EMAIL PROTECTED] wrote: - IMHO, the act of checking code out, building and then labelling is not part of the typical developers build lifecycle (ie. on a single developers machine, he handles this kind of thing manually if needs be, by updating his codebase, labelling, and branching when required), this kind of automation is needed particularly when doing continuous integration. True, that is why I have suggested to hook up Continuum with maven-release-plugin to do the automation. - The release plugin could do the job but when does it run, where is it configured ? Create a continuum shell project and configure build definition as mvn release:release this mojo is not avaible yet see http://jira.codehaus.org/browse/MRELEASE-100 but I dont think it is hard to implement - If I call the scm:tag command as part of a shell script integration in continuum, surely its build cycle is independent of the original project and hence may be inconsistent. Somehow the entire build cycle for a given project should be a single unit of work, all the way from checkout, build, test, and then potentially apply a label. scm:tag does the label scm:bootstrap pulls the source just labeled how could it inconsitent? Ahmed -- View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5272261 Sent from the Continuum - Dev forum at Nabble.com.
Re: [discuss] Java 5
snip 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 /snip 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: [discuss] Java 5
Rinku wrote: snip 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 /snip Anyone subscribed to QDox udpates - any news on this? Cheers, Rahul No, not yet. I'm having trouble subscribing to the list. Both Codehaus [1] and my ISP are investigating why. [1] http://jira.codehaus.org/browse/HAUS-1257 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with the new plugin plugin: missing parameters from parent mojo
Hi I've found a problem using the new plugin plugin. The new look for the mojo documentation doesn't include everything that it used to. I'm documenting the jar plugin. This plugin has an AbstractJarMojo which the JarMojo extends. The abstract class has many parameters that don't get included in the new look page. Only parameters declared in JarMojo end up in the page jar-mojo.html. If I revert to using maven-plugin-plugin-2.1 the parameters show up again. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please review the documentation for the maven-jar-plugin
Hi all I have finished going over the documentation for the maven-jar-plugin. I hope you can spare a moment and read through it. This is what I have done: [MJAR-46] Document manifestFile element in configuration [MJAR-47] maven-jar-plugin documentation should point to additional documentation, such as manifest guide [MJAR-48] Review plugin documentation - Add FAQ - Add links to the Javadocs for MavenArchiveConfiguration - Restructured the documentation according to the new guidelines for plugins - Review all the parameters to ensure they have good docs - Use the new and improved plugin report A staged site is available for browsing here: http://people.apache.org/~dennisl/maven-jar-plugin/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with the new plugin plugin: missing parameters from parent mojo
Dennis Lundberg wrote: Hi I've found a problem using the new plugin plugin. The new look for the mojo documentation doesn't include everything that it used to. I'm documenting the jar plugin. This plugin has an AbstractJarMojo which the JarMojo extends. The abstract class has many parameters that don't get included in the new look page. Only parameters declared in JarMojo end up in the page jar-mojo.html. If I revert to using maven-plugin-plugin-2.1 the parameters show up again. Here are some examples. Old plugin plugin: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html New plugin plugin: http://people.apache.org/~dennisl/maven-jar-plugin/jar-mojo.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review the documentation for the maven-jar-plugin
On 7/12/06, Dennis Lundberg [EMAIL PROTECTED] wrote: - Add FAQ In the FAQ, could you link to documentation that tells you how to set parameters in the configuration section. At the moment you have to know you can specify tags that match the attributes of the class to set values. The main class and classpath are the most common ones, so including them as well would be nice configuration archive manifest mainClassfully.qualified.MainClass/mainClass addClasspathtrue/addClasspath /manifest /archive /configuration - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with the new plugin plugin: missing parameters from parent mojo
Thanks - is it definitely the inheritence? If so, that's a bug. There are two other factors: - a bug that meant a parameter without expression didn't appear (I committed Edwin's fix yesterday, but didn't deploy a snapshot) - readonly and components are now omitted by design Definitely needs to be looked in to. - Brett On 12/07/2006 9:45 AM, Dennis Lundberg wrote: Dennis Lundberg wrote: Hi I've found a problem using the new plugin plugin. The new look for the mojo documentation doesn't include everything that it used to. I'm documenting the jar plugin. This plugin has an AbstractJarMojo which the JarMojo extends. The abstract class has many parameters that don't get included in the new look page. Only parameters declared in JarMojo end up in the page jar-mojo.html. If I revert to using maven-plugin-plugin-2.1 the parameters show up again. Here are some examples. Old plugin plugin: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html New plugin plugin: http://people.apache.org/~dennisl/maven-jar-plugin/jar-mojo.html -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review the documentation for the maven-jar-plugin
I think I remember that we should be using Maven instead of Maven 2. Aside from that, everything's just great. ^_^ Dennis Lundberg wrote: Hi all I have finished going over the documentation for the maven-jar-plugin. I hope you can spare a moment and read through it. This is what I have done: [MJAR-46] Document manifestFile element in configuration [MJAR-47] maven-jar-plugin documentation should point to additional documentation, such as manifest guide [MJAR-48] Review plugin documentation - Add FAQ - Add links to the Javadocs for MavenArchiveConfiguration - Restructured the documentation according to the new guidelines for plugins - Review all the parameters to ensure they have good docs - Use the new and improved plugin report A staged site is available for browsing here: http://people.apache.org/~dennisl/maven-jar-plugin/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review maven-idea-plugin documentation
Btw, to those who want to check it out, a staging site is available at http://people.apache.org/~epunzalan/maven-idea-plugin/ Edwin Punzalan wrote: I've just finished updating the documentation for the maven-idea-plugin. Your feedback is highly appreciated. Thanks. ^_^ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review the documentation for the maven-jar-plugin
Also, can you please update this page: http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation Thanks. ^_^ Dennis Lundberg wrote: Hi all I have finished going over the documentation for the maven-jar-plugin. I hope you can spare a moment and read through it. This is what I have done: [MJAR-46] Document manifestFile element in configuration [MJAR-47] maven-jar-plugin documentation should point to additional documentation, such as manifest guide [MJAR-48] Review plugin documentation - Add FAQ - Add links to the Javadocs for MavenArchiveConfiguration - Restructured the documentation according to the new guidelines for plugins - Review all the parameters to ensure they have good docs - Use the new and improved plugin report A staged site is available for browsing here: http://people.apache.org/~dennisl/maven-jar-plugin/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
