Maybe a bit late in the game, but still:
In face of the fact, that we are already looking at a multi module project:
Having all the examples within a dedicated module added into the
hierarchy would allow us, to have it all, and still without burdening
the RM:
- keeping the examples current by compiling and executing/testing them
during releases
- maintaining arbitrary links from other modules sites/javadoc into the
site generated by the examples
- we may still avoid to distribute some of their artifacts, especially
the binaries, by simply excluding them from install/deploy/release
steps, which could done by properly configuring the
install/deploy/release plugins within the examples pom. It shouldn't
even be necessary, to have a profile for that.
Just my 2 cents.
The only thing, that might be of interest is the question, whether as
part of the process, the examples module should produce and release kind
of a source artifact, containing the *complete* source (with pom,
src/main/** etc), or if we point the users simply to the version
control URL, where they might check it out.
Regards,
Thomas
On 09.08.2021 13:22, Matt Juntunen wrote:
Advertising
the examples at a higher level in the project site is better, so adding
them to the user guide is an appropriate place. The question then is should
the higher location point the user to the module site index, recommend
downloading the source release which contains all the examples (and not
having the module site published), or both.
I would say both.
I do not think pushing the artifacts to Maven Central is useful
+1. I think we're all agreed on this point.
-Matt J
On Sun, Aug 8, 2021 at 5:38 PM Alex Herbert <alex.d.herb...@gmail.com> wrote:
On Fri, 6 Aug 2021 at 04:01, Gilles Sadowski <gillese...@gmail.com> wrote:
Le ven. 6 août 2021 à 04:01, Matt Juntunen <matt.a.juntu...@gmail.com> a
écrit :
Gilles,
I do _not_ ask any work to be done in order to complicate the release
process and/or review.
My question was (cf. above and the other thread) whether singling out
the "examples" module has any benefit (apart from saving a few bytes
on Maven Central).
Yes, I believe it is beneficial. If nothing else, it keeps maven
central and the project site uncluttered and reduces the chance of
user confusion.
I do not see where the problem is supposed to be (with Maven Central).
But, either way, it's not worth fighting over it, as long as the examples
are kept in sync with the code (and this is done at the lastest as part
of the current release process). [The counter-example is "Commons
Math", where the code examples were not kept up to date with the
main code...]
For the site, I believe that the examples should be there, as they are
show-cases (for users!) of fully-working applications.[1]
I do not think that the layout of the site for maven modules is very
friendly for browsing the source. You are required to traverse down the
hierarchy to the module site index, then click the project reports link
then either the javadoc or xref reports. It takes a lot of finding and may
not be found at all by a new user of the modular site layout. Advertising
the examples at a higher level in the project site is better, so adding
them to the user guide is an appropriate place. The question then is should
the higher location point the user to the module site index, recommend
downloading the source release which contains all the examples (and not
having the module site published), or both.
I do not think pushing the artifacts to Maven Central is useful as the
applications are either developer testing tools or integration test demos.
These are not of use to be linked by a third party as a dependency, and
given they have no binary compatibility guarantee it would be unwise to
depend on them anyway.
Gilles
[1] See e.g.
https://commons.apache.org/proper/commons-rng/commons-rng-examples/commons-rng-examples-quadrature/xref/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
