On Wed, Jun 28, 2023 at 6:17 AM Gary Gregory <garydgreg...@gmail.com> wrote:
> Hi All and Phil.
>
> Thank you for the thoughtful reply, Phil.
>
> The main driver here was two combine keeping binary compatibility
> _and_ benefit call sites of the API by _not_ having to catch Exception
> or throw Exception, which clearly is an anti-pattern. Instead, call
> sites should deal with domain exceptions, which they can in turn
> handle. IOW, when I am using IO resources or JDBC resources, I should
> expect to handle IOException and JDBCException, not Exception, so by
> extension (more on this below), I would expect to handle the same
> kinds of exceptions when I am pooling those kinds of resources.
>
I think I understand. I am not sure I agree, but I get what you are trying
to do. My problem is doing it in a minor release. I believe you when you
say that this is "OK" by Commons standards, but breaking source
compatibility in a low-level, widely used component like [pool] is not very
nice to our users, IMO. The "domain exceptions" that I understanding your
liking for need to be invented (or hopefully as in your examples, found as
standard exceptions) and code needs to be modified in lots of places
(unless there is some magic I don't know about, which is entirely possible)
in order to compile code that directly uses the new version. I
respectfully suggest that it would be much better to hold this for a major
release. This is also something that should be discussed as we are doing
now. I don't see any discussion other than in the JIRA / PRs.
>
> The idea to convert APIs from throwing exceptions from checked to
> unchecked seems like a larger design and philosophical change than
> typing those exceptions with generics, so I stayed away from that.
>
I get that and agree. I am not sure it is the best way to go, honestly;
but here again, I see it as a 3.0 discussion.
> Note that changing APIs from checked to unchecked could be made in 2.x
> _and_ still preserve binary compatibility, just like this RC maintains
> binary compatibility.
>
Again, I am not sure binary compat is worth that much for library code that
is directly used by so many components (such as DBCP).
>
> I think it is worth talking about what a 3.0 would look like as it
> would inform how to get there in the best way, and then come back to
> talking about this RC. A question for a future 3.0 would be whether
> APIs should throw checked or unchecked exceptions. I think we can
> safely dismiss any argument as to whether APIs should throw exceptions
> or not, without discussion; Pool APIs throw exceptions, period, just
> like any API. As I pointed out above, changing exceptions from checked
> to unchecked does _not_ break binary compatibility, only source
> compatibility, so strictly speaking, we don't have to create a major
> release just for that change. Clearly, a 3.0 would take advantage of
> removing all deprecated APIs.
>
> Question: If we were to design Pool from scratch today, would we
> create APIs with checked or unchecked exceptions?
>
I would ask you that :)
I am serious. I don't honestly feel qualified to answer that question
other than for my own apps. I think getting broad-based feedback somehow
would be best on this and I honestly trust you more than me to make this
call. I will note that we currently throw one unchecked exception - NSE -
with great frequency and the admittedly loose and maybe "anti-pattern"-ish
approach in signatures makes that "OK." (That was the point of one of my
probably garbled examples below. Changing borrowObject to advertise a
checked "FooException" makes it look like if you catch that you catch
failures; but you don't - you will still get NSE in many cases.) The de
facto contract with borrowObject and several other pool methods is that all
manner of checked and unchecked exceptions may be propagated from either
the pool itself or the factories being used. We could do a better job
documenting the ones we throw ourselves but users need to understand what
their factories are going to throw and the cases (almost always) where the
pool propagates rather than swallows / logs. I am not defending this
setup, but as a user I have never found it that difficult and I have never
really minded the ugliness. Again, I admit that I am way less concerned
about this kind of thing than most and I understand the desire to make
things cleaner. But as I keep saying, I really think this is a 3.0
discussion.
>
> The only popular API I know of today that uses unchecked exceptions is
> JPA (like Hibernate). I've used Hibernate _a lot_, and my experience
> there is that just like any API, you eventually have to catch some
> exception somewhere and handle it. With unchecked exceptions, that
> coding decision shows up when you go through a _second_ round of
> compiling and running your sources. IOW, (TTD or not) you write a
> combination of test and main code, run it, and start iterating tests
> and main code, and now you have to deal with _unexpected_ unchecked
> exceptions, unless you've read the Javadoc and/or sources for all the
> APIs you're calling, and then wrote _correct_ code. With checked
> exceptions, you're forced to make that exception handing decision
> upfront or your code won't compile. It's a different experience for
> users of the API. I'm not judging it either way, it's just different.
>
I agree with this.
>
> Question: What's the experience we want to give Pool users, the people
> who write calls to the API?
>
Make it as easy as possible to safely use the component. More generic type
parameters == more cognitive load which to me means makes it harder to
use. But I can anticipate the response to this - crazy "throws Exception"
makes me have to shoehorn my domain exception hierarchy in somehow == more
cognitive load. I am not sure which is right, but I know that every time I
go to use a library, I want to spend as little time as possible
understanding its way of looking at things. Overall, the pool API is not
bad at that, but we may be able to make it easier in some ways and I am
big +1 for that. The other big thing I keep hammering on is that as a user
I absolutely don't want to be surprised by build breaks in minor releases.
Major releases, I know I may have to tweak some things / think a bit about
the new way the component thinks about the world. And I can decide if I
want to go there. Minor release, to get bug fixes I just want to drop it
in, build, and have it work.
>
> I'm not sold 100% on either approach. I consider Pool a mid-level API,
> as opposed to a low-level API. Calling a low-level API, I am OK
> handling/propagating checked exceptions. I see Pool as a
> semi-transparent proxy to the actual API/Objects being pooled, so I am
> OK with checked exceptions coming out of Pool just like I am OK with
> checked exceptions coming from a file or database API. My point here
> is that changing to unchecked API feels to me like raising the
> abstraction level of the API. It would mean that we pool and transform
> exceptions from checked to unchecked (or, leave them unchecked, or
> wrap unchecked domain APIs with Pool unchecked APIs).
>
> What do people think? Is the future checked or unchecked? As is Java
> taking on developer-friendly features ("var" for example, and
> unfriendly, hello JPMS), are checked exceptions just getting in the
> way? Are checked exceptions a step too far in a statically typed
> language?
>
> I did not get the points Phil is trying to make in his examples, I'm
> not sure they are valid. OTOH, the unit tests do show using the APIs
> typed with different types of exceptions. Sure, there might be
> adjustments to make, but I don't see the flaws you seem to think are
> there. WRT to source changes, I welcome cleaning up my call sites!
The problem is you are asking *many* users to be welcoming of this task,
which I do not think should happen in a minor release.
The
> debate is valid and I hope we have interesting replies to this thread.
>
> Thank you for reading all of this!
>
Thank you for explaining, Gary.
Phil
> Gary
>
> On Mon, Jun 26, 2023 at 7:44 PM Phil Steitz <phil.ste...@gmail.com> wrote:
> >
> > Looking more carefully at the extent of impact, I am -1 (non-binding) on
> > this change. I understand what you are trying to do, but a) I don't see
> > that the solution actually does it (see comments by Michael in PR) and b)
> > it is going to create a lot of pain for users who have to modify
> factories,
> > etc. when in fact many / most of them throw unchecked if any
> exceptions. I
> > would be +1 for removing the throws entirely in 3.0. It does not make
> > sense to me to have a "generic" checked exception type assigned at the
> pool
> > level. What the different factory and pool methods throw may be
> > different. Even after your change, for example, borrowObject throws
> NSE.
> > You are changing the signature to make it look like if you catch "E"
> > whatever that is, it will not go bang. But it will if you have replaced
> > "Exception" with a checked exception class. You are just replacing
> > "Exception" with something that looks "cleaner" but is not. Clients will
> > either have to ignore it and just instantiate with "Exception" or create
> a
> > gratuitous "FooException" to root a hierarchy of their own making (and
> > separately catch the NSEs) when in fact what they throw now are standard
> > exceptions. Remember pool is very widely used so you are asking *many*
> > developers to spend time making changes that many will consider a waste
> of
> > time. Is the idea that they all just parameterize with "Exception"? Can
> > IDEs do that automatically for them? Please let's get some input from
> > downstream users before surprising them with this.
> >
> > Phil
> >
> > On Mon, Jun 26, 2023 at 3:55 PM Phil Steitz <phil.ste...@gmail.com>
> wrote:
> >
> > >
> > >
> > > On Mon, Jun 26, 2023 at 3:43 PM Gary Gregory <garydgreg...@gmail.com>
> > > wrote:
> > >
> > >> Hi Phil,
> > >>
> > >> YW and thank you for the review.
> > >>
> > >> Yes, you are right that this is about POOL-269. While binary
> compatibility
> > >> is preserved 100%, source compatibility is not. This is one of those
> rare
> > >> cases where you can't make an omelette without breaking some eggs ;-)
> > >> Since
> > >> binary compatibility is preserved, I don't think this is worth going
> to a
> > >> new major release.
> > >>
> > >
> > > We should definitely add a *loud* statement in the release notes then
> and
> > > directions for how to work around because I am sure a lot of downstream
> > > builds will fail due to this as DBCP did. Is there no way that we can
> > > somehow keep the source compatability? Pool is widely used and a lot
> of
> > > builds will break IIUC what is going on here.
> > >
> > > Phil
> > >
> > >>
> > >> I have POOL projects that will benefit (greatly IMO) from cleaner
> > >> exception
> > >> handling and avoid having to throw/propagate Exception or
> catch/rethrow
> > >> Exception as a domain Exception, and will now instead be able to use
> > >> domain
> > >> specific exception for resources being pooled from the get go.
> > >>
> > >> I'll obviously adjust DBCP for this as soon as possible (IOW,
> > >> post-release).
> > >>
> > >> For the other items, I will try and reproduce. My tests builds were
> ok on
> > >> Windows 10 and macOS latest with Java 8. Maybe by hardware is too
> slow or
> > >> too fast compared to yours, hard to say.
> > >>
> > >> Gary
> > >>
> > >> On Mon, Jun 26, 2023, 16:53 Phil Steitz <phil.ste...@gmail.com>
> wrote:
> > >>
> > >> > Hi Gary, First, thanks for doing this. There are a lot of good
> fixes in
> > >> > here.
> > >> >
> > >> > I checked the build, sigs et al on a couple of platforms and did not
> > >> > find anything major except one item. I will start with the
> > >> > show-stopper (IMO) and then the other smaller things.
> > >> >
> > >> > 1. I get compilation failure when I try to compile the latest DBCP
> > >> > release with this code. I think it may have something to do with
> > >> > POOL-269. Here is one example:
> > >> >
> > >> > [*ERROR*]
> > >> >
> > >>
> /Users/psteitz/Downloads/commons-dbcp2-2.9.0-src/src/main/java/org/apache/commons/dbcp2/PoolableConnectionFactory.java:[45,70]
> > >> > wrong number of type arguments; required 2
> > >> >
> > >> > This should not happen in a dot release.
> > >> >
> > >> > 2. On MacOS 13.4.1, OpenJDK 20.0.1, I got the following test failure
> > >> > just one time and can't reproduce:
> > >> >
> > >> > java.util.concurrent.ExecutionException:
> > >> > java.lang.NullPointerException: Cannot invoke
> > >> >
> > >> >
> > >>
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
> > >> > because the return value of "java.util.Map.get(Object)" is null
> > >> >
> > >> > at
> > >> >
> java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> > >> > at
> > >> > java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> > >> > at
> > >> >
> > >>
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$2(TestGenericKeyedObjectPool.java:1056)
> > >> > ... 71 more
> > >> > Caused by: java.lang.NullPointerException: Cannot invoke
> > >> >
> > >> >
> > >>
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
> > >> > because the return value of "java.util.Map.get(Object)" is null
> > >> > at
> > >> >
> > >>
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.addIdleObject(GenericKeyedObjectPool.java:307)
> > >> > at
> > >> >
> > >>
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.addObject(GenericKeyedObjectPool.java:332)
> > >> > at
> > >> >
> > >>
> org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:136)
> > >> > at
> > >> >
> > >>
> org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:113)
> > >> > at
> > >> >
> > >>
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$0(TestGenericKeyedObjectPool.java:1036)
> > >> > at
> > >> >
> > >>
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> > >> > at
> > >> > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> > >> > at
> > >> >
> > >>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> > >> > at
> > >> >
> > >>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> > >> > at java.base/java.lang.Thread.run(Thread.java:1623)
> > >> >
> > >> > This one is driving me crazy because the NPE should not be possible
> > >> > due to key registration guarding. I will keep digging on this.
> > >> >
> > >> > 3.
> > >> >
> > >> > I see this one on every run, both config above and Ubuntu 20.0.4 /
> > >> > OpenJDK 11.0.19
> > >> >
> > >> > Exception in thread "Thread-1305"
> org.opentest4j.AssertionFailedError
> > >> >
> > >> > at
> > >> > org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:34)
> > >> >
> > >> > at
> org.junit.jupiter.api.Assertions.fail(Assertions.java:116)
> > >> >
> > >> > at
> > >> >
> > >>
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testClearUnblocksWaiters$3(TestGenericKeyedObjectPool.java:1237)
> > >> >
> > >> > at java.base/java.lang.Thread.run(Thread.java:1623)
> > >> >
> > >> > The test that causes it doesn't fail because it happens in a thread
> > >> > that the test spawns and the test does not wait for the threads it
> > >> > starts to finish. Digging into it, I realize this is my sloppiness
> as
> > >> > I committed this test case. I will make a PR to fix it. I don't
> > >> > think that it indicates a bug.
> > >> >
> > >> > 4. I forgot to add since tag on the new version of GKOP clear that
> > >> > adds reuseCapacity parm. Will fix in the same PR.
> > >> >
> > >> > 5. Small nit. There is a vestigal paragraph in the release notes
> > >> > template that I think should be dropped:
> > >> >
> > >> >
> > >> > No client code changes are required to migrate from versions 2.0-2.3
> > >> > to version 2.4.3.
> > >> >
> > >> > Users of version 1.x should consult the migration guide on the
> Commons
> > >> > Pool web site.
> > >> >
> > >> > Phil
> > >> >
> > >> > On Sat, Jun 24, 2023 at 6:27 PM Gary Gregory <
> garydgreg...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > We have fixed quite a few bugs and added some enhancements since
> > >> > > Apache Commons Pool 2.11.1 was released, so I would like to
> release
> > >> > > Apache Commons Pool 2.12.0.
> > >> > >
> > >> > > Apache Commons Pool 2.12.0 RC1 is available for review here:
> > >> > >
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC1
> > >> > > (svn revision 62626)
> > >> > >
> > >> > > The Git tag commons-pool-2.12.0-RC1 commit for this RC is
> > >> > > e5dae53e0ce1211b40680e7dccf601c3c3897378 which you can browse
> here:
> > >> > >
> > >> > >
> > >> >
> > >>
> https://gitbox.apache.org/repos/asf?p=commons-pool.git;a=commit;h=e5dae53e0ce1211b40680e7dccf601c3c3897378
> > >> > > You may checkout this tag using:
> > >> > > git clone
> https://gitbox.apache.org/repos/asf/commons-pool.git
> > >> > > --branch <
> > >> https://gitbox.apache.org/repos/asf/commons-pool.git--branch>
> > >> > > commons-pool-2.12.0-RC1 commons-pool-2.12.0-RC1
> > >> > >
> > >> > > Maven artifacts are here:
> > >> > >
> > >> > >
> > >> >
> > >>
> https://repository.apache.org/content/repositories/orgapachecommons-1640/org/apache/commons/commons-pool2/2.12.0/
> > >> > >
> > >> > > These are the artifacts and their hashes:
> > >> > >
> > >> > > #Release SHA-512s
> > >> > > #Sat Jun 24 21:12:18 EDT 2023
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-bin.tar.gz=e16b3a81c98feae6f9855a9bd2f2226dae51558c6e7bb77ee626e58853420ccc59d0943a594bba27ab7147524eca823cac47484e304ebaf14bd724b96bbffc25
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-bin.zip=29339f89a8efaa4ad3efbe656d610b8951be1a2a005ba7cb58ae356660331af9d473e8ada8bcdedd3d765c54d1dcfee8779ccb3902f0220de7e92e3039f95b8d
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-bom.json=adb3e197d360dc7f53ab116c8fa8b1699d60560fcf977cae613c4cb493168a130ca8041d4ca475e75386f281688819fa5f5111e4aa937b24390a6de8e779f507
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-bom.xml=d964e9ec5ed51c10591093bdd0e174f8eb354a447f710e8c3749100fdbda7456e3922846a7190180e5044fe46e571cbc600aaea1b8f64a37c12c5deaa2f1662a
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-javadoc.jar=356891b25f2e0367b74a7c4070c26d3cec7a3e608b6e47205e5ffeface590c9717187cb1fa72ebb4c484adaac2c7634ff1944c88282ba9c6551ab5abb58c87f4
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-sources.jar=6d955b437496d7af6f94844010a1df15efc04e2b9c15fadc1001777c54a60433570744605b0625a21adf53f03ce9e339809977384c562ad357a98370749c8ee6
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-src.tar.gz=eed0575d8357349c908fe8539db2c8ef23234c306f373d203d3d2d9a4ee1ae51cb6bdb2f86163e2296ac90f67a27c7d8cfde239cdfc8ab4966c6239b63f5984e
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-src.zip=d8158fd14ee393a99dd0abcb55448b699182a50e0ea114cd3a2681799c9f5e58161f71a2420d0605d1ea39efb08c31be1f7a38531c169fd2c69cc604458ee184
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-test-sources.jar=db4fabab1fae77e5dcf8af35397635738c6296ebc25065be9a73725d6b837179c3973ae3ea531aa40056459f011ff90e3c2ef16ad2fa77114dacaa5709e3bf57
> > >> > >
> > >> > >
> > >> >
> > >>
> commons-pool2-2.12.0-tests.jar=81af180ba6d2a5ce12064c9cc4eda4bc25d072fef55a3dc7ce48506571d40aceb6636c80202c31eff867eb8fd1971a44e0c2c2979019a1e32f43005d70cf2f5e
> > >> > >
> > >> > >
> > >> >
> > >>
> org.apache.commons_commons-pool2-2.12.0.spdx.json=ed49a8ca7a776ede454f8765f1bd71b5d6a2da35b8bd46ebe930f663127fbd6f248c27059b417ca578665295113ca56a0f0e6486c92436b7b9af7984e3f111db
> > >> > >
> > >> > > I have tested this with:
> > >> > >
> > >> > > mvn -V -Duser.name=$my_apache_id
> > >> > > -Dcommons.release-plugin.version=$commons_release_plugin_version
> > >> > > -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
> > >> > >
> > >> > > using:
> > >> > >
> > >> > > Apache Maven 3.9.2 (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
> > >> > > Maven home: /usr/local/Cellar/maven/3.9.2/libexec
> > >> > > Java version: 1.8.0_372, vendor: Homebrew, runtime:
> > >> > > /usr/local/Cellar/openjdk@8
> > >> > > /1.8.0+372/libexec/openjdk.jdk/Contents/Home/jre
> > >> > > Default locale: en_US, platform encoding: UTF-8
> > >> > > OS name: "mac os x", version: "13.4.1", arch: "x86_64", family:
> "mac"
> > >> > > Darwin gdg-mac-mini.local 22.5.0 Darwin Kernel Version 22.5.0:
> Thu Jun
> > >> > > 8 22:22:22 PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64 x86_64
> > >> > >
> > >> > > Details of changes since 2.11.1 are in the release notes:
> > >> > >
> > >> > >
> > >> >
> > >>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC1/RELEASE-NOTES.txt
> > >> > >
> > >> > >
> > >> >
> > >>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC1/site/changes-report.html
> > >> > >
> > >> > > Site:
> > >> > >
> > >> > >
> > >> >
> > >>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC1/site/index.html
> > >> > > (note some *relative* links are broken and the 2.12.0
> directories
> > >> > > are not yet created - these will be OK once the site is deployed.)
> > >> > >
> > >> > > JApiCmp Report (compared to 2.11.1):
> > >> > >
> > >> > >
> > >> >
> > >>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC1/site/japicmp.html
> > >> > >
> > >> > > RAT Report:
> > >> > >
> > >> > >
> > >> >
> > >>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC1/site/rat-report.html
> > >> > >
> > >> > > KEYS:
> > >> > > https://www.apache.org/dist/commons/KEYS
> > >> > >
> > >> > > Please review the release candidate and vote.
> > >> > > This vote will close no sooner than 72 hours from now.
> > >> > >
> > >> > > [ ] +1 Release these artifacts
> > >> > > [ ] +0 OK, but...
> > >> > > [ ] -0 OK, but really should fix...
> > >> > > [ ] -1 I oppose this release because...
> > >> > >
> > >> > > Thank you,
> > >> > >
> > >> > > Gary Gregory,
> > >> > > Release Manager (using key 86fdc7e2a11262cb)
> > >> > >
> > >> > > For following is intended as a helper and refresher for reviewers.
> > >> > >
> > >> > > Validating a release candidate
> > >> > > ==============================
> > >> > >
> > >> > > These guidelines are NOT complete.
> > >> > >
> > >> > > Requirements: Git, Java, Maven.
> > >> > >
> > >> > > You can validate a release from a release candidate (RC) tag as
> > >> follows.
> > >> > >
> > >> > > 1) Clone and checkout the RC tag
> > >> > >
> > >> > > git clone https://gitbox.apache.org/repos/asf/commons-pool.git
> > >> > > --branch commons-pool-2.12.0-RC1 commons-pool-2.12.0-RC1
> > >> > > cd commons-pool-2.12.0-RC1
> > >> > >
> > >> > > 2) Check Apache licenses
> > >> > >
> > >> > > This step is not required if the site includes a RAT report page
> which
> > >> > > you then must check.
> > >> > >
> > >> > > mvn apache-rat:check
> > >> > >
> > >> > > 3) Check binary compatibility
> > >> > >
> > >> > > Older components still use Apache Clirr:
> > >> > >
> > >> > > This step is not required if the site includes a Clirr report page
> > >> > > which you then must check.
> > >> > >
> > >> > > mvn clirr:check
> > >> > >
> > >> > > Newer components use JApiCmp with the japicmp Maven Profile:
> > >> > >
> > >> > > This step is not required if the site includes a JApiCmp report
> page
> > >> > > which you then must check.
> > >> > >
> > >> > > mvn install -DskipTests -P japicmp japicmp:cmp
> > >> > >
> > >> > > 4) Build the package
> > >> > >
> > >> > > mvn -V clean package
> > >> > >
> > >> > > You can record the Maven and Java version produced by -V in your
> VOTE
> > >> > > reply.
> > >> > > To gather OS information from a command line:
> > >> > > Windows: ver
> > >> > > Linux: uname -a
> > >> > >
> > >> > > 5) Build the site for a single module project
> > >> > >
> > >> > > Note: Some plugins require the components to be installed instead
> of
> > >> > > packaged.
> > >> > >
> > >> > > mvn site
> > >> > > Check the site reports in:
> > >> > > - Windows: target\site\index.html
> > >> > > - Linux: target/site/index.html
> > >> > >
> > >> > > -the end-
> > >> > >
> > >> > >
> ---------------------------------------------------------------------
> > >> > > 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
>
>
