Hi, [removed Apache Infra, because it no longer concerns them, but added maven-dev]
I didn't really understand the "small library" comment. Is that a comment about commons-email needing that information or did I get it wrong? It is not just commons-email. I only noticed the problem on commons-email. But I'm sure, many people imported CVS trees into Subversion and having _less_ information in my sites after doing a conversion is not really a good thing to have. As I wrote some times before, I do have a number of issues with the changelog plugin: What I would _love_ to see (especially in the light of being able to reproduce a site build at a given time) is the ability to define a point in time which is used for generating the changelog. Or a tag. But a fixed point in time. So I can do (example, does not work): maven.changelog.type = date maven.changelog.lastdate = 2005-09-29 maven.changelog.range = 30 and that would produce the changelog of 30 days up to 2005-09-29. No matter on which date I ran the changelog generation command. Same would be great for tags: maven.changelog.type=tag maven.changelog.tag=RELEASE_1_0 maven.changelog.range=30 The frustrating thing here is, that most of this is already in place but does not work as I would expect: There is the ability to give a changelog relative to a tag but only _after_ that tag. If you want to build a site documenting a release, you want to have information _up to_ that tag. There is range but it is not used if type is tag. The current changelog generation is highly volatile because it considers the "state of now()" as a part of the information which is used to generate the changelog. This means that potentially no two changelog generations are the same. And one can't reproduce a changelog, because you can't go back in time. Even though there is a change log type "date", it does not really help you because it sets the _START_ date, not the _END_ date of the change log. But unless you do build a site related to a current development tree and not to a released (i.e. fixed in time) version, setting the start date is not really interesting. Because for a release, I want to know "how did I get to this point in time/code". For a development tree, I want to know "How did I get to now() when I started at <date>/<tag>?". As a side point: For subversion, where you have unified revision numbers and atomic commits, the ability to use a tag would be cool(because according to the http://maven.apache.org/reference/plugins/changelog/properties.html page this works only for CVS anyway) but the ability to specify a revision number (because in Subversion, tags are just 'named revisions') would be even more useful. On Wed, 2005-09-28 at 07:35 +1000, Brett Porter wrote: > Someone has recently posted a workaround (patch) in Maven's JIRA. It > gets all revisions for the repository and then only puts any in the last > 30 days in the report. A bit too brute force for general use, but it'll > work if you need it for a small library. I don't think that you can do it any other way. This is a subversion shortcoming, not a changelog plugin. If you try to use date range checking and subversion does not deliver all the log information, you must pull everything and pick. Unless you have a really, really long changelog, that shouldn't really be a problem. Best regards Henning > > - Brett > > Henning Schmiedehausen wrote: > > >Hi, > > > >ah, thanks, didn't know about that FAQ. Doesn't help me with my problems > >as the change logs are maven driven, though. :-) > > > > Best regards > > Henning > > > > > > > > -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering 4 - 8 - 15 - 16 - 23 - 42 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
