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 > <url> > and associated <deploymentManagement><site> 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 <url> and > <site> > 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]
