Re: [vote] Release maven-deploy-plugin 2.2.1
Hi John, Can you reset the versions in JIRA and call this vote again? (yes, I know I have a vote from mid-may on the WAR plugin still hanging out there. I found more issues to fix and hope to get to it this week). - Brett John Casey wrote: Yes, you're right Mike. I've changed the subject accordingly... Brett, what I meant was that Maven cannot use a custom pluginRepository location given in a settings profile if there isn't a pom.xml running the build. While I know we have the apache.snapshots repository location available for normal artifact resolution, I'm pretty sure it's not available for plugin resolution. So, I'm not sure how you can use the deployed plugin snapshot via deploy:deploy-file. There is a bug filed against MNG for this, scheduled for 2.0.5. -john On 6/6/06, Mike Perham [EMAIL PROTECTED] wrote: John, is this going to be 2.3 or 2.2.1? If it's just bugfixes, shouldn't it be 2.2.1? -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 11:56 PM To: Maven Developers List Subject: Re: [vote] Release maven-deploy-plugin 2.3 BTW, the test snapshot for this release is 2.2.1-20060606.044331-3, on http://cvs.apache.org/maven-snasphot-repository Though you may have trouble trying to use the deploy-file mojo from there. The SVN revId is: 411999. -john On 6/6/06, John Casey [EMAIL PROTECTED] wrote: Hi, I've noticed that some people have had trouble with a few bugs in the current release of the maven-deploy-plugin, including: * POM and artifact build numbers are out of sync when using -DpomFile=... * Repository layout is not configurable I've checked, and both of these problems have been fixed. Additionally, I've gone over the documentation for this plugin, and it all looks to be in pretty good shape, including the parameter javadocs. Though it would be a small release, I believe that these two bugfixes warrant a fresh release. The only outstanding bug marked for 2.3 is MDEPLOY-28, which depends on a fix in maven-wagon...I don't believe this issue should hold up the release of 2.3. I'd like to open up the vote for 72 hours. Please cast your +1/+0/-1. Here's my +1. Thanks, john - 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]
Re: svn commit: r415252 - in /maven/sandbox/plugins/maven-docck-plugin/src/main/java/org/apache/maven/plugin/docck: AbstractCheckDocumentationMojo.java CheckPluginDocumentationMojo.java
[EMAIL PROTECTED] wrote: + * Copyright 2001-2005 The Apache Software Foundation. But this was only started in 2006 :) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r415252 - in /maven/sandbox/plugins/maven-docck-plugin/src/main/java/org/apache/maven/plugin/docck: AbstractCheckDocumentationMojo.java CheckPluginDocumentationMojo.java
Heheh, I didn't notice that... I just copied that from the other class. ^_^ btw, is that supposed to be 2006 only or 2001-2006 ? I remember Carlos said I'd change only the latter part Brett Porter wrote: [EMAIL PROTECTED] wrote: + * Copyright 2001-2005 The Apache Software Foundation. But this was only started in 2006 :) - 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 commit: r415252 - in /maven/sandbox/plugins/maven-docck-plugin/src/main/java/org/apache/maven/plugin/docck: AbstractCheckDocumentationMojo.java CheckPluginDocumentationMojo.java
started - last_changed AFAIK So in this case, just 2006. - Brett On 19/06/2006 5:03 PM, Edwin Punzalan wrote: Heheh, I didn't notice that... I just copied that from the other class. ^_^ btw, is that supposed to be 2006 only or 2001-2006 ? I remember Carlos said I'd change only the latter part Brett Porter wrote: [EMAIL PROTECTED] wrote: + * Copyright 2001-2005 The Apache Software Foundation. But this was only started in 2006 :) - 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] -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestions for handling native libraries
Mark Donszelmann wrote: Hi in the freehep-nar-plugin (for maven 1, being ported to maven 2) we have such a solution. snip Hrm, I wish I'd heard about this sooner! Sounds very interesting. I have a couple of questions... Do you unpack all nar files into the same directory? If so, how do you deal with different projects needing different versions of nars? Cheers, Rich -- 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]
Re: [jira] Closed: (MSITE-149) version tag is ignored for plugins in the reporting section of the POM
Was this actually fixed, or Cannot reproduce? - Brett On 19/06/2006 7:46 PM, Edwin Punzalan (JIRA) wrote: [ http://jira.codehaus.org/browse/MSITE-149?page=all ] Edwin Punzalan closed MSITE-149: Assign To: Edwin Punzalan Resolution: Fixed Fixed in SVN. version tag is ignored for plugins in the reporting section of the POM -- Key: MSITE-149 URL: http://jira.codehaus.org/browse/MSITE-149 Project: Maven 2.x Site Plugin Type: Bug Versions: 2.0-beta-5 Environment: Windows XP Reporter: Gunther Popp Assignee: Edwin Punzalan Fix For: 2.0 A version defined for a plugin in the reporting section of the POM is ignored. For example, I would expect that the following definition in a POM forces the usage of version 2.0-beta-4 of the site-plugin: project ... reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version2.0-beta-4/version /plugin ... However, Maven always uses the newer version 2.0-beta-5: mvn site -X + Error stacktraces are turned on. Maven version: 2.0.4 ... [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for updates from central [DEBUG] maven-site-plugin: resolved to version 2.0-beta-5 from repository central [DEBUG] Trying repository central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.pom 2/2K 2K downloaded [DEBUG] Artifact resolved [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: org.apache.maven.plugins:maven-plugins:pom:1 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: org.apache.maven:maven-parent:pom:1 from the repository. [DEBUG] Trying repository central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.jar 52K downloaded [DEBUG] Artifact resolved ... It doesn´t matter, if the plugin already exists in the local repostitory or not. -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Documenting Maven
Humans aren't capable to read more then 9 entries. Many of the questions asked on the user list are actually in the guides. So why don't they find it? http://maven.apache.org/guides/index.html links to a lot of good guides, but the way it is structured is plain wrong imho: - When people want to learn something about for example site deployment and they get the choice from Mini Guides, Introductory Material, Reference, ... they don't know what to choose. - When the pick Mini Guides they have to read 20+ entries, so 11+ to many. A refactor of that page, into a tree based structured on the functionality (not the format) will help a lot. The format (mini guide or introdcutory material) can be mentioned next to the entry. Brett Porter wrote: 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? btw: http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] However, I'm reading through them and going to reincoporate any additional thoughts into the current discussions (as I should have done *ages* ago). - Brett -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Documenting Maven
Yep, I think this thread was unanimous on that point. - Brett On 19/06/2006 10:08 PM, Geoffrey De Smet wrote: Humans aren't capable to read more then 9 entries. Many of the questions asked on the user list are actually in the guides. So why don't they find it? http://maven.apache.org/guides/index.html links to a lot of good guides, but the way it is structured is plain wrong imho: - When people want to learn something about for example site deployment and they get the choice from Mini Guides, Introductory Material, Reference, ... they don't know what to choose. - When the pick Mini Guides they have to read 20+ entries, so 11+ to many. A refactor of that page, into a tree based structured on the functionality (not the format) will help a lot. The format (mini guide or introdcutory material) can be mentioned next to the entry. Brett Porter wrote: 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? btw: http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] However, I'm reading through them and going to reincoporate any additional thoughts into the current discussions (as I should have done *ages* ago). - 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]
Re: [Proposal] Documenting Maven
On 19 Jun 06, at 12:37 AM 19 Jun 06, Brett Porter wrote: 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? btw: http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/% [EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/% [EMAIL PROTECTED] However, I'm reading through them and going to reincoporate any additional thoughts into the current discussions (as I should have done *ages* ago). A lot of the folks here and users had ideas on how to make the site better so how about we solicit for a users' favourite site with respect to usability. The other thing that might be interested is let folks who had ideas make some sample sites as it can often be hard to visualize what someone is talking about. A few minutes whipping up a new site.xml would give us lots of ideas. Most people seems to be concerned with easy navigation and that is something simple we can do before we start changing the structure of the content. I think simply reorganizing the content itself would be an easy first step. Having a few categories/trails seems to be a popular option so the big long list could just be categorized first and a navigation made. This should be done iteratively and let users guide it's final form with feed back instead of a grandiose plan to restructure everything everything. So I think something very simple and tenable is: 1. Ask users for favorite sites, good examples of quality navigation and ease of use. 2. Ask users to help show us what they want by making a site.xml and shows groupings they would find useful. 3. Do something really simple like categorize/trailize the existing content and make the first iteration of navigation improvements. While we're gathering feedback folks can think about how to improve the site further, change the structure of content, and create tools that might help. Shoot for short term changes that can be collected and published so users can browse around and we find what works as we go. Jason. - Brett - 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]
Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:08 AM 19 Jun 06, Geoffrey De Smet wrote: Humans aren't capable to read more then 9 entries. Many of the questions asked on the user list are actually in the guides. So why don't they find it? http://maven.apache.org/guides/index.html links to a lot of good guides, but the way it is structured is plain wrong imho: - When people want to learn something about for example site deployment and they get the choice from Mini Guides, Introductory Material, Reference, ... they don't know what to choose. - When the pick Mini Guides they have to read 20+ entries, so 11+ to many. Yup, I think everyone agrees. I just tried to jam as much content in there in as short a period of time as I could. A simple categorization/trail mechanism would be better. How would it look to you ideally? Would you categorize those and place the categories on the front page? Point to a documentation page with the categories listed there? I think these are really the questions we would like answers to. Guidance from users for our user documentation which will be the bulk of our documentation. Would you be willing to make a quick sample of what you think would work best? Jason. A refactor of that page, into a tree based structured on the functionality (not the format) will help a lot. The format (mini guide or introdcutory material) can be mentioned next to the entry. Brett Porter wrote: 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? btw: http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/% [EMAIL PROTECTED] http://mail-archives.apache.org/ mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] However, I'm reading through them and going to reincoporate any additional thoughts into the current discussions (as I should have done *ages* ago). - Brett -- With kind regards, Geoffrey De Smet - 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]
RE: [Proposal] Documenting Maven
Contrarian, one thing that is useful about the current approach is the browser search feature. It works pretty well to find the topics on a doc page with lots of entries and common search words. Hopefully the reorg solution doesn't lose a search-ability/adds a better search. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 7:21 AM To: Maven Developers List Subject: Re: [Proposal] Documenting Maven On 19 Jun 06, at 8:08 AM 19 Jun 06, Geoffrey De Smet wrote: Humans aren't capable to read more then 9 entries. Many of the questions asked on the user list are actually in the guides. So why don't they find it? http://maven.apache.org/guides/index.html links to a lot of good guides, but the way it is structured is plain wrong imho: - When people want to learn something about for example site deployment and they get the choice from Mini Guides, Introductory Material, Reference, ... they don't know what to choose. - When the pick Mini Guides they have to read 20+ entries, so 11+ to many. Yup, I think everyone agrees. I just tried to jam as much content in there in as short a period of time as I could. A simple categorization/trail mechanism would be better. How would it look to you ideally? Would you categorize those and place the categories on the front page? Point to a documentation page with the categories listed there? I think these are really the questions we would like answers to. Guidance from users for our user documentation which will be the bulk of our documentation. Would you be willing to make a quick sample of what you think would work best? Jason. A refactor of that page, into a tree based structured on the functionality (not the format) will help a lot. The format (mini guide or introdcutory material) can be mentioned next to the entry. Brett Porter wrote: 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? btw: http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/% [EMAIL PROTECTED] http://mail-archives.apache.org/ mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] However, I'm reading through them and going to reincoporate any additional thoughts into the current discussions (as I should have done *ages* ago). - Brett -- With kind regards, Geoffrey De Smet - 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: [vote] Release all wagons (was Re: [vote] Release wagon-webdav 1.0-beta-1)
Result: binding +1: 6 non-binding +1 : 3 Emmanuel Mike Perham a écrit : +1 -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 2:51 PM To: Maven Developers List Subject: Re: [vote] Release all wagons (was Re: [vote] Release wagon-webdav 1.0-beta-1) we want to keep them all in the same version (at least for now) so it's more easy to update them in projects that use them. Emmanuel Mike Perham a écrit : Can you summarize why? Do they all have outstanding fixes deserving of a release? Or are you just keeping them all versioned with the same version (1.0-beta-1)? -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 9:22 AM To: Maven Developers List Subject: [vote] Release all wagons (was Re: [vote] Release wagon-webdav 1.0-beta-1) I'd prefer to release all wagons. We have actually three open issues that will be fixed in beta-2 - 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: [Proposal] Documenting Maven
On 19/06/2006 10:16 PM, Jason van Zyl wrote: A lot of the folks here and users had ideas on how to make the site better so how about we solicit for a users' favourite site with respect to usability. Actually, that's what I was aiming for. There was a lot of feedback before, so I wanted to make sure that was captured in the form of what we agree on. The previous threads were summaries of the user list and dev list discussions of the time. The threads today are summaries that came from that. It all seems to be consensus. The other thing that might be interested is let folks who had ideas make some sample sites as it can often be hard to visualize what someone is talking about. A few minutes whipping up a new site.xml would give us lots of ideas. Sounds good. Raphael already did that last time which I've got in my notes here. While I wouldn't agree with the whole structure, there were plenty of good ideas that achieved goals others had stated. I think simply reorganizing the content itself would be an easy first step. Having a few categories/trails seems to be a popular option so the big long list could just be categorized first and a navigation made. I'd rather have a direction for how to do that then assemble a long list of documents that aren't finished, unless it is done somewhere off site. This should be done iteratively and let users guide it's final form with feed back instead of a grandiose plan to restructure everything everything. That's fine. I don't want a grandiose plan that is miles away (like I said to John, let's not overreach). I just want to capture everything we've discussed, and come up with a concrete plan of *next steps*. So I think something very simple and tenable is: 1. Ask users for favorite sites, good examples of quality navigation and ease of use. A useful exercise, but we're going to find a lot of repetition. If you want to do that, it'd be an interesting thing to know. The main ones mentioned so far have been the rails-type sites. 2. Ask users to help show us what they want by making a site.xml and shows groupings they would find useful. Also useful, not sure we'll get many. Want to add that to the above and send it out? 3. Do something really simple like categorize/trailize the existing content and make the first iteration of navigation improvements. That's what I was thinking from the front end, and an attack from the plugins at the back with a standardised set of docs for each. While we're gathering feedback folks can think about how to improve the site further, Do we really think there are any ideas that haven't been encountered in all these messages? change the structure of content, and create tools that might help. +1 Shoot for short term changes that can be collected and published so users can browse around and we find what works as we go. +1 - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:30 AM 19 Jun 06, Jeff Jensen wrote: Contrarian, one thing that is useful about the current approach is the browser search feature. It works pretty well to find the topics on a doc page with lots of entries and common search words. Hopefully the reorg solution doesn't lose a search-ability/adds a better search. That page is generated so there's no reason that can't remain as a view. This is why I think users need to get involved because people do work in different ways but we need to see what people want. I would urge anyone who is really interested to take a site.xml and swizzle into a view they think would work and publish it somewhere for us to look at. Probably 20 minutes of work and you'll go a long way to making the Maven site better. jason. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 7:21 AM To: Maven Developers List Subject: Re: [Proposal] Documenting Maven On 19 Jun 06, at 8:08 AM 19 Jun 06, Geoffrey De Smet wrote: Humans aren't capable to read more then 9 entries. Many of the questions asked on the user list are actually in the guides. So why don't they find it? http://maven.apache.org/guides/index.html links to a lot of good guides, but the way it is structured is plain wrong imho: - When people want to learn something about for example site deployment and they get the choice from Mini Guides, Introductory Material, Reference, ... they don't know what to choose. - When the pick Mini Guides they have to read 20+ entries, so 11 + to many. Yup, I think everyone agrees. I just tried to jam as much content in there in as short a period of time as I could. A simple categorization/trail mechanism would be better. How would it look to you ideally? Would you categorize those and place the categories on the front page? Point to a documentation page with the categories listed there? I think these are really the questions we would like answers to. Guidance from users for our user documentation which will be the bulk of our documentation. Would you be willing to make a quick sample of what you think would work best? Jason. A refactor of that page, into a tree based structured on the functionality (not the format) will help a lot. The format (mini guide or introdcutory material) can be mentioned next to the entry. Brett Porter wrote: 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? btw: http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/% [EMAIL PROTECTED] http://mail-archives.apache.org/ mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] However, I'm reading through them and going to reincoporate any additional thoughts into the current discussions (as I should have done *ages* ago). - Brett -- With kind regards, Geoffrey De Smet - 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] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Documenting Maven
We should have (a possibly categorised) index. On 19/06/2006 10:30 PM, Jeff Jensen wrote: Contrarian, one thing that is useful about the current approach is the browser search feature. It works pretty well to find the topics on a doc page with lots of entries and common search words. Hopefully the reorg solution doesn't lose a search-ability/adds a better search. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 7:21 AM To: Maven Developers List Subject: Re: [Proposal] Documenting Maven On 19 Jun 06, at 8:08 AM 19 Jun 06, Geoffrey De Smet wrote: Humans aren't capable to read more then 9 entries. Many of the questions asked on the user list are actually in the guides. So why don't they find it? http://maven.apache.org/guides/index.html links to a lot of good guides, but the way it is structured is plain wrong imho: - When people want to learn something about for example site deployment and they get the choice from Mini Guides, Introductory Material, Reference, ... they don't know what to choose. - When the pick Mini Guides they have to read 20+ entries, so 11+ to many. Yup, I think everyone agrees. I just tried to jam as much content in there in as short a period of time as I could. A simple categorization/trail mechanism would be better. How would it look to you ideally? Would you categorize those and place the categories on the front page? Point to a documentation page with the categories listed there? I think these are really the questions we would like answers to. Guidance from users for our user documentation which will be the bulk of our documentation. Would you be willing to make a quick sample of what you think would work best? Jason. A refactor of that page, into a tree based structured on the functionality (not the format) will help a lot. The format (mini guide or introdcutory material) can be mentioned next to the entry. Brett Porter wrote: 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? btw: http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/% [EMAIL PROTECTED] http://mail-archives.apache.org/ mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] However, I'm reading through them and going to reincoporate any additional thoughts into the current discussions (as I should have done *ages* ago). - Brett -- With kind regards, Geoffrey De Smet - 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] -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:37 AM 19 Jun 06, Brett Porter wrote: Do we really think there are any ideas that haven't been encountered in all these messages? Absolutely. If 10 people make a site I guarantee you something will fall out that hasn't been seen. If users don't want to help in this regard then they get whatever we come up with which would be unfortunate. I will post something to the users list asking for a list of favorite sites and example Maven sites. 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? Jason. - Brett - 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]
Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:39 AM 19 Jun 06, Brett Porter wrote:
We should have (a possibly categorised) index.
What if we slightly altered the the APT parser to pick up a tags/
categories identifier? We could even just put it in the title line so
we could start categorizing today. Something like:
-
Site Management {site,navigation}
-
Date
-
Author
Then we can start the process and alter the parser later.
Just a thought.
Jason.
On 19/06/2006 10:30 PM, Jeff Jensen wrote:
Contrarian, one thing that is useful about the current approach is
the
browser search feature. It works pretty well to find the topics
on a doc
page with lots of entries and common search words. Hopefully the
reorg
solution doesn't lose a search-ability/adds a better search.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June
19, 2006 7:21 AM
To: Maven Developers List
Subject: Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:08 AM 19 Jun 06, Geoffrey De Smet wrote:
Humans aren't capable to read more then 9 entries.
Many of the questions asked on the user list are actually in the
guides.
So why don't they find it?
http://maven.apache.org/guides/index.html
links to a lot of good guides, but the way it is structured is
plain wrong imho:
- When people want to learn something about for example site
deployment and they get the choice from Mini Guides,
Introductory Material, Reference, ... they don't know what to
choose.
- When the pick Mini Guides they have to read 20+ entries, so 11
+ to many.
Yup, I think everyone agrees. I just tried to jam as much content
in there
in as short a period of time as I could. A simple categorization/
trail
mechanism would be better.
How would it look to you ideally? Would you categorize those and
place the
categories on the front page? Point to a documentation page with the
categories listed there? I think these are really the questions we
would
like answers to. Guidance from users for our user documentation
which will
be the bulk of our documentation. Would you be willing to make a
quick
sample of what you think would work best?
Jason.
A refactor of that page, into a tree based structured on the
functionality (not the format) will help a lot.
The format (mini guide or introdcutory material) can be mentioned
next to the entry.
Brett Porter wrote:
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?
btw:
http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/%
[EMAIL PROTECTED] http://mail-
archives.apache.org/ mod_mbox/maven-dev/200603.mbox/%
[EMAIL PROTECTED]
However, I'm reading through them and going to reincoporate any
additional thoughts into the current discussions (as I should
have done *ages* ago).
- Brett
--
With kind regards,
Geoffrey De Smet
-
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]
--
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]
Re: [Proposal] Documenting Maven
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... - 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]
Request for release of maven-archiver-plugin
Hi, as MJAR-38 and MJAR-39 are now fixed and as suggested by Brett in http://jira.codehaus.org/browse/MJAR-38#action_67562 How about releasing the maven-archiver-plugin and the maven-jar-plugin? Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Documenting Maven
Pretty hesitant to modify APT since we got it from another source
(afraid I already violated that with || for table headers).
Is there a standard way we can add extra markup? Is it something that is
also possible in other input formats? (I guess properties in xdoc,
meta in xhtml?)
But yes, I think that's a good idea. I don't have the issue to hand, but
it's under the MNG documentation category already if you wanted to add
this as a possible solution.
Cheers,
Brett
On 19/06/2006 10:49 PM, Jason van Zyl wrote:
On 19 Jun 06, at 8:39 AM 19 Jun 06, Brett Porter wrote:
We should have (a possibly categorised) index.
What if we slightly altered the the APT parser to pick up a
tags/categories identifier? We could even just put it in the title line
so we could start categorizing today. Something like:
-
Site Management {site,navigation}
-
Date
-
Author
Then we can start the process and alter the parser later.
Just a thought.
Jason.
On 19/06/2006 10:30 PM, Jeff Jensen wrote:
Contrarian, one thing that is useful about the current approach is the
browser search feature. It works pretty well to find the topics on a
doc
page with lots of entries and common search words. Hopefully the reorg
solution doesn't lose a search-ability/adds a better search.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 19,
2006 7:21 AM
To: Maven Developers List
Subject: Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:08 AM 19 Jun 06, Geoffrey De Smet wrote:
Humans aren't capable to read more then 9 entries.
Many of the questions asked on the user list are actually in the
guides.
So why don't they find it?
http://maven.apache.org/guides/index.html
links to a lot of good guides, but the way it is structured is plain
wrong imho:
- When people want to learn something about for example site
deployment and they get the choice from Mini Guides, Introductory
Material, Reference, ... they don't know what to choose.
- When the pick Mini Guides they have to read 20+ entries, so 11+
to many.
Yup, I think everyone agrees. I just tried to jam as much content in
there
in as short a period of time as I could. A simple categorization/trail
mechanism would be better.
How would it look to you ideally? Would you categorize those and
place the
categories on the front page? Point to a documentation page with the
categories listed there? I think these are really the questions we would
like answers to. Guidance from users for our user documentation which
will
be the bulk of our documentation. Would you be willing to make a quick
sample of what you think would work best?
Jason.
A refactor of that page, into a tree based structured on the
functionality (not the format) will help a lot.
The format (mini guide or introdcutory material) can be mentioned
next to the entry.
Brett Porter wrote:
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?
btw:
http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/%
[EMAIL PROTECTED] http://mail-archives.apache.org/
mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED]
However, I'm reading through them and going to reincoporate any
additional thoughts into the current discussions (as I should have
done *ages* ago).
- Brett
--
With kind regards,
Geoffrey De Smet
-
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]
--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]
--
Brett Porter [EMAIL PROTECTED]
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for release of maven-archiver-plugin
maven-archiver-plugin doesn't exist (it's just maven-archiver, a component). That can be released when the JAR plugin is, but there are a number of other scheduled issues for 2.1 that need to be fixed first (I think some of the new functionality is not completely implemented/documented). - Brett On 19/06/2006 10:49 PM, Jochen Wiedmann wrote: Hi, as MJAR-38 and MJAR-39 are now fixed and as suggested by Brett in http://jira.codehaus.org/browse/MJAR-38#action_67562 How about releasing the maven-archiver-plugin and the maven-jar-plugin? Thanks, Jochen - 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]
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]
Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:56 AM 19 Jun 06, Brett Porter wrote:
Pretty hesitant to modify APT since we got it from another source
(afraid I already violated that with || for table headers).
Oh, it was maimed the second it arrive here :-)
Is there a standard way we can add extra markup? Is it something
that is also possible in other input formats? (I guess properties
in xdoc, meta in xhtml?)
In APT the only option would be a comment. The format has been
tampered with so I don't see any harm in extending it further.
But yes, I think that's a good idea. I don't have the issue to
hand, but it's under the MNG documentation category already if you
wanted to add this as a possible solution.
Cheers,
Brett
On 19/06/2006 10:49 PM, Jason van Zyl wrote:
On 19 Jun 06, at 8:39 AM 19 Jun 06, Brett Porter wrote:
We should have (a possibly categorised) index.
What if we slightly altered the the APT parser to pick up a tags/
categories identifier? We could even just put it in the title line
so we could start categorizing today. Something like:
-
Site Management {site,navigation}
-
Date
-
Author
Then we can start the process and alter the parser later.
Just a thought.
Jason.
On 19/06/2006 10:30 PM, Jeff Jensen wrote:
Contrarian, one thing that is useful about the current approach
is the
browser search feature. It works pretty well to find the topics
on a doc
page with lots of entries and common search words. Hopefully
the reorg
solution doesn't lose a search-ability/adds a better search.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June
19, 2006 7:21 AM
To: Maven Developers List
Subject: Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:08 AM 19 Jun 06, Geoffrey De Smet wrote:
Humans aren't capable to read more then 9 entries.
Many of the questions asked on the user list are actually in
the guides.
So why don't they find it?
http://maven.apache.org/guides/index.html
links to a lot of good guides, but the way it is structured is
plain wrong imho:
- When people want to learn something about for example site
deployment and they get the choice from Mini Guides,
Introductory Material, Reference, ... they don't know what
to choose.
- When the pick Mini Guides they have to read 20+ entries, so
11+ to many.
Yup, I think everyone agrees. I just tried to jam as much
content in there
in as short a period of time as I could. A simple categorization/
trail
mechanism would be better.
How would it look to you ideally? Would you categorize those and
place the
categories on the front page? Point to a documentation page with
the
categories listed there? I think these are really the questions
we would
like answers to. Guidance from users for our user documentation
which will
be the bulk of our documentation. Would you be willing to make a
quick
sample of what you think would work best?
Jason.
A refactor of that page, into a tree based structured on the
functionality (not the format) will help a lot.
The format (mini guide or introdcutory material) can be
mentioned next to the entry.
Brett Porter wrote:
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?
btw:
http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/%
[EMAIL PROTECTED] http://mail-
archives.apache.org/ mod_mbox/maven-dev/200603.mbox/%
[EMAIL PROTECTED]
However, I'm reading through them and going to reincoporate
any additional thoughts into the current discussions (as I
should have done *ages* ago).
- Brett
--
With kind regards,
Geoffrey De Smet
--
---
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]
--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]
--
Brett Porter [EMAIL PROTECTED]
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
-
To
Re: Request for release of maven-archiver-plugin
On 6/19/06, Brett Porter [EMAIL PROTECTED] wrote: maven-archiver-plugin doesn't exist (it's just maven-archiver, a component). Right, sorry. That can be released when the JAR plugin is, but there are a number of other scheduled issues for 2.1 that need to be fixed first (I think some of the new functionality is not completely implemented/documented). Can you be more specific? Certain issues? Perhaps Mike is still ready to pull patches in, if I provide them? 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]
Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:56 AM 19 Jun 06, Brett Porter wrote:
Pretty hesitant to modify APT since we got it from another source
(afraid I already violated that with || for table headers).
Oh, it was maimed the second it arrive here :-)
Is there a standard way we can add extra markup? Is it something
that is also possible in other input formats? (I guess properties
in xdoc, meta in xhtml?)
In APT the only option would be a comment. The format has been
tampered with so I don't see any harm in extending it further.
But yes, I think that's a good idea. I don't have the issue to
hand, but it's under the MNG documentation category already if you
wanted to add this as a possible solution.
Cheers,
Brett
On 19/06/2006 10:49 PM, Jason van Zyl wrote:
On 19 Jun 06, at 8:39 AM 19 Jun 06, Brett Porter wrote:
We should have (a possibly categorised) index.
What if we slightly altered the the APT parser to pick up a tags/
categories identifier? We could even just put it in the title line
so we could start categorizing today. Something like:
-
Site Management {site,navigation}
-
Date
-
Author
Then we can start the process and alter the parser later.
Just a thought.
Jason.
On 19/06/2006 10:30 PM, Jeff Jensen wrote:
Contrarian, one thing that is useful about the current approach
is the
browser search feature. It works pretty well to find the topics
on a doc
page with lots of entries and common search words. Hopefully
the reorg
solution doesn't lose a search-ability/adds a better search.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June
19, 2006 7:21 AM
To: Maven Developers List
Subject: Re: [Proposal] Documenting Maven
On 19 Jun 06, at 8:08 AM 19 Jun 06, Geoffrey De Smet wrote:
Humans aren't capable to read more then 9 entries.
Many of the questions asked on the user list are actually in
the guides.
So why don't they find it?
http://maven.apache.org/guides/index.html
links to a lot of good guides, but the way it is structured is
plain wrong imho:
- When people want to learn something about for example site
deployment and they get the choice from Mini Guides,
Introductory Material, Reference, ... they don't know what
to choose.
- When the pick Mini Guides they have to read 20+ entries, so
11+ to many.
Yup, I think everyone agrees. I just tried to jam as much
content in there
in as short a period of time as I could. A simple categorization/
trail
mechanism would be better.
How would it look to you ideally? Would you categorize those and
place the
categories on the front page? Point to a documentation page with
the
categories listed there? I think these are really the questions
we would
like answers to. Guidance from users for our user documentation
which will
be the bulk of our documentation. Would you be willing to make a
quick
sample of what you think would work best?
Jason.
A refactor of that page, into a tree based structured on the
functionality (not the format) will help a lot.
The format (mini guide or introdcutory material) can be
mentioned next to the entry.
Brett Porter wrote:
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?
btw:
http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/%
[EMAIL PROTECTED] http://mail-
archives.apache.org/ mod_mbox/maven-dev/200603.mbox/%
[EMAIL PROTECTED]
However, I'm reading through them and going to reincoporate
any additional thoughts into the current discussions (as I
should have done *ages* ago).
- Brett
--
With kind regards,
Geoffrey De Smet
--
---
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]
--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]
--
Brett Porter [EMAIL PROTECTED]
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
-
To
Re: Plugin documentation standard
Here's some additions, sorry I missed these: # must have link to the API docs of of additional types (eg MavenArchiveConfiguration) # must describe how the configuration of some elements affects others, where applicable (for example, surefire's suiteXmlFiles disables the includes/excludes options) # must document relationship with other plugins - Brett On 19/06/2006 11:47 PM, Brett Porter wrote: Hi, Just thought I'd break this one out. This needs to be converted to a guide - which is one of the tasks I'll list at the end. (this is MNG-1987, btw) * Required POM Elements - modelVersion, version, group ID, artifact ID, packaging (required anyway to build) - name - description - url - issueManagement - prerequisites maven (I think it's good to make people think about this) - inceptionYear - mailingLists (just a warning if missing as I guess there might not be one, though we should have some other contact details - do general contact details fit a list description?) - license - scm (warning if missing, may not be OSS!) - organization - plugin report must be configured * Plugin configuration - each @parameter field must have a description. Not required if @readonly or @component - Class level should have a description. * Documents - plugins must have an /index.html (from apt, xdoc, html etc). Not generated automatically - plugins must have a /usage.html, where the standard use case is described. The recommended lifecycle phases should be listed. This will almost be boilerplate (just some common configuration items, how to include it in the POM, and whether it usually needs executions or not). It will probably repeat for each goal available. - plugins should have examples/*.html for individual use cases. - plugins should have a FAQ page for common questions, issues, and misunderstandings Consider this example: - use case: http://maven.apache.org/plugins/maven-release-plugin/introduction.html - specific examples: http://maven.apache.org/plugins/maven-release-plugin/howto.html (should be broken out into examples/dryRun.apt, etc) * Site descriptor - navigation must include the link to the usage and the examples under that * Reports - Plugin must have javadoc, jxr and changelog reports * General guidelines - Always be able to publish the latest and greatest. Mark new features with the version they were introduced. Mark caveats in certain versions. - The Jetty6 and Cargo plugins are the level of information we are looking for. * Tasks (any volunteers? If so, please create a JIRA and grab it (and drop a reply here to say so - eventually we'll get these all in regardless though) - convert the above to a guide on the Maven website - add any missing checks to the docck plugin - wire up the docck plugin to all maven plugins - pilot plugins. Some of these have gone into JIRA already and been assigned. - rework the plugin reference page (a separate discussion, MPLUGIN-7 is a starting point). This should be reworked not to overwrite index.html - create an archetype for a compliant plugin - add @since tag to plugin fields (it's standard javadoc so we can dual purpose it, but we need to acknowledge it in the descriptor) Any additional thoughts? - 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]
Re: Request for release of maven-archiver-plugin
They should be the ones scheduled for 2.1 (and there may be some unscheduled that should be scheduled - I haven't reviewed recently). I know at least that Jerome had a queue of patches. I've been meaning to take a look if anyone can take an assessment (or better, a committer run with it), that'd be great Thanks, Brett On 19/06/2006 11:24 PM, Jochen Wiedmann wrote: On 6/19/06, Brett Porter [EMAIL PROTECTED] wrote: maven-archiver-plugin doesn't exist (it's just maven-archiver, a component). Right, sorry. That can be released when the JAR plugin is, but there are a number of other scheduled issues for 2.1 that need to be fixed first (I think some of the new functionality is not completely implemented/documented). Can you be more specific? Certain issues? Perhaps Mike is still ready to pull patches in, if I provide them? Jochen -- 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]
Plugin documentation standard
Hi, Just thought I'd break this one out. This needs to be converted to a guide - which is one of the tasks I'll list at the end. (this is MNG-1987, btw) * Required POM Elements - modelVersion, version, group ID, artifact ID, packaging (required anyway to build) - name - description - url - issueManagement - prerequisites maven (I think it's good to make people think about this) - inceptionYear - mailingLists (just a warning if missing as I guess there might not be one, though we should have some other contact details - do general contact details fit a list description?) - license - scm (warning if missing, may not be OSS!) - organization - plugin report must be configured * Plugin configuration - each @parameter field must have a description. Not required if @readonly or @component - Class level should have a description. * Documents - plugins must have an /index.html (from apt, xdoc, html etc). Not generated automatically - plugins must have a /usage.html, where the standard use case is described. The recommended lifecycle phases should be listed. This will almost be boilerplate (just some common configuration items, how to include it in the POM, and whether it usually needs executions or not). It will probably repeat for each goal available. - plugins should have examples/*.html for individual use cases. - plugins should have a FAQ page for common questions, issues, and misunderstandings Consider this example: - use case: http://maven.apache.org/plugins/maven-release-plugin/introduction.html - specific examples: http://maven.apache.org/plugins/maven-release-plugin/howto.html (should be broken out into examples/dryRun.apt, etc) * Site descriptor - navigation must include the link to the usage and the examples under that * Reports - Plugin must have javadoc, jxr and changelog reports * General guidelines - Always be able to publish the latest and greatest. Mark new features with the version they were introduced. Mark caveats in certain versions. - The Jetty6 and Cargo plugins are the level of information we are looking for. * Tasks (any volunteers? If so, please create a JIRA and grab it (and drop a reply here to say so - eventually we'll get these all in regardless though) - convert the above to a guide on the Maven website - add any missing checks to the docck plugin - wire up the docck plugin to all maven plugins - pilot plugins. Some of these have gone into JIRA already and been assigned. - rework the plugin reference page (a separate discussion, MPLUGIN-7 is a starting point). This should be reworked not to overwrite index.html - create an archetype for a compliant plugin - add @since tag to plugin fields (it's standard javadoc so we can dual purpose it, but we need to acknowledge it in the descriptor) Any additional thoughts? - 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]
action items
Hi, Aside from the stuff related to plugin documentation, we have some other things to do. Same approach - here's a list, looking for a show of hands on who's interested (or if these seem wrong). Eventually all need to get to JIRA: - apply the maven site skin consistently (MNG-1212) - site structuring (this already had concrete proposals): * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL PROTECTED] * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL PROTECTED] * see also Better Builds with Maven section on separating developer and user content - set up a staging site - remove 2 from Maven 2 references (it's just Maven). We'll still refer to Maven 1.x in comparisons and pointing to the Maven 1.1 docs. - create a plugin link page that is categorised (j2ee, ide, artifact handling, test, packaging, CI, archetypes, source generators, reports) - to be automated later by additional metadata - enhance plugin link page (more plugins, add current release version and quality (dev, alpha, beta, stable) - to be automated later (MNG-1213) - add search box to the index page (google for now) - chop up the getting started guide so it is again something you could do in 10 minutes to get a feel for Maven (perhaps go back to the level of the original guide). Maybe rename to something else? I used to call it the 10 minute test on Maven 1. - categorise the guides page, rename the page as Index (not index.html) - MNG-1540 - relabel other projects FAQ as guide for sync partners or similar. It should go into a repository related subsection. The other thing to do is revise the front page and navigation. So I'll propose mine based on the discussions I've been reading, and Jason will gather up suggestions from others. Between them we can probably start making steps. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Docs: remaining questions
Hi (again), From reviewing the threads, I found the following things to still be a bit up in the air so thought there should be further discussion: 1) should we drop the standard reports from the maven site? Tim and John C seemed to think so (if I understand John's stand), among others (Brian Wallace, IIRC). I imagine they get replaced by hand crafter equivalents. I think the generated approach (possibly with extra comment) still has merit, so what about we hand craft it until we have what we think is right, and then automate that? 2) JIRA documentation Can anyone explain what the documentation version is for? What do others think about merging the documentation categories for now, since we seem to agree this isn't the right breakdown of docs? (I saw a couple of dupes when I surfed across categories, but none within a single one). This gives a more managable task list. 3) What is the role of the wiki? Wendy made some very good points about the accessibility of the wiki for getting doc contributions, which I think is worth exploring, especially since we can automatically bring it into the site. However, it comes with the downside that it can be less thoroughly reviewed and sometimes unstructured unless the person is really putting some extra effort in. So I think we have some alternatives: - use the wiki for everything, auto generate site - use the wiki for a specified section of the site, autogenerate (and perhaps mark as being contributed) - use the wiki as a holding area for new doc contributions I'd go with a combo of the last 2. I think the cookbooks section should have 2 parts - an apt/etc part and a contributed part autogenerated from the wiki using Wendy's proposal (and possibly doing the same per plugin) I'm in favour of using APT/local confluence markup for the main, verified part of the site (would want an easy way to convert confluence to APT, though). Thoughts on these? - 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]
Re: Configure plugins through settings.xml
Tomasz Pik tompik at gmail.com writes: Hello, It's currently not possible but generally I think it would be nice to have possibility to configure plugins through profiles using $HOME/.m2/settings.xml Please note there are some bugs in maven that prevent all of the aspects of plugin configurations from working properly from within profiles (i.e. defined inside profiles). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestions for handling native libraries
The jar file and its attached nar files share one pom, so are associated to one version. The NAR gets unpacked in the local repository under the directory where the jar file is stored, so underneath a parent directory with that version number. Nothing is currently done about locking the file system while unpacking, so running two mavens in parallel using the same local repository may not work correctly, but I have seen maven (with jars only) making mistakes in writing metafiles when two mavens run in parallel, so this may be a general problem still. Regards Mark On Jun 19, 2006, at 2:32 AM, Richard van der Hoff wrote: Mark Donszelmann wrote: Hi in the freehep-nar-plugin (for maven 1, being ported to maven 2) we have such a solution. snip Hrm, I wish I'd heard about this sooner! Sounds very interesting. I have a couple of questions... Do you unpack all nar files into the same directory? If so, how do you deal with different projects needing different versions of nars? Cheers, Rich -- 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]
Re: Docs: remaining questions
On 6/19/06, Brett Porter [EMAIL PROTECTED] wrote: 1) should we drop the standard reports from the maven site? -1 (Eat your own dog food. :-) -- 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]
RE: Request for release of maven-archiver-plugin
I can continue to work with Jochen. Jochen, if you want to go through JIRA and send me pointers to issues you think are ready, please do. I'll have a few hours to spend on this tomorrow night. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 8:44 AM To: Maven Developers List Subject: Re: Request for release of maven-archiver-plugin They should be the ones scheduled for 2.1 (and there may be some unscheduled that should be scheduled - I haven't reviewed recently). I know at least that Jerome had a queue of patches. I've been meaning to take a look if anyone can take an assessment (or better, a committer run with it), that'd be great Thanks, Brett On 19/06/2006 11:24 PM, Jochen Wiedmann wrote: On 6/19/06, Brett Porter [EMAIL PROTECTED] wrote: maven-archiver-plugin doesn't exist (it's just maven-archiver, a component). Right, sorry. That can be released when the JAR plugin is, but there are a number of other scheduled issues for 2.1 that need to be fixed first (I think some of the new functionality is not completely implemented/documented). Can you be more specific? Certain issues? Perhaps Mike is still ready to pull patches in, if I provide them? Jochen -- 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: Docs: remaining questions
Not sure if this is serious, but I'm asking if the other guys are suggesting we develop a new brand of dog food to eat. - Brett On 20/06/2006 12:33 AM, Jochen Wiedmann wrote: On 6/19/06, Brett Porter [EMAIL PROTECTED] wrote: 1) should we drop the standard reports from the maven site? -1 (Eat your own dog food. :-) -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin documentation standard
On 19 Jun 06, at 9:47 AM 19 Jun 06, Brett Porter wrote: Hi, Just thought I'd break this one out. This needs to be converted to a guide - which is one of the tasks I'll list at the end. (this is MNG-1987, btw) * Required POM Elements - modelVersion, version, group ID, artifact ID, packaging (required anyway to build) - name - description - url - issueManagement - prerequisites maven (I think it's good to make people think about this) - inceptionYear - mailingLists (just a warning if missing as I guess there might not be one, though we should have some other contact details - do general contact details fit a list description?) - license - scm (warning if missing, may not be OSS!) - organization - plugin report must be configured * Plugin configuration - each @parameter field must have a description. Not required if @readonly or @component - Class level should have a description. * Documents - plugins must have an /index.html (from apt, xdoc, html etc). Not generated automatically - plugins must have a /usage.html, where the standard use case is described. The recommended lifecycle phases should be listed. This will almost be boilerplate (just some common configuration items, how to include it in the POM, and whether it usually needs executions or not). It will probably repeat for each goal available. - plugins should have examples/*.html for individual use cases. - plugins should have a FAQ page for common questions, issues, and misunderstandings Consider this example: - use case: http://maven.apache.org/plugins/maven-release-plugin/ introduction.html - specific examples: http://maven.apache.org/plugins/maven-release- plugin/howto.html (should be broken out into examples/dryRun.apt, etc) * Site descriptor - navigation must include the link to the usage and the examples under that * Reports - Plugin must have javadoc, jxr and changelog reports * General guidelines - Always be able to publish the latest and greatest. Mark new features with the version they were introduced. Mark caveats in certain versions. - The Jetty6 and Cargo plugins are the level of information we are looking for. * Tasks (any volunteers? If so, please create a JIRA and grab it (and drop a reply here to say so - eventually we'll get these all in regardless though) - convert the above to a guide on the Maven website - add any missing checks to the docck plugin - wire up the docck plugin to all maven plugins - pilot plugins. Some of these have gone into JIRA already and been assigned. - rework the plugin reference page (a separate discussion, MPLUGIN-7 is a starting point). This should be reworked not to overwrite index.html - create an archetype for a compliant plugin - add @since tag to plugin fields (it's standard javadoc so we can dual purpose it, but we need to acknowledge it in the descriptor) Any additional thoughts? Make a plugin to check all these thing and plug it into the validation phase. This is all nice to enumerate but it will only take effect when it is easy for people to comply. - 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]
Re: action items
On 19 Jun 06, at 10:14 AM 19 Jun 06, Brett Porter wrote: Hi, Aside from the stuff related to plugin documentation, we have some other things to do. Same approach - here's a list, looking for a show of hands on who's interested (or if these seem wrong). Eventually all need to get to JIRA: - apply the maven site skin consistently (MNG-1212) - site structuring (this already had concrete proposals): * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/% [EMAIL PROTECTED] * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/% [EMAIL PROTECTED] * see also Better Builds with Maven section on separating developer and user content - set up a staging site - remove 2 from Maven 2 references (it's just Maven). We'll still refer to Maven 1.x in comparisons and pointing to the Maven 1.1 docs. - create a plugin link page that is categorised (j2ee, ide, artifact handling, test, packaging, CI, archetypes, source generators, reports) - to be automated later by additional metadata - enhance plugin link page (more plugins, add current release version and quality (dev, alpha, beta, stable) - to be automated later (MNG-1213) - add search box to the index page (google for now) - chop up the getting started guide so it is again something you could do in 10 minutes to get a feel for Maven (perhaps go back to the level of the original guide). Maybe rename to something else? I used to call it the 10 minute test on Maven 1. -1 Leave this one and make a shorter one. This can be broken up into stages and walked through wizard style but it's comprehensive. It's not approachable right now, I agree, but it's a full working scenerio. Something smaller can be made for the 10 minute thing. - categorise the guides page, rename the page as Index (not index.html) - MNG-1540 John worked on a new list of cateogies based on JIRA and I still have the list that we (brett/jason) refined from that. I'll dig that out before I jump on a plane. - relabel other projects FAQ as guide for sync partners or similar. It should go into a repository related subsection. The other thing to do is revise the front page and navigation. So I'll propose mine based on the discussions I've been reading, and Jason will gather up suggestions from others. Between them we can probably start making steps. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin documentation standard
Why stop at a plugin? Wouldn't this be valuable to have for thirdparty dependencies as well? Ruel Loehr JBoss QA - 512-342-7840 ext 2011 Yahoo: ruelloehr Skype: ruelloehr AOL: dokoruel -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 9:56 AM To: Maven Developers List Subject: Re: Plugin documentation standard On 19 Jun 06, at 9:47 AM 19 Jun 06, Brett Porter wrote: Hi, Just thought I'd break this one out. This needs to be converted to a guide - which is one of the tasks I'll list at the end. (this is MNG-1987, btw) * Required POM Elements - modelVersion, version, group ID, artifact ID, packaging (required anyway to build) - name - description - url - issueManagement - prerequisites maven (I think it's good to make people think about this) - inceptionYear - mailingLists (just a warning if missing as I guess there might not be one, though we should have some other contact details - do general contact details fit a list description?) - license - scm (warning if missing, may not be OSS!) - organization - plugin report must be configured * Plugin configuration - each @parameter field must have a description. Not required if @readonly or @component - Class level should have a description. * Documents - plugins must have an /index.html (from apt, xdoc, html etc). Not generated automatically - plugins must have a /usage.html, where the standard use case is described. The recommended lifecycle phases should be listed. This will almost be boilerplate (just some common configuration items, how to include it in the POM, and whether it usually needs executions or not). It will probably repeat for each goal available. - plugins should have examples/*.html for individual use cases. - plugins should have a FAQ page for common questions, issues, and misunderstandings Consider this example: - use case: http://maven.apache.org/plugins/maven-release-plugin/ introduction.html - specific examples: http://maven.apache.org/plugins/maven-release- plugin/howto.html (should be broken out into examples/dryRun.apt, etc) * Site descriptor - navigation must include the link to the usage and the examples under that * Reports - Plugin must have javadoc, jxr and changelog reports * General guidelines - Always be able to publish the latest and greatest. Mark new features with the version they were introduced. Mark caveats in certain versions. - The Jetty6 and Cargo plugins are the level of information we are looking for. * Tasks (any volunteers? If so, please create a JIRA and grab it (and drop a reply here to say so - eventually we'll get these all in regardless though) - convert the above to a guide on the Maven website - add any missing checks to the docck plugin - wire up the docck plugin to all maven plugins - pilot plugins. Some of these have gone into JIRA already and been assigned. - rework the plugin reference page (a separate discussion, MPLUGIN-7 is a starting point). This should be reworked not to overwrite index.html - create an archetype for a compliant plugin - add @since tag to plugin fields (it's standard javadoc so we can dual purpose it, but we need to acknowledge it in the descriptor) Any additional thoughts? Make a plugin to check all these thing and plug it into the validation phase. This is all nice to enumerate but it will only take effect when it is easy for people to comply. - 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] -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.8.3/359 - Release Date: 6/8/2006 -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.8.3/359 - Release Date: 6/8/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestions for handling native libraries
Mark Donszelmann wrote: The NAR gets unpacked in the local repository under the directory where the jar file is stored, so underneath a parent directory with that version number. Ah ha, I see. In that case, how does your System.load() call know where to find the library? I guess it has knowledge of group, artifact, version built into the java jar? And if you have libraries which are linked at the native level, how does the os library loader know where to find the prerequisite libraries? Cheers, 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]
Re: Plugin documentation standard
I agree, I think there are some lessons to be learned from this for apis and other project types in general (archetypes, and so on), and the same tools can be used. Worth keeping in mind, but I believe we've identified a particular problem with plugin docs and should work to improve that asap. - Brett On 20/06/2006 1:15 AM, Ruel Loehr wrote: Why stop at a plugin? Wouldn't this be valuable to have for thirdparty dependencies as well? Ruel Loehr JBoss QA - 512-342-7840 ext 2011 Yahoo: ruelloehr Skype: ruelloehr AOL: dokoruel -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 9:56 AM To: Maven Developers List Subject: Re: Plugin documentation standard On 19 Jun 06, at 9:47 AM 19 Jun 06, Brett Porter wrote: Hi, Just thought I'd break this one out. This needs to be converted to a guide - which is one of the tasks I'll list at the end. (this is MNG-1987, btw) * Required POM Elements - modelVersion, version, group ID, artifact ID, packaging (required anyway to build) - name - description - url - issueManagement - prerequisites maven (I think it's good to make people think about this) - inceptionYear - mailingLists (just a warning if missing as I guess there might not be one, though we should have some other contact details - do general contact details fit a list description?) - license - scm (warning if missing, may not be OSS!) - organization - plugin report must be configured * Plugin configuration - each @parameter field must have a description. Not required if @readonly or @component - Class level should have a description. * Documents - plugins must have an /index.html (from apt, xdoc, html etc). Not generated automatically - plugins must have a /usage.html, where the standard use case is described. The recommended lifecycle phases should be listed. This will almost be boilerplate (just some common configuration items, how to include it in the POM, and whether it usually needs executions or not). It will probably repeat for each goal available. - plugins should have examples/*.html for individual use cases. - plugins should have a FAQ page for common questions, issues, and misunderstandings Consider this example: - use case: http://maven.apache.org/plugins/maven-release-plugin/ introduction.html - specific examples: http://maven.apache.org/plugins/maven-release- plugin/howto.html (should be broken out into examples/dryRun.apt, etc) * Site descriptor - navigation must include the link to the usage and the examples under that * Reports - Plugin must have javadoc, jxr and changelog reports * General guidelines - Always be able to publish the latest and greatest. Mark new features with the version they were introduced. Mark caveats in certain versions. - The Jetty6 and Cargo plugins are the level of information we are looking for. * Tasks (any volunteers? If so, please create a JIRA and grab it (and drop a reply here to say so - eventually we'll get these all in regardless though) - convert the above to a guide on the Maven website - add any missing checks to the docck plugin - wire up the docck plugin to all maven plugins - pilot plugins. Some of these have gone into JIRA already and been assigned. - rework the plugin reference page (a separate discussion, MPLUGIN-7 is a starting point). This should be reworked not to overwrite index.html - create an archetype for a compliant plugin - add @since tag to plugin fields (it's standard javadoc so we can dual purpose it, but we need to acknowledge it in the descriptor) Any additional thoughts? Make a plugin to check all these thing and plug it into the validation phase. This is all nice to enumerate but it will only take effect when it is easy for people to comply. - 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] -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r415349 - in /maven/surefire/trunk/surefire-booter: ./ src/main/java/org/apache/maven/surefire/booter/ src/main/java/org/apache/maven/surefire/booter/output/ src/test/ src/test/java/ s
[EMAIL PROTECTED] wrote: Author: carlos Date: Mon Jun 19 08:00:44 2006 New Revision: 415349 URL: http://svn.apache.org/viewvc?rev=415349view=rev Log: [MSUREFIRE-136] Added option to redirect test output to a file, redirectTestOutputToFile How is this different that useFile=true? Should this new stuff use the same configuration property perhaps? -- Trygve
Re: Docs: remaining questions
comments inline... 1) should we drop the standard reports from the maven site? I would agree with that 'new brand of puppy chow' version of this question...I would keep these generating though to a 'old style' link until something better is all hammered out and in place.. 2) JIRA documentation Can anyone explain what the documentation version is for? my bet is on documentation containing differences for older version of software still in use, api changes and documents detailing those kinda differences... What do others think about merging the documentation categories for now, since we seem to agree this isn't the right breakdown of docs? (I saw a couple of dupes when I surfed across categories, but none within a single one). This gives a more managable task list. +1 3) What is the role of the wiki? Wendy made some very good points about the accessibility of the wiki for getting doc contributions, which I think is worth exploring, especially since we can automatically bring it into the site. However, it comes with the downside that it can be less thoroughly reviewed and sometimes unstructured unless the person is really putting some extra effort in. So I think we have some alternatives: - use the wiki for everything, auto generate site - use the wiki for a specified section of the site, autogenerate (and perhaps mark as being contributed) - use the wiki as a holding area for new doc contributions I'd go with a combo of the last 2. I think the cookbooks section should have 2 parts - an apt/etc part and a contributed part autogenerated from the wiki using Wendy's proposal (and possibly doing the same per plugin) I'm in favour of using APT/local confluence markup for the main, verified part of the site (would want an easy way to convert confluence to APT, though). Thoughts on these? I support the idea of a lot of the content being developed on the wiki and slurped into the main site simply. But this is mildly difficult since we do not want to lock all that process into confluence by any means...so what if we were to have a custom template or something in confluence and mapped a defined page x - site x content mapping, and in that custom template or whatever try and validate that the content saved to the page adhered to a trimmed down set of tags that were simular to apt, or at least we spit out errors and failed the site generation in continuum if the pulling of text over from the confluence didn't match a set of info... basically anything that made the site really easy to make sure that anyone who was working with it followed strict guildlines format wise. would be really nice if we could pull a particular part of a wiki page into the site and then surrounding that there could be comments and whatnot and calls for improvement or what...say if the confluence page of 'Welcome Page' had a table in it with and id of content and in that table was the actual test for the page, and below that brett could add something along the lines of 'todo: spruce up the welcome text so that people know the difference between maven 1.x and latest release of maven. would be cooler still if there where multple tables (or whatever) with ids for content in different translations and we could manage that site content in different language through the same mechanism, all on the same page...and an aggregating page that shows pages of text that were missing translations for a particular language. being able to manage language translations through the wiki would make it easier for people to contribute along those lines then working with properties files and svn/patchs. though if you take into account language translations and whatnot then having the majority if not all of the website in the wiki starts making more sense, perhaps even going so far as to say the plugins could seed the wiki documentation effort automatically for english and then translations based on that being pulled down for website generationdepends on how fully you want to support internationalization. jesse -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] Maven front page, navigation
(adapted from Making the current web site suck less initial proposal,
based on user/dev feedback)
I'm embarrassed to say that the front page looks a whole lot like the
one I created about this time last year for 2.0 alpha 1. I think it
needs an update. IMO, the front page should be:
* an introduction
* how to use the left navigation
* documentation trails
* quick links like the download box
* have news, but not be the primary focus of the page
* above all, brief.
So, something like:
* About Maven
Maven is ... for more info see {features}, {FAQ}, {what is maven}, {why
maven}, etc (but all this in prose.
* Learning about Maven
This site is separated into the following sections:
- {Quick start} information for those needing to build a project that
uses Maven
- {User's Guide} for those wanting to use Maven to build their project,
including a 10 minute test that gives a practical overview of Maven's
main features
- {Plugin Developer's Guide} - for those who may or may not be using
Maven, but want to provide a plugin for shared functionality or to
accompany their own product or toolset
- {Maven Developer's Guide} - for those interested in contributing to
the development of Maven
Each guide is divided into a number of trails to get you started on a
particular topic, and includes a reference area and a cookbook of
common examples.
You can access the guides at any time from the left navigation.
* Plugins
Maven functionality is provided by plugins: See {concept} and {plugin
list(s)}.
* How to get Support
{mailing lists}, {IRC}, {wiki} etc. Send beer.
* News (RHS, under download box).
... blah
Of course, we can spruce this page up with round corners and javascript
if that'll make people happier too :) I'm not tied to any lout here, I
just think these are the elements of it.
For the navigation (headings, * pages, submenus - initially hidden,
(bracketed text) not shown on nav):
Get Maven (maybe not needed if it is on the front page)
* Download
* Release Notes
About Maven
* What is Maven?
* Features
* FAQ -- this is for non-users, not a technical FAQ
* Powered By
* Books and Articles
Documentation
* Quick start
* User's Guide
Concepts (POM, artifacts, lifecycle, repositories, plugins,
conventions, archetypes, multimodule, sites, reports) - each a high
level description with links into guides
Getting Started Guide
Trail 1 (some good trail ideas in John's proposal)
Trail 2
Build Cookbook
Settings Reference
POM Reference
Profiles Reference
* Plugin Developer's Guide
Plugin Concepts
Writing your first Mojo
Mojo API Reference
Plugin Cookbook
...
Maven API Reference
* Available Plugins
By Host (default)
By Category
* Getting Support
... (as on front page)
* Documentation Index
By Category (default)
Alphabetical
IDE Integration
* Eclipse Extension
* Netbeans Module
Developers
* How to Contribute
* Developer's Guide (developer subsite with reports, etc)
Getting Started
...
Maven Repository
* How to upload
* How to partner
* How to mirror
The index is important, as that's how the Maven maven's find their doc
quickly (I need the lifecycle guide), instead of wading through the
trails which are for learning.
I think we should leave breadcrumbs and links to a later topic once this
is nailed down, but agree we should have them.
Final note: once we tackle this the subprojects/apis should get the same
approach (but also be linked to from the main site and considered a
subsite). Some links back to the top level site to maintain hierachy is
required.
I can come up with a strawman index.apt and site.xml tomorrow if folks
would find that helpful. I'm sure once it gets put together it'll need a
lot of tweaking in any regard, but maybe this is a starting point. For
now, sleep :)
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestions for handling native libraries
Hi System.load: - for the user we still need to make some assembly goal that grabs all the shared and jni like libs and puts them in a lib directory. A small setup script can then set the appropriate ld_library_path or the like. - for maven the nar plugin includes an integration test goal, which runs after packaging, and runs as part of maven, so it knows how to set the java.library.path to run the tests. The lava.library.path is set to the produced jni/ so file and all its dependencies. Naming: The artifactID and version are picked up from the standard maven properties file in the jar file. Regards Mark On Jun 19, 2006, at 8:18 AM, Richard van der Hoff wrote: Mark Donszelmann wrote: The NAR gets unpacked in the local repository under the directory where the jar file is stored, so underneath a parent directory with that version number. Ah ha, I see. In that case, how does your System.load() call know where to find the library? I guess it has knowledge of group, artifact, version built into the java jar? And if you have libraries which are linked at the native level, how does the os library loader know where to find the prerequisite libraries? Cheers, 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]
Re: suggestions for handling native libraries
Mark Donszelmann wrote: Hi System.load: - for the user we still need to make some assembly goal that grabs all the shared and jni like libs and puts them in a lib directory. A small setup script can then set the appropriate ld_library_path or the like. - for maven the nar plugin includes an integration test goal, which runs after packaging, and runs as part of maven, so it knows how to set the java.library.path to run the tests. The lava.library.path is set to the produced jni/so file and all its dependencies. I see. Well, this has all been very interesting - thanks Mark! It seems that we've both considered the same set of problems, and come up with slightly different solutions. I only wish I'd heard about this a month ago - I'd much rather have worked with you on the nar plugin than made my own version. I'll watch development of your plugin with interest :). Cheers, 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]
[ANN] Maven Distribution Plugin 1.7 for Maven 1.x released
We are pleased to announce the Maven Distribution Plugin 1.7 release! http://maven.apache.org/maven-1.x/plugins/dist/ === Changes in this version include: New Features: o New property maven.dist.include.dirs to include additional directories. Fixes MPDIST-14. o New property maven.dist.formats to allow creation of only zip or tar.gz archives. Fixes MPDIST-17. o Allow distribution of artifact types other than jar. New property maven.dist.bin.artifact.type, deprecated property maven.dist.bin.artifact. Fixes MPDIST-26. o New property maven.dist.bin.include.site to optionally include the site docs in the binary distribution. Fixes MPDIST-19. o Allow to configure to which files should use CRLF/LF line endings in archives. Fixes MPDIST-27 and MPDIST-28. o Added multiproject analogs mirroring single project goals. Also added the abiltiy to generate combined javadocs for multiproject distribution. However multiproject consolidation might be best put into the site plugin. These fixes are associated with the following JIRA enhancement issue. o Added maven.dist.bin.artifact property. Fixes MPDIST-13. Fixed bugs: o Parent project is not included in source distribution. Fixes MPDIST-11. o build-src goal does not use pom.build.sourceDirectory. Fixes MPDIST-12. o dist:prepare-src-filesystem doesn't recognize maven.ant.generatebuild.file. Fixes MPDIST-24. Changes: o Fix compatibility with the version of ant plugin newer or equal to 1.10. o New maven.dist.src.include property. Fixes MPDIST-15. Thanks to Fabrizio Giustina. o Update dependencies to match ones in maven 1.1 core and to unify them between plugins. The following dependencies are updated : commons-logging v1.0.3 to v1.0.4, maven v1.0 to v1.0.2, maven-model v3.0.0 to v3.0.1 Fixes MAVEN-1712. o It requires at least maven-artifact-plugin v1.7. Notethat this plugin is not compatible with Maven 1.0.2! o Make compatible with Maven 1.1 o Don't generate ant build file, call maven-ant-plugin before or set a preGoal o Add NOTICE file to distribution Removed features: o Removed unused properties: maven.dist.tar.executable and maven.dist.gunzip.executable. Fixes MPDIST-18. === To automatically install the plugin, type the following on a single line: maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://people.apache.org/repository/ -DgroupId=maven -DartifactId=maven-dist-plugin -Dversion=1.7 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-dist-plugin-1.7.jar Have fun! -The Maven Distribution Plugin development team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven XDoc Plugin 1.10 for Maven 1.x released
We are pleased to announce the Maven XDoc Plugin 1.10 release! http://maven.apache.org/maven-1.x/plugins/xdoc/ Convert xdocs into HTML. === Changes in this version include: New Features: o Add a public DTD identifier for xdoc. Fixes MPXDOC-192. o Allow the use of items' attributes 'target' and 'img' for breadcrumbs entries in the navigation file. o New attribute fileSuffix for the tag doc:registerReport allow to use another extension than '.html' for a report link. o Include instructions for ClearCase, Starteam and Perforce access in the scm-usage page. o Include dependencies' scope in dependencies page. Fixes MPXDOC-191. o Include the new theme maven-stylus.css. Fixes MPXDOC-190. o Document the use of pom settings by the xdoc plugin. Fixes MPXDOC-189. o Enable user-defined custom templates. Fixes MPXDOC-183. Thanks to Niall Pemberton. o New goal xdoc:sitemap to generate a sitemap. Fixes MPXDOC-164. o Perform JSL transforms on xdocs onlywhen they have changed. Fixes MPXDOC-141. Thanks to M. Sean Gilligan. o Add xdoc tag library documentation to the plugin site. Fixes MPXDOC-169. o Add support for more powered-by banners. Fixes MPXDOC-126. Thanks to Maarten Coene. o Support global theme. Fixes MPXDOC-80. Thanks to Joerg Schaible. o Add a navigation bar. Fixes MPXDOC-24. Thanks to Gilles Dodinet. o Add an optional id tag to sub/sections, so they can be referenced. Fixes MPXDOC-158. o Add a property to override navigation.xml. Fixes MPXDOC-144. o Show organization in header even if logo not set. Fixes MPXDOC-127. Thanks to Shinobu Kawai Yoshida. Fixed bugs: o Fix xml entities in xdoc source files (only in Maven 1.1 because of a bug in an old Jelly version). Fixes MPXDOC-17. o Add i18n support for links and breadcrumbs. Fixes MPXDOC-194. o Display the external link icon only if the link host is different from the project url (pom.url). o CVS usage page is blank when using Subversion. Fixes MPXDOC-130. o Fix broken maven.xdoc.date=navigation-top and navigation-bottom. Fixes MPXDOC-185. o Correct cvs checkout instructions on cvs-usage page. Fixes MPXDOC-187. o Url and timezone not used for contributor. Fixes MPXDOC-125. Thanks to Shinobu Kawai Yoshida. o Mailing list links break if the address starts with http. Fixes MPXDOC-186. o Internationalized sites have no images. Fixes MPXDOC-177. o maven.ui.navcol.width has no effect. Fixes MPXDOC-178. Thanks to Phil Steitz. o When there's no user provided documentation, some generated docs don't get copied to site. Fixes MPXDOC-176. o Menus with type=header are not processed by site.jsl. Fixes MPXDOC-175. Thanks to Phil Steitz. o Unclear error message when currentVersion/ in project.xml file not defined. Fixes MPXDOC-174. o Fix xdoc:validate. Fixes MPXDOC-87. o One cannot call xdoc:copy-user-resources directly. Fixes MPXDOC-106. Thanks to Jerome Lacoste. o Ampersands in navigation.xml being escaped twice. Fixes MPXDOC-47. o Ampersand in section/subsection not correct. Fixes MPXDOC-133. o Downloads report cannot be disabled for child projects. Fixes MPXDOC-104. Thanks to Rafal Krzewski. Changes: o The 'Development Process' menu link now leads to an internal page. Fixes MPXDOC-170. o Replace the deprecated xmlParserAPIs by xml-apis 1.3.03. Fixes MAVEN-1753. o An image can be used in the menu entry for a report. o Item name is always displayed even if img attribute is setted. In the navigation file the new attribute 'hideName' can be used to hide the name in the link (if you want to display only the image for example). o In breadcrumbs, use for the project's name nav.title if defined, pom.name otherwise. o The name of the cvs-usage page has changed to scm-usage.html. If you have a link directly to this page, you will have to update it. o Update dependencies to match ones in maven 1.1 core and to unify them between plugins. The following dependencies are updated : commons-jelly v1.0-RC1 - v1.0 commons-logging v1.0.3 - v1.0.4 maven-model v3.0.0 - v3.0.1 Fixes MAVEN-1712. === To automatically install the plugin, type the following on a single line: maven plugin:download -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://people.apache.org/repository/ -DgroupId=maven -DartifactId=maven-xdoc-plugin -Dversion=1.10 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-xdoc-plugin-1.10.jar Have fun! -The Maven XDoc Plugin development team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Eclipse Plugin 1.11 for Maven 1.x Released
The maven team is pleased to announce the Maven Eclipse Plugin 1.11 release! http://maven.apache.org/maven-1.x/plugins/eclipse/ A plugin to generate various files for the Eclipse IDE and ease the use of Maven within that environment. Changes in this version include: New Features: o Added new property maven.eclipse.project.name. Issue: MPECLIPSE-84. o Now trying to download java sources archives from the remote repositories. Issue: MPECLIPSE-60. Fixed bugs: o Made output and testOutput directory configuration consistent. Issue: MPECLIPSE-111. To automatically install the plugin, type the following on a single line: maven plugin:download -DgroupId=maven -DartifactId=maven-eclipse-plugin -Dversion=1.11 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-eclipse-plugin-1.11.jar Have fun! -The maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven War Plugin 1.6.2 for Maven 1.x Released
The maven team is pleased to announce the Maven WAR Plugin 1.6.2 release! http://maven.apache.org/maven-1.x/plugins/war/ War Plugin for Maven Changes in this version include: New Features: o Aded the ability to customize the Class-Path entry of the manifest Issue: MPWAR-43. o Added property maven.war.webxml.overwriteto control if the source web.xml overwrite the one in the generated webapp directory. Issue: MPWAR-52. Fixed bugs: o Manifest file is now generated properly. Issue: MPWAR-58. o Fixed confusing documentation regarding maven.war.classes.includes and excludes properties Issue: MPWAR-29. o License file is now added properly to the generated war Issue: MPWAR-32. o Remove reference to unused caller tag library to suppress warning Changes: o Added property maven.war.resources.overwriteto control is resources overwrites the ones in the generated webapp directory. Issue: MPWAR-49. o Added ability to expand properties when copying war resources. Issue: MPWAR-37. Thanks to Troy Poppe. o Updated wrong documentation regarding web.xml filtering. Issue: MPWAR-39. o Now filtering when copying resources. Issue: MPWAR-46. o Add support for EJB client code. Issue: MPWAR-50. To automatically install the plugin, type the following on a single line: maven plugin:download -DgroupId=maven -DartifactId=maven-war-plugin -Dversion=1.6.2 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-war-plugin-1.6.2.jar Have fun! -The maven team - 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 dev@maven.apache.org 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: [Proposal] Documenting Maven
Hi Jason and List, The last result was on the mavenuser wiki. I can also found some paper notes i wrote some month ago. If you are interrested, i could rewrote what i had. Raphaël 2006/6/19, Jason van Zyl [EMAIL PROTECTED]: On 19 Jun 06, at 8:37 AM 19 Jun 06, Brett Porter wrote: Do we really think there are any ideas that haven't been encountered in all these messages? Absolutely. If 10 people make a site I guarantee you something will fall out that hasn't been seen. If users don't want to help in this regard then they get whatever we come up with which would be unfortunate. I will post something to the users list asking for a list of favorite sites and example Maven sites. 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? Jason. - Brett - 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]
Please sync ...
the following directories on people.apache.org: /www/www.apache.org/dist/maven-repository/org/apache/ws/commons/ws-commons-java5/ /www/www.apache.org/dist/maven-repository/org/apache/ws/commons/ws-commons-util/ Thank you, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Docs: remaining questions
comments inline. Cheers, john 1) should we drop the standard reports from the maven site? I never was really pushing to drop reports altogether; it just didn't really make sense to me to have them on the main site, in addition to the individual reference pages. IMO, until we can aggregate all of those reports for the entirety of Maven, it's confusing what they represent. Also, it clutters up the main site for users who might not have any use for that information. 2) JIRA documentation Can anyone explain what the documentation version is for? The documentation version in JIRA was my feeble attempt to find another grouping for documentation-related issues. At the time, I didn't know issues could have more than one component association, and I wanted to get a handle on how documentation was coming without destroying the association of what it was trying to document. What do others think about merging the documentation categories for now, since we seem to agree this isn't the right breakdown of docs? (I saw a couple of dupes when I surfed across categories, but none within a single one). This gives a more managable task list. +1. 3) What is the role of the wiki? Wendy made some very good points about the accessibility of the wiki for getting doc contributions, which I think is worth exploring, especially since we can automatically bring it into the site. I think the wiki is the best candidate for making some of the conversations taking place on the users list and IRC more permanent. It's a fast way for users to start helping users, without people like me serving as a bottleneck. As for quality, I think that can also be driven by the user community to some extent, and shepherded by us. However, it comes with the downside that it can be less thoroughly reviewed and sometimes unstructured unless the person is really putting some extra effort in. I would expect that a certain amount of social pressure would eventually drive the wiki documentation to become and stay fairly accurate, if not in alignment with best practices. As for formatting, I'd love to see some sort of way we could offer a template for framing an example...something that would make one document look a bit like the others, to make it easier to pull out information. Standards will be hard to enforce, unless there is a clear benefit to the community, IMO. But something like the loose organization on the different pages linked from http://www.linux-laptop.netshould be good enough... So I think we have some alternatives: - use the wiki for everything, auto generate site Do you mean that we'd keep all of our static site documentation on there as well, and render everything from confluence markup? This seems a bit drastic. - use the wiki for a specified section of the site, autogenerate (and perhaps mark as being contributed) - use the wiki as a holding area for new doc contributions I'm not sure I understand. Why bother rendering any of the wiki content as static pages? This will only slow down user contributions in terms of revisions to existing docs, which will in some ways compromise their quality. I'd prefer to see a combination of static site pages and wiki, where the static site might refer to a corresponding wiki section for any given discussion. So, the assembly plugin might have the bare-minimum official docs, which include basic usage, the plugin report, etc. and a _link_ to the wiki area for the assembly plugin. In this area of the wiki, users can add their own examples, workarounds, etc. The only drawbacks I can see here are in keeping the wiki information up to date with new releases, and navigational consistency between wiki and the main site. I really don't see much value in rendering the wiki content to static pages, particularly when we'll have to implement in Doxia the confluence macro-set we'll need to represent a technical discussion...things like the code macro. I'd go with a combo of the last 2. I think the cookbooks section should have 2 parts - an apt/etc part and a contributed part autogenerated from the wiki using Wendy's proposal (and possibly doing the same per plugin) I'm in favour of using APT/local confluence markup for the main, verified part of the site (would want an easy way to convert confluence to APT, though). Thoughts on these? I support the idea of a lot of the content being developed on the wiki and slurped into the main site simply. But this is mildly difficult since we do not want to lock all that process into confluence by any means...so what if we were to have a custom template or something in confluence and mapped a defined page x - site x content mapping, and in that custom template or whatever try and validate that the content saved to the page adhered to a trimmed down set of tags that were simular to apt, or at least we spit out errors and failed the site generation in continuum if the pulling of text over from the
Re: Please sync ...
done On 6/19/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: the following directories on people.apache.org: /www/www.apache.org/dist/maven-repository/org/apache/ws/commons/ws-commons-java5/ /www/www.apache.org/dist/maven-repository/org/apache/ws/commons/ws-commons-util/ Thank you, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Maven front page, navigation
+1
2006/6/19, Brett Porter [EMAIL PROTECTED]:
(adapted from Making the current web site suck less initial proposal,
based on user/dev feedback)
I'm embarrassed to say that the front page looks a whole lot like the
one I created about this time last year for 2.0 alpha 1. I think it
needs an update. IMO, the front page should be:
* an introduction
* how to use the left navigation
* documentation trails
* quick links like the download box
* have news, but not be the primary focus of the page
* above all, brief.
So, something like:
* About Maven
Maven is ... for more info see {features}, {FAQ}, {what is maven}, {why
maven}, etc (but all this in prose.
* Learning about Maven
This site is separated into the following sections:
- {Quick start} information for those needing to build a project that
uses Maven
- {User's Guide} for those wanting to use Maven to build their project,
including a 10 minute test that gives a practical overview of Maven's
main features
- {Plugin Developer's Guide} - for those who may or may not be using
Maven, but want to provide a plugin for shared functionality or to
accompany their own product or toolset
- {Maven Developer's Guide} - for those interested in contributing to
the development of Maven
Each guide is divided into a number of trails to get you started on a
particular topic, and includes a reference area and a cookbook of
common examples.
You can access the guides at any time from the left navigation.
* Plugins
Maven functionality is provided by plugins: See {concept} and {plugin
list(s)}.
* How to get Support
{mailing lists}, {IRC}, {wiki} etc. Send beer.
* News (RHS, under download box).
... blah
Of course, we can spruce this page up with round corners and javascript
if that'll make people happier too :) I'm not tied to any lout here, I
just think these are the elements of it.
For the navigation (headings, * pages, submenus - initially hidden,
(bracketed text) not shown on nav):
Get Maven (maybe not needed if it is on the front page)
* Download
* Release Notes
About Maven
* What is Maven?
* Features
* FAQ -- this is for non-users, not a technical FAQ
* Powered By
* Books and Articles
Documentation
* Quick start
* User's Guide
Concepts (POM, artifacts, lifecycle, repositories, plugins,
conventions, archetypes, multimodule, sites, reports) - each a high
level description with links into guides
Getting Started Guide
Trail 1 (some good trail ideas in John's proposal)
Trail 2
Build Cookbook
Settings Reference
POM Reference
Profiles Reference
* Plugin Developer's Guide
Plugin Concepts
Writing your first Mojo
Mojo API Reference
Plugin Cookbook
...
Maven API Reference
* Available Plugins
By Host (default)
By Category
* Getting Support
... (as on front page)
* Documentation Index
By Category (default)
Alphabetical
IDE Integration
* Eclipse Extension
* Netbeans Module
Developers
* How to Contribute
* Developer's Guide (developer subsite with reports, etc)
Getting Started
...
Maven Repository
* How to upload
* How to partner
* How to mirror
The index is important, as that's how the Maven maven's find their doc
quickly (I need the lifecycle guide), instead of wading through the
trails which are for learning.
I think we should leave breadcrumbs and links to a later topic once this
is nailed down, but agree we should have them.
Final note: once we tackle this the subprojects/apis should get the same
approach (but also be linked to from the main site and considered a
subsite). Some links back to the top level site to maintain hierachy is
required.
I can come up with a strawman index.apt and site.xml tomorrow if folks
would find that helpful. I'm sure once it gets put together it'll need a
lot of tweaking in any regard, but maybe this is a starting point. For
now, sleep :)
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Docs: remaining questions
On 20/06/2006 7:19 AM, John Casey wrote: 1) should we drop the standard reports from the maven site? I never was really pushing to drop reports altogether; it just didn't really make sense to me to have them on the main site, in addition to the individual reference pages. IMO, until we can aggregate all of those reports for the entirety of Maven, it's confusing what they represent. Also, it clutters up the main site for users who might not have any use for that information. When I say standard information, I mean standard - just project-info-reports (mailing list, etc). Is that what you mean? There aren't others on the site. The only drawbacks I can see here are in keeping the wiki information up to date with new releases, and navigational consistency between wiki and the main site. I really don't see much value in rendering the wiki content to static pages, particularly when we'll have to implement in Doxia the confluence macro-set we'll need to represent a technical discussion...things like the code macro. The reason to render it into the site is for consistency (navigation and appearance), and speed. There shouldn't be any bottleneck as we can run this automatically every hour or something. Other sites are already doing this: http://incubator.apache.org/activemq/ - 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]
