RE: Maven Download Procedure
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 download Maven. Is /dyn/closer.cgi a Foundation requirement? Is there any project that uses an alternative? I see closer.cgi used on Tapestry and CouchDB. Apache Directory looks like it uses an intuitive approach (without breaking user experience): http://directory.apache.org/apacheds/2.0/download/download-windows.html If you are curious as to why I'm interested in this now. It is because I'm starting to pay much closer attention to Gradle, and Gradle gets this right. The process to download Gradle is: 1. Go to http://gradle.org 2. Click on the download link - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Maven Download Procedure
Nice Job! I'm not a graphics guy neither, but the idea is worth discussing! LieGrue, strub --- On Thu, 7/21/11, Robert Scholte rfscho...@codehaus.org wrote: From: Robert Scholte rfscho...@codehaus.org Subject: RE: Maven Download Procedure To: dev@maven.apache.org Date: Thursday, July 21, 2011, 8:34 PM 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 download Maven. Is /dyn/closer.cgi a Foundation requirement? Is there any project that uses an alternative? I see closer.cgi used on Tapestry and CouchDB. Apache Directory looks like it uses an intuitive approach (without breaking user experience): http://directory.apache.org/apacheds/2.0/download/download-windows.html If you are curious as to why I'm interested in this now. It is because I'm starting to pay much closer attention to Gradle, and Gradle gets this right. The process to download Gradle is: 1. Go to http://gradle.org 2. Click on the download link - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
Re: Maven Download Procedure
Someone has to get the ball rolling. So, good. But, I do think this project would benefit some designer attention. Let me see if I can take your site and break it down a bit. On Thu, Jul 21, 2011 at 3:52 PM, Mark Struberg strub...@yahoo.de wrote: Nice Job! I'm not a graphics guy neither, but the idea is worth discussing! LieGrue, strub --- On Thu, 7/21/11, Robert Scholte rfscho...@codehaus.org wrote: From: Robert Scholte rfscho...@codehaus.org Subject: RE: Maven Download Procedure To: dev@maven.apache.org Date: Thursday, July 21, 2011, 8:34 PM 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 download Maven. Is /dyn/closer.cgi a Foundation requirement? Is there any project that uses an alternative? I see closer.cgi used on Tapestry and CouchDB. Apache Directory looks like it uses an intuitive approach (without breaking user experience): http://directory.apache.org/apacheds/2.0/download/download-windows.html If you are curious as to why I'm interested in this now. It is because I'm starting to pay much closer attention to Gradle, and Gradle gets this right. The process to download Gradle is: 1. Go to http://gradle.org 2. Click on the download link - To
RE: Maven Download Procedure
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 download Maven. Is /dyn/closer.cgi a Foundation requirement? Is there any project that uses an alternative? I see closer.cgi used on Tapestry and CouchDB. Apache Directory looks like it uses an intuitive approach (without breaking user experience): http://directory.apache.org/apacheds/2.0/download/download-windows.html If you are curious as to why I'm interested in this now. It is because I'm starting to pay much closer attention to Gradle, and Gradle gets this right. The process to download Gradle is: 1. Go to http://gradle.org 2. Click on the download link - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
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 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
Re: Interested in helping a research study on Eclipse?
Hi, We're happy to announce that CodingSpectator now supports Eclipse Indigo (3.7) -- the latest version of Eclipse. We are looking for more participants. Your participation in our study will help to keep the Eclipse platform innovative. If you couldn't participate in the study because you had to use Indigo, you can now install CodingSpectator. If you are interested, please sign up at http://codingspectator.cs.illinois.edu/ConsentForm to participate in our study. We are thankful to those of you who have already participated in our study. Regards, Mohsen Vakilian On Fri, May 27, 2011 at 11:28 AM, Mohsen Vakilian mvaki...@illinois.edu wrote: Hi I'm Mohsen, a PhD student working with Prof. Ralph Johnson at the University of Illinois at Urbana-Champaign (UIUC). Together with my team mates [1], we are conducting a research study to better understand how developers, across different projects, interact with the Eclipse IDE for evolving and maintaining their code. We are extending this invitation to Java developers and would greatly appreciate and value your participation and help in our research study. To participate you should be at least 18 years old and use the Eclipse IDE for Java development. As a participant, we ask that you complete a short survey and install our Eclipse plug-in called CodingSpectator [2]. CodingSpectator monitors programming interactions non-intrusively in the background and periodically uploads it to a secure server at UIUC. To get a representative perspective of how you interact with Eclipse, we would appreciate if you could install CodingSpectator for two months. Rest assured that we are taking the utmost measures to protect your privacy and confidentiality. If you are interested, you may sign up at http://codingspectator.cs.illinois.edu/ConsentForm, which contains our consent form with all the details and procedures of our research study. Your participation will help us greatly as we try to better understand how developers interact with their IDE's so we can propose improvements which fit better with their mindsets. Thanks in advance for your time! Please do not hesitate to contact me (mvaki...@illinois.edu) if you have any questions or comments. More information can also be found at our FAQ [3]. Feel free to forward this invitation to anyone who might be interested in participating in this study. -- Mohsen Vakilian the CodingSpectator team [1] http://codingspectator.cs.illinois.edu/People [2] http://codingspectator.cs.illinois.edu [3] http://codingspectator.cs.illinois.edu/FAQ - 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
[jira] Subscription: Design Best Practices
Issue Subscription
Filter: Design Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
https://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
https://jira.codehaus.org/browse/MNG-612
MNG-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to jsp tags or jsf composites
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
https://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for properties and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
