While I do think that the org.apache.river.(impl|api) distinction is more clear, different projects have different styles in this regard and I think it is Ok to respect the existing patterns.
My sense is that river 3.0 is not introducing a large set of new public implementation objects and that most of the change is "behind the scenes" in terms of the public APIs. Is this correct? Why use net.jini.* rather than net.river.*? What is the "new api" vs "existing api" distinction? Apologies if I am behind the curve here. It would probably be easier for me to understand if the package namespace cleanup was proposed as a list of X => Y renames so I could look at the source tree and understand more clearly what is involved. Thanks, Bryan On Mon, Aug 31, 2015 at 3:52 AM, Peter <j...@zeus.net.au> wrote: > All packages in org.apache.river.*, apart from org.apache.river.api is > implementation code. There's also an implementation package > org.apache.river.impl. > > I think it would be too much work to move everything into the impl package > now. > > The easiest solution would be to move anything in org.apache.river.api > into the net.jini namespace where it makes sense. From memory some things > I had wanted to make package private ended up being public because of the > need to avoid adding new api to net.jini.* as this namespace was standards > developed, however I'm not sure weather it makes sense now to strictly > adhere to that rule. > > Can we use org.apache.river.* as implementation and net.jini.* for public > api? > > Anything introduced in River 3.0 will be annotated with @since 3.0 > anyway. Anything we can't justify putting into net.jini.* public api > namespace should probably remain in the implementation. > > Thoughts? > > > Regards, > > Peter. > > > On 31/08/2015 12:04 AM, Patricia Shanahan wrote: > >> One objective should be a really clear, and clearly articulated, >> distinction between public APIs and implementation. >> >> I would like to see all implementation code marked in one of three ways: >> >> non-public access >> >> com.sun package name >> >> package name with "impl" as one of the components. >> >> Adding a public non-imple API is something that needs to be done very >> carefully, because it is difficult to undo. >> >> On 8/30/2015 4:09 AM, Peter wrote: >> >>> I finally had the chance to look through the org.apache.river name >>> change work Dennis Reedy has done, it all looks very impressive, he's >>> even taken the time to tidy up the qa suite. I haven't had time to run >>> any tests or look at the jtreg test suite, I promise I'll make some time >>> in the near future. Before we release this code there is an opportunity >>> to tidy up the org.apache.river name space even further. In the Jini >>> days, com.sun.jini.* was implementation code, it wasn't part of the Jini >>> public API, should we now use org.apache.river.* for this purpose? There >>> is some new public api, in org.apache.river.api.* and at the time new >>> implementation code was being placed into org.apache.river.impl.* and >>> now the com.sun.jini.* namespace has been moved to org.apache.river.*. >>> Should we consider placing the new api in the net.jini.* namespace? It's >>> worth looking at the javadoc as most of the new classes are package >>> private. There are also discovery constraints in the implementation >>> namespace that should be moved into the public api in my opinion, >>> thoughts? >>> >> >> >
