Re: Publishing Plugin Sites (was: Re: Plugins sandbox site)
Wendy Smoak wrote: On 10/4/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: From: Wendy Smoak [mailto:[EMAIL PROTECTED] There is now (in v9) some config in the plugin parent for staging sites under maven-whatever-plugin-x.y-SNAPSHOT and I would like to get that trend started for plugin docs. Or at least see if there are objections and we need to talk about it more. Here's what it looks like: plugins/maven-whatever-plugin <-- latest release plugins/maven-whatever-plugin-1.1.6 <-- archived release docs plugins/maven-whatever-plugin-1.2.3 <-- latest release, for archives plugins/maven-whatever-plugin-1.2.4-SNAPSHOT How does it move a site from the latest release to an archived one? Are you doing some rewrite rules or something? This is not currently in place, so it's not happening at all yet. :) I'd say we just publish to the staging area from the tag when the release vote is called (for review) and then do a normal 'mvn site-deploy' to the un-versioned/latest url once the vote passes (when you merge the staging repo artifacts). It could be done with symlinks on the server or rewrite rules in .htaccess also-- of the two I'd prefer .htaccess because it can be kept in svn. (It's also very easy to break the site with a typo. Not that I'd know...) The implementation doesn't matter too much to me, people who have been doing plugin releases probably have a better idea of the easiest way to do it. Wendy, I agree that having versioned deployments of plugins docs. If we go down this road, we could simply have the unversioned url (eg plugins/maven-whatever-plugin) point to the versioned deployment, rather than redeploying. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Publishing Plugin Sites (was: Re: Plugins sandbox site)
On 10/4/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: > From: Wendy Smoak [mailto:[EMAIL PROTECTED] >> There is now (in v9) some config in the plugin parent for staging >> sites under maven-whatever-plugin-x.y-SNAPSHOT and I would like to get >> that trend started for plugin docs. >> >> Or at least see if there are objections and we need to talk about it >> more. Here's what it looks like: >> >> plugins/maven-whatever-plugin <-- latest release >> plugins/maven-whatever-plugin-1.1.6 <-- archived release docs >> plugins/maven-whatever-plugin-1.2.3 <-- latest release, for archives >> plugins/maven-whatever-plugin-1.2.4-SNAPSHOT > How does it move a site from the latest release to an archived one? Are > you doing some rewrite rules or something? This is not currently in place, so it's not happening at all yet. :) I'd say we just publish to the staging area from the tag when the release vote is called (for review) and then do a normal 'mvn site-deploy' to the un-versioned/latest url once the vote passes (when you merge the staging repo artifacts). It could be done with symlinks on the server or rewrite rules in .htaccess also-- of the two I'd prefer .htaccess because it can be kept in svn. (It's also very easy to break the site with a typo. Not that I'd know...) The implementation doesn't matter too much to me, people who have been doing plugin releases probably have a better idea of the easiest way to do it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
I'd like having the version number added. I don't usually know (or keep track of) when something gets released. And it's not always obvious that I'm reading a new feature... and we don't want to stop eager people in contributing documentation ALONG with their code patches right? :-) On 12/8/06, Stephane Nicoll <[EMAIL PROTECTED]> wrote: On 12/8/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > Just a reminder and in case it needs more discussion: we are now > publishing the latest plugin docs from svn, and not waiting for a > release to do it. Can't we add the version of the plugin matching the status of the documentation? Even if we have @since tags, it would be better to clearly state the documentation is for version X.Y-SNAPSHOT. WDYT? Stéphane PS: Personnaly I forgot to add those tags to the EAR plugin and I am probably not the only one. Will fix it ASAP. > > Here's a link to the beginning of this thread, in case anyone missed > it the first time around: > >http://www.nabble.com/Publishing-plugin-sites-t2584348.html > > Thanks, > -- > Wendy > > - > 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: Publishing plugin sites
I don't think a "normal" maven user would bother with the version of the plugin. Putting in the version of the plugin may give the user a bit too much information. However, putting the version would help the users who are using the latest features ( and are checking whether the features they want are in the plugins they are using ). Thus, a reference to indicate the version which those features are available is still necessary. I guess the @since tag on the goal parameters are enough, and a few side notes on the examples and usage section ( depending on what is presented ). Besides, if the user starts using those features, they would find out about those in the said sections, thus, the version where those features are available should be placed there as well ( making sure that the info is presented only when it is needed ). ...btw, the version of the plugin can be seen from the project-summary section. but it's not visible to common users. just my 2 cents worth. - Franz On 12/17/06, Brett Porter <[EMAIL PROTECTED]> wrote: Late response, but probably worth answering... I generally like this idea (and it is the default behaviour, I think) - but I think it would be too constrictive to most users. Is that a fair analysis? - Brett On 08/11/2006, at 7:54 AM, John Allen wrote: > This maybe moot but this reminds me of something that bothered me a > while > back: > > The problem here is the lack of project identity (group id, > artifact id, > version) support in sites. A site is simply a view upon a project > and yet > there is no way for us to reflect which version that site was > generated from > while still employing maven's auto-URL generation scheme (i.e. > automatic > inheritance based generation of URLs). One can manually specify the > > and associated details for each > project but > that is lame and error prone. Consider all those nice links in the > dependencies report, they should be linking to specific versions of > those > depended-upon projects, but without a lot of manual effort they are > going to > point to the 'latest' site for that dependency. > > I think we should have the same rigor in the site address space > (URLs) as is > employed in the repository address space. This would allow for > automatic > generation of version accurate sites (i.e. we would be able to > preserve the > 'old' sites). > > Historically 'site' may have been thought of as just a quick way > for an open > source project to produce an external facing web site and such a > 'proper' > addressing scheme would result in URLs such as: > > http://www.my-opensource.org/i/am/the/group/i-am-the-artifact-id/ > and-im-the- > version/index.html > > But that's easily handled with simple web server mapping > techniques. Alt > (and preferably) just create some good old fashioned web pages as > the front > door and then link to the maven generated content from there. > > Just my 0.02 worth > > Ps. We do intend visiting the core sometime soon to extend the current > scheme to support full POM identity representation in the and > > schemes. I'll post patches if/when its sorted. > > John > > -Original Message- > From: Franz Allan Valencia See [mailto:[EMAIL PROTECTED] > Sent: 07 November 2006 13:26 > To: Maven Developers List > Subject: Re: Publishing plugin sites > > On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: >>> >>> Also, maybe the @since tags should be documented as well in [1]? >> >> Yes, but isn't this also included in the Maven site somewhere? >> > > hhmm..never seen it in maven2 site. but i've seen some goals > documentation in maven-1.x with the 'since' column. > > - Franz > > - > 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: Publishing plugin sites
Late response, but probably worth answering... I generally like this idea (and it is the default behaviour, I think) - but I think it would be too constrictive to most users. Is that a fair analysis? - Brett On 08/11/2006, at 7:54 AM, John Allen wrote: This maybe moot but this reminds me of something that bothered me a while back: The problem here is the lack of project identity (group id, artifact id, version) support in sites. A site is simply a view upon a project and yet there is no way for us to reflect which version that site was generated from while still employing maven's auto-URL generation scheme (i.e. automatic inheritance based generation of URLs). One can manually specify the and associated details for each project but that is lame and error prone. Consider all those nice links in the dependencies report, they should be linking to specific versions of those depended-upon projects, but without a lot of manual effort they are going to point to the 'latest' site for that dependency. I think we should have the same rigor in the site address space (URLs) as is employed in the repository address space. This would allow for automatic generation of version accurate sites (i.e. we would be able to preserve the 'old' sites). Historically 'site' may have been thought of as just a quick way for an open source project to produce an external facing web site and such a 'proper' addressing scheme would result in URLs such as: http://www.my-opensource.org/i/am/the/group/i-am-the-artifact-id/ and-im-the- version/index.html But that's easily handled with simple web server mapping techniques. Alt (and preferably) just create some good old fashioned web pages as the front door and then link to the maven generated content from there. Just my 0.02 worth Ps. We do intend visiting the core sometime soon to extend the current scheme to support full POM identity representation in the and schemes. I'll post patches if/when its sorted. John -Original Message- From: Franz Allan Valencia See [mailto:[EMAIL PROTECTED] Sent: 07 November 2006 13:26 To: Maven Developers List Subject: Re: Publishing plugin sites On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: Also, maybe the @since tags should be documented as well in [1]? Yes, but isn't this also included in the Maven site somewhere? hhmm..never seen it in maven2 site. but i've seen some goals documentation in maven-1.x with the 'since' column. - Franz - 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: Publishing plugin sites
On 12/8/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: Just a reminder and in case it needs more discussion: we are now publishing the latest plugin docs from svn, and not waiting for a release to do it. Can't we add the version of the plugin matching the status of the documentation? Even if we have @since tags, it would be better to clearly state the documentation is for version X.Y-SNAPSHOT. WDYT? Stéphane PS: Personnaly I forgot to add those tags to the EAR plugin and I am probably not the only one. Will fix it ASAP. Here's a link to the beginning of this thread, in case anyone missed it the first time around: http://www.nabble.com/Publishing-plugin-sites-t2584348.html Thanks, -- Wendy - 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: Publishing plugin sites
On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: Well, its up for discussion. I don't like the idea of having separate docs per release, since some aspects of docs are updated independent of version. So, we added the @since flag to mojos and parameters so that you have an accurate reference for all versions. WRT the docs on the site, it's just going to mean documenting version compatibility as you go if you discuss something that has been added in later versions. Just a reminder and in case it needs more discussion: we are now publishing the latest plugin docs from svn, and not waiting for a release to do it. Here's a link to the beginning of this thread, in case anyone missed it the first time around: http://www.nabble.com/Publishing-plugin-sites-t2584348.html Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 11/8/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: Can someone look at maven-plugin-plugin? I changed its parent to 4-SNAPSHOT locally to get the upload to work, but the header on the site is wrong. http://maven.apache.org/plugins/maven-plugin-plugin/ Done: http://jira.codehaus.org/browse/MPLUGIN-25 - Franz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 11/8/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: One this to think about now is what we should do with old files on the plugin sites. ... Should such files be manually deleted from minotaur, to avoid confusion for the users? Yes, otherwise they'll keep showing up in web searches. Do we need to put up .htaccess files to redirect user to an appropriate new page? If so where do we put these files? If we can avoid broken links, we should. There is already a top level site/trunk/src/site/resources/.htaccess file, but I could be convinced that it makes sense to do it at the plugin level. Does anyone have a preference? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
Wendy Smoak wrote: On 11/8/06, Vincent Siveton <[EMAIL PROTECTED]> wrote: It seems that some plugins have not been published yet: compiler, eclipse, help, jxr, one Sorry, I must have missed some errors scanning the log file. I needed to build a few things in shared to get them to work, but now those four are published. So, *most* of the plugin sites are published, let me know if you see any others missing, and anyone who updates a plugin site should feel free to 'mvn site-deploy' it. Not yet published: antrun, archetype, site The antrun plugin won't build for me, it's looking for 'maven-invoker-plugin' which I can't find anywhere. The site plugin needs Maven 2.1-SNAPSHOT. (Anyone who's using 2.1 is welcome to type 'mvn site-deploy' to publish that one.) I've done maven-site-plugin. One this to think about now is what we should do with old files on the plugin sites. Take the site plugin as an example. The old version of the site has (at least) 2 files that are not part of the new version of the site: /plugins/maven-site-plugin/ /creating-a-skin.html (moved to the examples directory) /howto.html (replaced by usage.html) Should such files be manually deleted from minotaur, to avoid confusion for the users? Do we need to put up .htaccess files to redirect user to an appropriate new page? If so where do we put these files? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 11/8/06, Vincent Siveton <[EMAIL PROTECTED]> wrote: It seems that some plugins have not been published yet: compiler, eclipse, help, jxr, one Sorry, I must have missed some errors scanning the log file. I needed to build a few things in shared to get them to work, but now those four are published. So, *most* of the plugin sites are published, let me know if you see any others missing, and anyone who updates a plugin site should feel free to 'mvn site-deploy' it. Not yet published: antrun, archetype, site The antrun plugin won't build for me, it's looking for 'maven-invoker-plugin' which I can't find anywhere. The site plugin needs Maven 2.1-SNAPSHOT. (Anyone who's using 2.1 is welcome to type 'mvn site-deploy' to publish that one.) I'm not sure what happened with archetype, I'll try that one again later. Can someone look at maven-plugin-plugin? I changed its parent to 4-SNAPSHOT locally to get the upload to work, but the header on the site is wrong. http://maven.apache.org/plugins/maven-plugin-plugin/ Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
It seems that some plugins have not been published yet: compiler, eclipse, help, jxr, one Cheers, Vincent 2006/11/8, Vincent Siveton <[EMAIL PROTECTED]>: Thanks a lot Wendy for this! Vincent 2006/11/8, Wendy Smoak <[EMAIL PROTECTED]>: > On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > > Since we still have the problem of circular dependencies in there > > (plugins use the javadoc and other reports, so it can't figure out > > the right order to build), you can't use the parent to run from, but > > you can probably do: > > mvn -r '*/pom.xml' site-deploy > > or > > for i in */pom.xml; do mvn -f $i site-deploy; done > > Thanks! The sites are published, except for > > maven-antrun-plugin, which won't build because it can't find > maven-invoker-plugin > > maven-site-plugin, which requires Maven 2.1-SNAPSHOT > > Also, maven-plugin-plugin needs its parent changed to 4-SNAPSHOT, > unless it's like that for a reason. I had trouble with the upload, > version 3 must have minotaur.a.o instead of people.a.o in distribution > management. > > -- > Wendy > > - > 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: Publishing plugin sites
Thanks a lot Wendy for this! Vincent 2006/11/8, Wendy Smoak <[EMAIL PROTECTED]>: On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: > Since we still have the problem of circular dependencies in there > (plugins use the javadoc and other reports, so it can't figure out > the right order to build), you can't use the parent to run from, but > you can probably do: > mvn -r '*/pom.xml' site-deploy > or > for i in */pom.xml; do mvn -f $i site-deploy; done Thanks! The sites are published, except for maven-antrun-plugin, which won't build because it can't find maven-invoker-plugin maven-site-plugin, which requires Maven 2.1-SNAPSHOT Also, maven-plugin-plugin needs its parent changed to 4-SNAPSHOT, unless it's like that for a reason. I had trouble with the upload, version 3 must have minotaur.a.o instead of people.a.o in distribution management. -- Wendy - 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: Publishing plugin sites
On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: Since we still have the problem of circular dependencies in there (plugins use the javadoc and other reports, so it can't figure out the right order to build), you can't use the parent to run from, but you can probably do: mvn -r '*/pom.xml' site-deploy or for i in */pom.xml; do mvn -f $i site-deploy; done Thanks! The sites are published, except for maven-antrun-plugin, which won't build because it can't find maven-invoker-plugin maven-site-plugin, which requires Maven 2.1-SNAPSHOT Also, maven-plugin-plugin needs its parent changed to 4-SNAPSHOT, unless it's like that for a reason. I had trouble with the upload, version 3 must have minotaur.a.o instead of people.a.o in distribution management. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 08/11/2006, at 11:27 AM, Wendy Smoak wrote: On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: I think the addition of new documentation outweighs the problems we'll see from snapshot features, but we should mark them up as we [see] them. I agree. So, who would like to do do the honors and publish the updated plugin sites? I'm happy to do it, if no one objects. Technically, having the 'maven' unix group on minotaur is enough to let any committer publish the entire Maven site, but there are social boundaries. :) Go for it! Since we still have the problem of circular dependencies in there (plugins use the javadoc and other reports, so it can't figure out the right order to build), you can't use the parent to run from, but you can probably do: mvn -r '*/pom.xml' site-deploy or for i in */pom.xml; do mvn -f $i site-deploy; done (Or, can we get Continuum to publish sites along with snapshots?) Even better, but a second step :) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: I think the addition of new documentation outweighs the problems we'll see from snapshot features, but we should mark them up as we [see] them. I agree. So, who would like to do do the honors and publish the updated plugin sites? I'm happy to do it, if no one objects. Technically, having the 'maven' unix group on minotaur is enough to let any committer publish the entire Maven site, but there are social boundaries. :) (Or, can we get Continuum to publish sites along with snapshots?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Publishing plugin sites
This maybe moot but this reminds me of something that bothered me a while back: The problem here is the lack of project identity (group id, artifact id, version) support in sites. A site is simply a view upon a project and yet there is no way for us to reflect which version that site was generated from while still employing maven's auto-URL generation scheme (i.e. automatic inheritance based generation of URLs). One can manually specify the and associated details for each project but that is lame and error prone. Consider all those nice links in the dependencies report, they should be linking to specific versions of those depended-upon projects, but without a lot of manual effort they are going to point to the 'latest' site for that dependency. I think we should have the same rigor in the site address space (URLs) as is employed in the repository address space. This would allow for automatic generation of version accurate sites (i.e. we would be able to preserve the 'old' sites). Historically 'site' may have been thought of as just a quick way for an open source project to produce an external facing web site and such a 'proper' addressing scheme would result in URLs such as: http://www.my-opensource.org/i/am/the/group/i-am-the-artifact-id/and-im-the- version/index.html But that's easily handled with simple web server mapping techniques. Alt (and preferably) just create some good old fashioned web pages as the front door and then link to the maven generated content from there. Just my 0.02 worth Ps. We do intend visiting the core sometime soon to extend the current scheme to support full POM identity representation in the and schemes. I'll post patches if/when its sorted. John -Original Message- From: Franz Allan Valencia See [mailto:[EMAIL PROTECTED] Sent: 07 November 2006 13:26 To: Maven Developers List Subject: Re: Publishing plugin sites On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > Also, maybe the @since tags should be documented as well in [1]? > > Yes, but isn't this also included in the Maven site somewhere? > hhmm..never seen it in maven2 site. but i've seen some goals documentation in maven-1.x with the 'since' column. - Franz - 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: Publishing plugin sites
On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > Also, maybe the @since tags should be documented as well in [1]? Yes, but isn't this also included in the Maven site somewhere? hhmm..never seen it in maven2 site. but i've seen some goals documentation in maven-1.x with the 'since' column. - Franz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 07/11/2006, at 4:50 PM, Franz Allan Valencia See wrote: So the priority now for the maven plugins docs is to mark them up with @since tags? If im not mistaken, most (if not all) of those docs do not have the since tags. It should only be necessary as new features are added. And if we're going to apply those @since tags to just the mojos, goals, and javadocs. What about the usage and examples? That's going to need to be explained inline where needed. Also, maybe the @since tags should be documented as well in [1]? Yes, but isn't this also included in the Maven site somewhere? True, but I guess we need those @since tags first...or in the meantime, at least a note at their intro pages stating something like "This doc was intended for the current snapshot version and may not be applicable to the currently released version. For more information" I think the addition of new documentation outweighs the problems we'll see from snapshot features, but we should mark them up as we seem them. And speaking of getting the users involved, maybe a visible feedback page, or a link to the "how to contirbute" page would be nice, and maybe even a link to that plugin's wiki page so that users can share their info such as cookbook recipes :-) (which can later be incorporated in the docs) I think these are a good idea, but I'd look to set this up in a structured fashion rather than manually adding it to every plugin if we can. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: On 07/11/2006, at 3:33 PM, Wendy Smoak wrote: > On 11/6/06, Franz Allan Valencia See <[EMAIL PROTECTED]> wrote: > >> I don't think the new plugin docus can be published yet until the >> plugins themselves are released. Those docus were based on the >> snapshot versions and some information they contain may not be >> applicable to the currently released versions. > > As I understand it, a 'since' attribute was introduced so that we can > identify the version in which new features will appear. That means we > can go ahead and publish now, users will understand that if they're > using 1.1.3, something marked 'since 1.1.4' will not exist. This does depend on people marking that up. I think at this point we are better off correcting the issues of not marking it up than missing the docs that are there. I'm willing to contribute again to the plugin docs but just a few clarifications: So the priority now for the maven plugins docs is to mark them up with @since tags? If im not mistaken, most (if not all) of those docs do not have the since tags. And if we're going to apply those @since tags to just the mojos, goals, and javadocs. What about the usage and examples? Also, maybe the @since tags should be documented as well in [1]? > > Waiting until the next release to publish docs isn't working. There's > too much good stuff sitting in svn, invisible, and it does nothing to > encourage contributions since it may be weeks or months before you > ever see your work "in print". Agreed. True, but I guess we need those @since tags first...or in the meantime, at least a note at their intro pages stating something like "This doc was intended for the current snapshot version and may not be applicable to the currently released version. For more information" And speaking of getting the users involved, maybe a visible feedback page, or a link to the "how to contirbute" page would be nice, and maybe even a link to that plugin's wiki page so that users can share their info such as cookbook recipes :-) (which can later be incorporated in the docs) WDYT? Cheers, Franz [1] http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 07/11/2006, at 3:33 PM, Wendy Smoak wrote: On 11/6/06, Franz Allan Valencia See <[EMAIL PROTECTED]> wrote: I don't think the new plugin docus can be published yet until the plugins themselves are released. Those docus were based on the snapshot versions and some information they contain may not be applicable to the currently released versions. As I understand it, a 'since' attribute was introduced so that we can identify the version in which new features will appear. That means we can go ahead and publish now, users will understand that if they're using 1.1.3, something marked 'since 1.1.4' will not exist. This does depend on people marking that up. I think at this point we are better off correcting the issues of not marking it up than missing the docs that are there. Waiting until the next release to publish docs isn't working. There's too much good stuff sitting in svn, invisible, and it does nothing to encourage contributions since it may be weeks or months before you ever see your work "in print". Agreed. -- Wendy - 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: Publishing plugin sites
On 11/6/06, Franz Allan Valencia See <[EMAIL PROTECTED]> wrote: I don't think the new plugin docus can be published yet until the plugins themselves are released. Those docus were based on the snapshot versions and some information they contain may not be applicable to the currently released versions. As I understand it, a 'since' attribute was introduced so that we can identify the version in which new features will appear. That means we can go ahead and publish now, users will understand that if they're using 1.1.3, something marked 'since 1.1.4' will not exist. Waiting until the next release to publish docs isn't working. There's too much good stuff sitting in svn, invisible, and it does nothing to encourage contributions since it may be weeks or months before you ever see your work "in print". -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 11/6/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 11/6/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Please, let's all help to keep this list up to date, until all plugin > sites have been published. Brett posted earlier that he fixed the navigation inheritance problem. Is there anything else preventing us from publishing all of the plugin sites, now? -- Wendy Good day, I don't think the new plugin docus can be published yet until the plugins themselves are released. Those docus were based on the snapshot versions and some information they contain may not be applicable to the currently released versions. Cheers, Franz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 11/6/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Please, let's all help to keep this list up to date, until all plugin sites have been published. Brett posted earlier that he fixed the navigation inheritance problem. Is there anything else preventing us from publishing all of the plugin sites, now? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
On 11/6/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Dennis Lundberg wrote: > Wendy Smoak wrote: >> Are all the plugin websites up to date with svn, or is the policy >> still to only publish them when a release is done? >> >> Thanks, > > The published plugin sites are unfortunately not in sync with what is in > svn. The published docs should reflect the current release of the > plugin. Therefor we need to release the plugins to reap the benefits of > the improved documentation. > > We should keep track of which plugin sites have been published after the > documentation make-over. I'll add a new column for this at: > http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation Done. Please, let's all help to keep this list up to date, until all plugin sites have been published. -- Dennis Lundberg Good day, Aside from the following plugins: * maven-changelog-plugin * maven-changes-plugin * maven-docck-plugin * maven-jar-plugin the following have already been published: * maven-clean-plugin * maven-clover-plugin * maven-surefire-plugin * maven-war-plugin * maven-javadoc-plugin Btw, the maven-jar-plugin's site may need republishing since it's index.html does not reflect its src/site/index.apt. Furthermore, the following docs have not yet been published (aside from maven-one-plugin): * maven-ant-plugin * maven-antlr-plugin * maven-antrun-plugin * maven-archetype-plugin * maven-assembly-plugin * maven-compiler-plugin * maven-dependency-plugin * maven-deploy-plugin * maven-ear-plugin * maven-ejb-plugin * maven-eclipse-plugin * maven-help-plugin * maven-idea-plugin * maven-install-plugin * maven-jxr-plugin * maven-one-plugin * maven-plugin-plugin * maven-project-info-reports-plugin * maven-rar-plugin * maven-release-plugin * maven-resources-plugin * maven-site-plugin * maven-surefire-report-plugin * maven-verifier-plugin Cheers, Franz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
Dennis Lundberg wrote: Wendy Smoak wrote: Are all the plugin websites up to date with svn, or is the policy still to only publish them when a release is done? Thanks, The published plugin sites are unfortunately not in sync with what is in svn. The published docs should reflect the current release of the plugin. Therefor we need to release the plugins to reap the benefits of the improved documentation. We should keep track of which plugin sites have been published after the documentation make-over. I'll add a new column for this at: http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation Done. Please, let's all help to keep this list up to date, until all plugin sites have been published. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
Well, its up for discussion. I don't like the idea of having separate docs per release, since some aspects of docs are updated independent of version. So, we added the @since flag to mojos and parameters so that you have an accurate reference for all versions. WRT the docs on the site, it's just going to mean documenting version compatibility as you go if you discuss something that has been added in later versions. I don't believe the xref/javadoc/reporting is really relevant for plugins so that shouldn't be a concern (though javadoc will make use of @since too) - do others agree? On 07/11/2006, at 6:48 AM, Wendy Smoak wrote: On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: They are currently at releases. We are now in a position (with @since), to publish all the time, and I've lined them all up, but it is currently blocked by a bug in the navigation link generation. So is the plan to keep all the plugin sites up to date with svn, once the navigation works? I've heard more than one person say that the published docs should exactly match the releases. Do we need to version the plugin docs, as we do with /ref/current -> /ref/2.0.4 and /ref/2.0.5-SNAPSHOT for the Maven core? -- Wendy - 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: Publishing plugin sites
On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: They are currently at releases. We are now in a position (with @since), to publish all the time, and I've lined them all up, but it is currently blocked by a bug in the navigation link generation. So is the plan to keep all the plugin sites up to date with svn, once the navigation works? I've heard more than one person say that the published docs should exactly match the releases. Do we need to version the plugin docs, as we do with /ref/current -> /ref/2.0.4 and /ref/2.0.5-SNAPSHOT for the Maven core? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
They are currently at releases. We are now in a position (with @since), to publish all the time, and I've lined them all up, but it is currently blocked by a bug in the navigation link generation. On 07/11/2006, at 6:00 AM, Wendy Smoak wrote: Are all the plugin websites up to date with svn, or is the policy still to only publish them when a release is done? Thanks, -- Wendy - 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: Publishing plugin sites
Is it possible to use versioning on the site? So you can select the site/documentation for a specific version of the plugin? For instance: http://ws.apache.org/jaxme/, on the left there's Documentation per version. Something like that would be nice for the plugins. -- Kenney Dennis Lundberg wrote: Wendy Smoak wrote: Are all the plugin websites up to date with svn, or is the policy still to only publish them when a release is done? Thanks, The published plugin sites are unfortunately not in sync with what is in svn. The published docs should reflect the current release of the plugin. Therefor we need to release the plugins to reap the benefits of the improved documentation. We should keep track of which plugin sites have been published after the documentation make-over. I'll add a new column for this at: http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
Wendy Smoak wrote: Are all the plugin websites up to date with svn, or is the policy still to only publish them when a release is done? Thanks, The published plugin sites are unfortunately not in sync with what is in svn. The published docs should reflect the current release of the plugin. Therefor we need to release the plugins to reap the benefits of the improved documentation. We should keep track of which plugin sites have been published after the documentation make-over. I'll add a new column for this at: http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Publishing plugin sites
Are all the plugin websites up to date with svn, or is the policy still to only publish them when a release is done? Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
