RE: Maven Download Procedure
Hi, thanks for the feedback. I've adjusted the page a bit.For most of them I agree, but I think we should tell something about environment tooling. Maybe as some kind of wiki-text while explaining the features of Maven. Another approach is to ask yourself the following questions and give it a place on the page:What? (Maven)Why? (stable builds, the environment tooling suuport, etc.)When? (Now!)Who? (Maven Users, and indeed: Maven Plugin developers and Maven Core developers are not the first aim and need a separate page)Where? (?)How? (Download, unpack/install and run) -Robert Date: Thu, 21 Jul 2011 14:58:19 -0700 Subject: RE: Maven Download Procedure From: manf...@mosabuam.com To: dev@maven.apache.org Hi! I am not a web designer either but from a mere content point of view this page is already way too busy. The developer and plugin developer stuff can be removed or reduced to one link each. The environment tooling links are not necessary on the front page. The section Maven and Maven users should be one and a few of the topics can be brought into separate landing pages e.g. one for documentation, one for contributing and so on. It should be much cleaner and basically empty so it is not so overwhelming for beginners. In any case a good logo for Maven would be useful too. just my 2c manfred http://www.simpligility.com On Thu, July 21, 2011 1:34 pm, Robert Scholte wrote: First of all: I'm not a graphical designer or the king of HTML and CSS, but this is just a brainwave.It seems like we want a lot of links on the first page. The current page-setup isn't really link-friendly.It contains a lot of text, most of us haven't read it for ages, they just click directly to the required page.My idea is to use a portal view, where portlets can be grouped and each portlet contains it's own specific links.With some coloring I tried to bundle some portlets, like blue for the role of the visitor, green for the product Maven.The one-click download doesn't seem to be possible. The Apache Site always list the mirrors you can download from, never a direct reference. Anyhow, just shoot at http://people.apache.org/~rfscholte/maven-site/ (half of the links just refer to #)(I hope there's somebody who knows somebody who can make it look great ;) ) -Robert From: aherit...@gmail.com Date: Tue, 12 Jul 2011 09:23:17 +0200 Subject: Re: Maven Download Procedure To: dev@maven.apache.org +1 It was said several times and many people are agree to simplify / cleanup / improve our web site If someone is volunteer :-) On Tue, Jul 12, 2011 at 9:06 AM, Brett Porter br...@apache.org wrote: I think you'll find in the archives of this list plenty of agreement and thoughts about how to change / simplify. It just needs someone willing to start :) - Brett On 09/07/2011, at 8:24 PM, Robert Scholte wrote: I agree with Tim here. Compare the maven[1] and gradle[2] homepages. The gradle page is pretty clean (too clean?) and you know immediately where to download the bundle.The maven site has a huge amount of text, all links look the same so I can imagine that newbies get a bit lost, already on this page. That can't be right.I think it's more than adding a huge download button. IMHO the pages should reflect the role of the visitor (starter, user, developer) instead of summing up all the handy stuff, but that's a real challenge. -Robert [1] http://maven.apache.org[2] http://gradle.org From: vsive...@apache.org Date: Fri, 8 Jul 2011 23:11:20 -0400 Subject: Re: Maven Download Procedure To: dev@maven.apache.org Well, 3 clicks vs 1 click to get Maven vs gradle from the main page, not a big deal IMHO. Apache Ant gives it in 2 clicks by catching the right mirror. Apache Tomcat 2 clicks by catching the right mirror. Apache Directory gives it in 3 clicks. and so on So, I think we are not so bad. Vincent 2011/7/8 Tim O'Brien tobr...@discursive.com: I had to write this process down for the millionth time today. Here it is: the current procedure for downloading Maven (without using figures). 1. Go to http://maven.apache.org. 2. On the right-hand side of the page, you should see a section with the title Get Maven 3.0.3. 3. Click on the first link in this section, the link titled Maven 3.0.3 next to the folder icon. This will take you to a list of Maven distributions. 4. Click on one of the archive links (apache-maven-3.0.3-bin.tgz or apache-maven-3.0.3-bin.zip) in the Mirrors column of this table. 5. You should then see the Apache Download Mirrors page. 6. Click on one of the Mirror URLs and download Apache Maven. Can we figure out a way to make it this easy? 1. Go to http://maven.apache.org 2. Click on one of the Download buttons to
POM5 proposal
Since I can't edit the Wiki, I created: https://docs.google.com/document/d/1k3E4vx_4cKJ4zzksVM4oROX3Dffsh0Q4VOGVjd3oUto/edit?hl=en_US - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
one last decision/documentation point about m-site-p 3 with Maven 3 we had a discussion on IRC yesterday with Robert, Mark and Benjamin about wagon and its change in M3 [1]. It was about the way we promote configuring wagon protocols in plugins: - in m-deploy-p, we promote using extensions (and the plugin doesn't add any wagon provider other that what is available from Maven core) - in m-site-p 3, we actually added a lot of wagon providers as dependencies (ssh, ftp, webdav, scm:svn), thus they are automagically available for end user, but this disables extension mecanisms for every providers added: if you want to change a wagon provider version, for example, defining it in extension won't work for m-site-p So we have to do a choice between 2 options: 1. be consistent with other plugins, remove every wagon provider from m-site-p and promote/document configuration done by end-users (either as extension or dependency). This will be needed notably for scp (which works automagically in M2) and ftp or scm:svn (which were added in m-site-p 3.0-beta*): I suppose we need to create a dedicated example. 2. let the multiple wagon providers in m-site-p, which will work automagically for a lot of protocols, but downloads a lot of artifacts and disables extensions definition for these protocols: this needs at least documentation So what should we do: 1. pure, with good explanations to help users understand what to do 2. magic at the beginning, but downloads the internet and more complex later ? Please correct if I misunderstood something... Regards, Hervé [1] https://cwiki.apache.org/MAVEN/maven-3x-compatibility- notes.html#Maven3.xCompatibilityNotes-TransportProtocols%2528Wagons%2529 Le vendredi 22 juillet 2011, Dennis Lundberg a écrit : On 2011-07-22 00:48, Hervé BOUTEMY wrote: Maven Site Plugin 3.0 is now ready for release (with its documentation) for me If anybody still has something to change, please explain what so we can fix it and release ASAP Thanks for all your work Hervé! Now that we plan for 3.0 to be the main version of the plugin, there are a couple of things I'd like to do: 1. Remove any references to the 3.x Subversion branch in the docs. I'll do this. 2. Document the difference between Maven 2 and Maven 3 with regards to inheritance that was recently discovered, if it hasn't already been done. I'll check this. 3. Switch the URLs for the deployed sites. We currently have these redirects: RedirectMatch ^/plugins/maven-site-plugin-2.x/(.*)$ /plugins/maven-site-plugin/$1 RedirectMatch ^/plugins/maven-site-plugin-3.x/(.*)$ http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/ I'd like to change them to this: RedirectMatch ^/plugins/maven-site-plugin-2.x/(.*)$ /plugins/maven-site-plugin-2.3/$1 RedirectMatch ^/plugins/maven-site-plugin-3.x/(.*)$ http://maven.apache.org/plugins/maven-site-plugin/$1 This would also require changing the plugins/index page to point to /plugins/maven-site-plugin-2.x/ and /plugins/maven-site-plugin/ respectively for versions 2 and 3. 4. Change the deploy site URL in both POMs. 5. Move the current maven/plugins/trunk/maven-site-plugin/ to maven/plugins/branches/maven-site-plugin-2.x 6. Move maven/plugins/branches/maven-site-plugin-3.x to maven/plugins/trunk/maven-site-plugin/ I'll get on 1 and 2 right now. 3 I'd like to do after the release, once the deployed site is in place. 4 needs to be done before the release. 5 and 6 can be done either before or after the release, I'd prefer to do it before. Regards, Hervé Le samedi 2 juillet 2011, Dennis Lundberg a écrit : Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Sonar Drools Plugin version 0.1
Hi,
I would like to release the first version (0.1) of Drools Sonar Plugin.
This version requires sonar 2.2+
*5 issues has been solved.*
http://jira.codehaus.org/browse/SONARPLUGINS/fixforversion/17498
*Download *(snapshot)
http://snapshots.repository.codehaus.org/org/codehaus/sonar-plugins/sonar-drools-plugin/0.1-SNAPSHOT/sonar-drools-plugin-0.1-20110724.170524-1.jar
*Documentation *(draft)
http://docs.codehaus.org/display/SONAR/Drools+plugin
*Test*
It has been tested on Windows7 64bits with Sonar 2.9
Simple Test Case
- download Sonar 2.9 and unzip it ( http://www.sonarsource.org/downloads/ )
- put sonar-drools-plugin-0.1-20110724.170524-1.jar in
${SONAR_HOME}/extensions/plugins
- start sonar server
- download the simple project
http://svn.codehaus.org/sonar-plugins/trunk/drools/projects/simple/
- run mvn sonar:sonar in the simple project
*Vote open to everybody for 72 hours.*
[ ] +1
[ ] +0
[ ] -1
Jérémie.
RE: Is Maven Site Plugin 3.0-beta-4 ready for release?
I've already made a jira-issue for it, MSITE-598 [1]. I think we should stay consistent: specify wagons with extensions.We just need to document this very well, both on the site and the failure-message, including the required xml to add to the pom. -Robert [1] http://jira.codehaus.org/browse/MSITE-598 From: herve.bout...@free.fr To: dev@maven.apache.org Subject: Re: Is Maven Site Plugin 3.0-beta-4 ready for release? Date: Sun, 24 Jul 2011 21:56:22 +0200 one last decision/documentation point about m-site-p 3 with Maven 3 we had a discussion on IRC yesterday with Robert, Mark and Benjamin about wagon and its change in M3 [1]. It was about the way we promote configuring wagon protocols in plugins: - in m-deploy-p, we promote using extensions (and the plugin doesn't add any wagon provider other that what is available from Maven core) - in m-site-p 3, we actually added a lot of wagon providers as dependencies (ssh, ftp, webdav, scm:svn), thus they are automagically available for end user, but this disables extension mecanisms for every providers added: if you want to change a wagon provider version, for example, defining it in extension won't work for m-site-p So we have to do a choice between 2 options: 1. be consistent with other plugins, remove every wagon provider from m-site-p and promote/document configuration done by end-users (either as extension or dependency). This will be needed notably for scp (which works automagically in M2) and ftp or scm:svn (which were added in m-site-p 3.0-beta*): I suppose we need to create a dedicated example. 2. let the multiple wagon providers in m-site-p, which will work automagically for a lot of protocols, but downloads a lot of artifacts and disables extensions definition for these protocols: this needs at least documentation So what should we do: 1. pure, with good explanations to help users understand what to do 2. magic at the beginning, but downloads the internet and more complex later ? Please correct if I misunderstood something... Regards, Hervé [1] https://cwiki.apache.org/MAVEN/maven-3x-compatibility- notes.html#Maven3.xCompatibilityNotes-TransportProtocols%2528Wagons%2529 Le vendredi 22 juillet 2011, Dennis Lundberg a écrit : On 2011-07-22 00:48, Hervé BOUTEMY wrote: Maven Site Plugin 3.0 is now ready for release (with its documentation) for me If anybody still has something to change, please explain what so we can fix it and release ASAP Thanks for all your work Hervé! Now that we plan for 3.0 to be the main version of the plugin, there are a couple of things I'd like to do: 1. Remove any references to the 3.x Subversion branch in the docs. I'll do this. 2. Document the difference between Maven 2 and Maven 3 with regards to inheritance that was recently discovered, if it hasn't already been done. I'll check this. 3. Switch the URLs for the deployed sites. We currently have these redirects: RedirectMatch ^/plugins/maven-site-plugin-2.x/(.*)$ /plugins/maven-site-plugin/$1 RedirectMatch ^/plugins/maven-site-plugin-3.x/(.*)$ http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/ I'd like to change them to this: RedirectMatch ^/plugins/maven-site-plugin-2.x/(.*)$ /plugins/maven-site-plugin-2.3/$1 RedirectMatch ^/plugins/maven-site-plugin-3.x/(.*)$ http://maven.apache.org/plugins/maven-site-plugin/$1 This would also require changing the plugins/index page to point to /plugins/maven-site-plugin-2.x/ and /plugins/maven-site-plugin/ respectively for versions 2 and 3. 4. Change the deploy site URL in both POMs. 5. Move the current maven/plugins/trunk/maven-site-plugin/ to maven/plugins/branches/maven-site-plugin-2.x 6. Move maven/plugins/branches/maven-site-plugin-3.x to maven/plugins/trunk/maven-site-plugin/ I'll get on 1 and 2 right now. 3 I'd like to do after the release, once the deployed site is in place. 4 needs to be done before the release. 5 and 6 can be done either before or after the release, I'd prefer to do it before. Regards, Hervé Le samedi 2 juillet 2011, Dennis Lundberg a écrit : Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:
[VOTE] Release Sonar Drools Plugin version 0.1
Hi,
I would like to release the first version (0.1) of Drools Sonar Plugin.
This version requires sonar 2.2+
5 issues has been solved.
http://jira.codehaus.org/browse/SONARPLUGINS/fixforversion/17498
Download (snapshot)
http://snapshots.repository.codehaus.org/org/codehaus/sonar-plugins/sonar-drools-plugin/0.1-SNAPSHOT/sonar-drools-plugin-0.1-20110724.170524-1.jar
Documentation (draft)
http://docs.codehaus.org/display/SONAR/Drools+plugin
Test
It has been tested on Windows7 64bits with Sonar 2.9
Simple Test Case
- download Sonar 2.9 and unzip it ( http://www.sonarsource.org/downloads/ )
- put sonar-drools-plugin-0.1-20110724.170524-1.jar in
${SONAR_HOME}/extensions/plugins
- start sonar server
- download the simple project
http://svn.codehaus.org/sonar-plugins/trunk/drools/projects/simple/
- run mvn sonar:sonar in the simple project
Vote open to everybody for 72 hours.
[ ] +1
[ ] +0
[ ] -1
Jérémie.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
A thought: since 'extensions' has no 'management' or inheritance control, the use of it is actually harder and more obscure when people want to use other versions. It's far easier to just manage dependencies of the site plugin via pluginManagement. So, I'm in favor of using and documenting dependencies rather than extensions. On Sun, Jul 24, 2011 at 4:33 PM, Robert Scholte rfscho...@codehaus.org wrote: I've already made a jira-issue for it, MSITE-598 [1]. I think we should stay consistent: specify wagons with extensions.We just need to document this very well, both on the site and the failure-message, including the required xml to add to the pom. -Robert [1] http://jira.codehaus.org/browse/MSITE-598 From: herve.bout...@free.fr To: dev@maven.apache.org Subject: Re: Is Maven Site Plugin 3.0-beta-4 ready for release? Date: Sun, 24 Jul 2011 21:56:22 +0200 one last decision/documentation point about m-site-p 3 with Maven 3 we had a discussion on IRC yesterday with Robert, Mark and Benjamin about wagon and its change in M3 [1]. It was about the way we promote configuring wagon protocols in plugins: - in m-deploy-p, we promote using extensions (and the plugin doesn't add any wagon provider other that what is available from Maven core) - in m-site-p 3, we actually added a lot of wagon providers as dependencies (ssh, ftp, webdav, scm:svn), thus they are automagically available for end user, but this disables extension mecanisms for every providers added: if you want to change a wagon provider version, for example, defining it in extension won't work for m-site-p So we have to do a choice between 2 options: 1. be consistent with other plugins, remove every wagon provider from m-site-p and promote/document configuration done by end-users (either as extension or dependency). This will be needed notably for scp (which works automagically in M2) and ftp or scm:svn (which were added in m-site-p 3.0-beta*): I suppose we need to create a dedicated example. 2. let the multiple wagon providers in m-site-p, which will work automagically for a lot of protocols, but downloads a lot of artifacts and disables extensions definition for these protocols: this needs at least documentation So what should we do: 1. pure, with good explanations to help users understand what to do 2. magic at the beginning, but downloads the internet and more complex later ? Please correct if I misunderstood something... Regards, Hervé [1] https://cwiki.apache.org/MAVEN/maven-3x-compatibility- notes.html#Maven3.xCompatibilityNotes-TransportProtocols%2528Wagons%2529 Le vendredi 22 juillet 2011, Dennis Lundberg a écrit : On 2011-07-22 00:48, Hervé BOUTEMY wrote: Maven Site Plugin 3.0 is now ready for release (with its documentation) for me If anybody still has something to change, please explain what so we can fix it and release ASAP Thanks for all your work Hervé! Now that we plan for 3.0 to be the main version of the plugin, there are a couple of things I'd like to do: 1. Remove any references to the 3.x Subversion branch in the docs. I'll do this. 2. Document the difference between Maven 2 and Maven 3 with regards to inheritance that was recently discovered, if it hasn't already been done. I'll check this. 3. Switch the URLs for the deployed sites. We currently have these redirects: RedirectMatch ^/plugins/maven-site-plugin-2.x/(.*)$ /plugins/maven-site-plugin/$1 RedirectMatch ^/plugins/maven-site-plugin-3.x/(.*)$ http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/ I'd like to change them to this: RedirectMatch ^/plugins/maven-site-plugin-2.x/(.*)$ /plugins/maven-site-plugin-2.3/$1 RedirectMatch ^/plugins/maven-site-plugin-3.x/(.*)$ http://maven.apache.org/plugins/maven-site-plugin/$1 This would also require changing the plugins/index page to point to /plugins/maven-site-plugin-2.x/ and /plugins/maven-site-plugin/ respectively for versions 2 and 3. 4. Change the deploy site URL in both POMs. 5. Move the current maven/plugins/trunk/maven-site-plugin/ to maven/plugins/branches/maven-site-plugin-2.x 6. Move maven/plugins/branches/maven-site-plugin-3.x to maven/plugins/trunk/maven-site-plugin/ I'll get on 1 and 2 right now. 3 I'd like to do after the release, once the deployed site is in place. 4 needs to be done before the release. 5 and 6 can be done either before or after the release, I'd prefer to do it before. Regards, Hervé Le samedi 2 juillet 2011, Dennis Lundberg a écrit : Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one:
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
ok, I added a doc to add a protocol and improved the error message [1] I think we can safely do the change proposed in MSITE-598: users won't be lost (of course, they'll need to read the error message...) Regards, Hervé [1] http://jira.codehaus.org/browse/MSITE-599 Le dimanche 24 juillet 2011, Benson Margulies a écrit : A thought: since 'extensions' has no 'management' or inheritance control, the use of it is actually harder and more obscure when people want to use other versions. It's far easier to just manage dependencies of the site plugin via pluginManagement. So, I'm in favor of using and documenting dependencies rather than extensions. On Sun, Jul 24, 2011 at 4:33 PM, Robert Scholte rfscho...@codehaus.org wrote: I've already made a jira-issue for it, MSITE-598 [1]. I think we should stay consistent: specify wagons with extensions.We just need to document this very well, both on the site and the failure-message, including the required xml to add to the pom. -Robert [1] http://jira.codehaus.org/browse/MSITE-598 From: herve.bout...@free.fr To: dev@maven.apache.org Subject: Re: Is Maven Site Plugin 3.0-beta-4 ready for release? Date: Sun, 24 Jul 2011 21:56:22 +0200 one last decision/documentation point about m-site-p 3 with Maven 3 we had a discussion on IRC yesterday with Robert, Mark and Benjamin about wagon and its change in M3 [1]. It was about the way we promote configuring wagon protocols in plugins: - in m-deploy-p, we promote using extensions (and the plugin doesn't add any wagon provider other that what is available from Maven core) - in m-site-p 3, we actually added a lot of wagon providers as dependencies (ssh, ftp, webdav, scm:svn), thus they are automagically available for end user, but this disables extension mecanisms for every providers added: if you want to change a wagon provider version, for example, defining it in extension won't work for m-site-p So we have to do a choice between 2 options: 1. be consistent with other plugins, remove every wagon provider from m-site-p and promote/document configuration done by end-users (either as extension or dependency). This will be needed notably for scp (which works automagically in M2) and ftp or scm:svn (which were added in m-site-p 3.0-beta*): I suppose we need to create a dedicated example. 2. let the multiple wagon providers in m-site-p, which will work automagically for a lot of protocols, but downloads a lot of artifacts and disables extensions definition for these protocols: this needs at least documentation So what should we do: 1. pure, with good explanations to help users understand what to do 2. magic at the beginning, but downloads the internet and more complex later ? Please correct if I misunderstood something... Regards, Hervé [1] https://cwiki.apache.org/MAVEN/maven-3x-compatibility- notes.html#Maven3.xCompatibilityNotes-TransportProtocols%2528Wagons%2529 Le vendredi 22 juillet 2011, Dennis Lundberg a écrit : On 2011-07-22 00:48, Hervé BOUTEMY wrote: Maven Site Plugin 3.0 is now ready for release (with its documentation) for me If anybody still has something to change, please explain what so we can fix it and release ASAP Thanks for all your work Hervé! Now that we plan for 3.0 to be the main version of the plugin, there are a couple of things I'd like to do: 1. Remove any references to the 3.x Subversion branch in the docs. I'll do this. 2. Document the difference between Maven 2 and Maven 3 with regards to inheritance that was recently discovered, if it hasn't already been done. I'll check this. 3. Switch the URLs for the deployed sites. We currently have these redirects: RedirectMatch ^/plugins/maven-site-plugin-2.x/(.*)$ /plugins/maven-site-plugin/$1 RedirectMatch ^/plugins/maven-site-plugin-3.x/(.*)$ http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/ I'd like to change them to this: RedirectMatch ^/plugins/maven-site-plugin-2.x/(.*)$ /plugins/maven-site-plugin-2.3/$1 RedirectMatch ^/plugins/maven-site-plugin-3.x/(.*)$ http://maven.apache.org/plugins/maven-site-plugin/$1 This would also require changing the plugins/index page to point to /plugins/maven-site-plugin-2.x/ and /plugins/maven-site-plugin/ respectively for versions 2 and 3. 4. Change the deploy site URL in both POMs. 5. Move the current maven/plugins/trunk/maven-site-plugin/ to maven/plugins/branches/maven-site-plugin-2.x 6. Move maven/plugins/branches/maven-site-plugin-3.x to maven/plugins/trunk/maven-site-plugin/ I'll get on 1 and 2 right now. 3 I'd like to do after the release, once the deployed site is in place. 4 needs to be done before the release. 5 and 6 can be done either before or after the
Re: [VOTE] Release Sonar Drools Plugin version 0.1
Oops, wrong mailing list. Sorry.
Jérémie
2011/7/24 Jérémie j...@printstacktrace.org
Hi,
I would like to release the first version (0.1) of Drools Sonar Plugin.
This version requires sonar 2.2+
5 issues has been solved.
http://jira.codehaus.org/**browse/SONARPLUGINS/**fixforversion/17498http://jira.codehaus.org/browse/SONARPLUGINS/fixforversion/17498
Download (snapshot)
http://snapshots.repository.**codehaus.org/org/codehaus/**
sonar-plugins/sonar-drools-**plugin/0.1-SNAPSHOT/sonar-**
drools-plugin-0.1-20110724.**170524-1.jarhttp://snapshots.repository.codehaus.org/org/codehaus/sonar-plugins/sonar-drools-plugin/0.1-SNAPSHOT/sonar-drools-plugin-0.1-20110724.170524-1.jar
Documentation (draft)
http://docs.codehaus.org/**display/SONAR/Drools+pluginhttp://docs.codehaus.org/display/SONAR/Drools+plugin
Test
It has been tested on Windows7 64bits with Sonar 2.9
Simple Test Case
- download Sonar 2.9 and unzip it ( http://www.sonarsource.org/**
downloads/ http://www.sonarsource.org/downloads/ )
- put sonar-drools-plugin-0.1-**20110724.170524-1.jar in
${SONAR_HOME}/extensions/**plugins
- start sonar server
- download the simple project http://svn.codehaus.org/sonar-**
plugins/trunk/drools/projects/**simple/http://svn.codehaus.org/sonar-plugins/trunk/drools/projects/simple/
- run mvn sonar:sonar in the simple project
Vote open to everybody for 72 hours.
[ ] +1
[ ] +0
[ ] -1
Jérémie.
--**--**-
To unsubscribe, e-mail:
dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Sonar Drools Plugin version 0.1
Oops, wrong mailing list. Sorry.
Jérémie
2011/7/24 Jérémie j...@printstacktrace.org
Hi,
I would like to release the first version (0.1) of Drools Sonar Plugin.
This version requires sonar 2.2+
*5 issues has been solved.*
http://jira.codehaus.org/browse/SONARPLUGINS/fixforversion/17498
*Download *(snapshot)
http://snapshots.repository.codehaus.org/org/codehaus/sonar-plugins/sonar-drools-plugin/0.1-SNAPSHOT/sonar-drools-plugin-0.1-20110724.170524-1.jar
*Documentation *(draft)
http://docs.codehaus.org/display/SONAR/Drools+plugin
*Test*
It has been tested on Windows7 64bits with Sonar 2.9
Simple Test Case
- download Sonar 2.9 and unzip it ( http://www.sonarsource.org/downloads/)
- put sonar-drools-plugin-0.1-20110724.170524-1.jar in
${SONAR_HOME}/extensions/plugins
- start sonar server
- download the simple project
http://svn.codehaus.org/sonar-plugins/trunk/drools/projects/simple/
- run mvn sonar:sonar in the simple project
*Vote open to everybody for 72 hours.*
[ ] +1
[ ] +0
[ ] -1
Jérémie.
