I think there is an additional item that falls into the same category. What are Apache guidelines/policies regarding maven group ids and java package names?
Many projects use org.apache.foo as the group id for projects and org.apache.foo.subproject.InterfaceName for class names. Others use naked foo as high level package names and org.foo as group ids. I think there may be a difference based on whether the project is intended for use as an API or as an executable. Possibly also whether the project had a large user community before coming to Apache. I don’t know that the incubator or Apache has ever had a discussion on this topic, and it seems relevant. If not, please disregard and I’ll raise it in another thread. Craig > On Jan 3, 2017, at 7:19 PM, John D. Ament <johndam...@apache.org> wrote: > > All, > > This is a follow up to recent threads, purposely made a bit broader to > encourage more discussions. First to set down some facts about what's been > established: > > 1. Incubator policy [1] states that a podling's release meets two > requirements, include "incubating" in the release archive's file name and > the standard disclaimer within the documentation or README. > > 2. The foundation policy on a valid release [2] seems to indicate that the > elements that make up a valid release includes properly licensed source > code, ICLAs on file, IP clearance and grants. > > 3. Back in 2008 [3] it was established that incubator released are endorsed > while the podlings themselves are not endorsed. This means that while the > podling may not fully be developed in an open way, all releases produced > are expected to comply with ASF policies. > > So why am I harping on this problem? The incubator has a series of guides, > which are partially treated as policy and partially treated as advice. > Many of these guides remain with large notions of being draft only, not > finalized, I want to try to get these draft documents finalized so that > we're able to provide better guidance to podlings coming in. > > I also think its important to keep our policies and guides as light as > possible. There shouldn't be a lot different in the incubator than a TLP > would go through, or else this makes the eventual transition to TLP harder > since many things previously done are now different. > > One of the distinguishing marks within the incubator is the use of maven. > The incubator has a best practice that says if your build tool is maven, if > and when you publish a convenience binary, that convenience binary must > include either incubator or incubating in the version string [4]. Its not > clear why maven is singled out, probably because it was the first of its > kind, other tools didn't exist. One of the key notes I can find is that > the downstream redistribution channels are operated outside the ASF [5]. > So while Maven is an apache project, maven central is not an ASF managed > resource but we are attempting to enforce our internal concerns to an > outside party. > > So I move that we cannot apply our policies on third parties, and artifacts > distributed in maven central from our release archives need not comply with > our policies. > > John > > [1]: http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > [2]: http://www.apache.org/dev/release-publishing.html#valid > [3]: > https://lists.apache.org/thread.html/0b6c065a908c5f9ec39fa78c31b39c83a6fea29eb34fada0ee070413@1222432864@%3Cgeneral.incubator.apache.org%3E > [4]: > http://incubator.apache.org/guides/release-java.html#best-practice-maven > [5]: http://www.apache.org/dev/release-distribution.html#channels Craig Russell papa...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
