You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2014/09/10 12:01:18 UTC
Re: [ALL] Auto generating README.md and CONTRIBUTING.md for github
using the commons build plugin
Hello Bernd,
I'm back from Portual and will try to have a look at your comments this
week :-)
Thanks!
Benedikt
2014-08-31 23:20 GMT+02:00 Bernd Eckenfels <ec...@zusammenkunft.net>:
> Hello Benedikt,
>
> I finally had some time to look at this. I tried to integrate it into
> VFS. I did not (yet) change the commpons-parent, I instead used the
> direct call method:
>
> mvn org.apache.commons:commons-build-plugin:1.5-SNAPSHOT:readme-md
>
> I dont think this affects the result substantially, but who knows.
>
> https://github.com/ecki/commons-vfs/tree/draft-readme
>
> Anyway, the things I noticed:
>
> - with VFS beeing a module build where the toplevel is the vfs-project
> parent, the generated description for the maven artifact might be the
> wrong one. Is there a plan/option to specify a specific module as the
> main deliverable?
>
> - in the generated README.md is some html comments about the template
> system. It talks about "mail-list-template.xml", I guess its a C&P
> error?
>
> - i do like that github is featured, but I wonder if this is true for
> all commons projects as the prefered way to contribute? Or is this
> only because you expect README.md to be visible mostly on Github?
>
> - the files have been generated with native (windows) CRLF line endings,
> is that intentional?
>
> - most links relative to project do not work as they use
> commons-vfs2-project instead of commons-vfs. Do I need to set a
> property or should the mojo use a different one?
>
> - is there suggested javadoc location intended for future use, i.e.
> should we change the site build of vfs2?
>
> - I wonder can the link from README.md to CONTRIBUTING.md be relative,
> it somehow has the svn trunk in there.
>
> - for the JIRA link, i think we hava a property for the JIRA project
> (for the changes report), that can be added to the JIRA URL to be
> more specific?
>
> - I would suggest to name the test command "mvn clean verify" instead
> of "clean test" to make sure ITs are executed (if present).
>
> - i wonder if it should not work recursive, the CONTRIBUTING/README in
> core and examples might not be needed (of course I can skip to commit
> them).
>
> Gruss
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [ALL] Auto generating README.md and CONTRIBUTING.md for github
using the commons build plugin
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello Benedikt,
thanks for the feedback, no worries, take your time.
I already fixed the below mentioned wrong template-comments.
For the project id/url related stuff I did not take a deeper look as it
is I guess moslty getting familiar with the commons-parent structure.
However let me know if I should dig deeper and help.
Maybe we should check all commons projects which are affected, if VFS
is the only outlier I guess we can manually fix it up as well (after
all even the site of VFS does not get it right atm).
Gruss
Bernd
Am Wed, 10 Sep 2014 12:01:18 +0200
schrieb Benedikt Ritter <br...@apache.org>:
> Hello Bernd,
>
> I'm back from Portual and will try to have a look at your comments
> this week :-)
>
> Thanks!
> Benedikt
>
> 2014-08-31 23:20 GMT+02:00 Bernd Eckenfels <ec...@zusammenkunft.net>:
>
> > Hello Benedikt,
> >
> > I finally had some time to look at this. I tried to integrate it
> > into VFS. I did not (yet) change the commpons-parent, I instead
> > used the direct call method:
> >
> > mvn org.apache.commons:commons-build-plugin:1.5-SNAPSHOT:readme-md
> >
> > I dont think this affects the result substantially, but who knows.
> >
> > https://github.com/ecki/commons-vfs/tree/draft-readme
> >
> > Anyway, the things I noticed:
> >
> > - with VFS beeing a module build where the toplevel is the
> > vfs-project parent, the generated description for the maven
> > artifact might be the wrong one. Is there a plan/option to specify
> > a specific module as the main deliverable?
> >
> > - in the generated README.md is some html comments about the
> > template system. It talks about "mail-list-template.xml", I guess
> > its a C&P error?
> >
> > - i do like that github is featured, but I wonder if this is true
> > for all commons projects as the prefered way to contribute? Or is
> > this only because you expect README.md to be visible mostly on
> > Github?
> >
> > - the files have been generated with native (windows) CRLF line
> > endings, is that intentional?
> >
> > - most links relative to project do not work as they use
> > commons-vfs2-project instead of commons-vfs. Do I need to set a
> > property or should the mojo use a different one?
> >
> > - is there suggested javadoc location intended for future use, i.e.
> > should we change the site build of vfs2?
> >
> > - I wonder can the link from README.md to CONTRIBUTING.md be
> > relative, it somehow has the svn trunk in there.
> >
> > - for the JIRA link, i think we hava a property for the JIRA project
> > (for the changes report), that can be added to the JIRA URL to be
> > more specific?
> >
> > - I would suggest to name the test command "mvn clean verify"
> > instead of "clean test" to make sure ITs are executed (if present).
> >
> > - i wonder if it should not work recursive, the CONTRIBUTING/README
> > in core and examples might not be needed (of course I can skip to
> > commit them).
> >
> > Gruss
> > Bernd
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org