> Some terms: > - Apache Commons is an Apache _project_. > - Apache Commons Lang is a _component_ of the _project_.
> Each component has its own level of functionality and granularity. Some are > lower level, like Commons Lang and Commons IO and do not depend on anything > at runtime. > Others offer higher levels of functionality like Commons VFS, Commons > Configuration, Commons Digester, and Commons Weaver. > You'll notice that some of the lower-level components offer a single Maven > module and jar, while others offer many. > There is no uniform granularity to be expected. Get it, at least, kind of. But if Apache Commons is thought to be a whole project, I do think the relationship between each of its components should be enforced. For example, we might start from trying to use a same code style formatter. Thanks. Gary Gregory <garydgreg...@gmail.com> 于2020年6月12日周五 下午9:42写道： > On Fri, Jun 12, 2020 at 9:30 AM Xeno Amess <xenoam...@gmail.com> wrote: > > > Hi. > > > > >> 2. How are commons projects related? > > > > > They are not necessarily related. Usually it is considered > > > a feature if a component has zero dependency (as it is was > > > easier to avoid "JAR hell"). > > > However, there are also drawbacks, e.g. duplicating functionality > > > (and work) needed by several components. > > > > Something was not quite right about this. > > For example, in commons-vfs, we just use commons-lang3 as a dependency. > > But in commons-email, we fork some of utility functions in commons-lang3 > as > > a java class in commons-email. > > Which is the right way, or a more commonly accepted way in commons > > projects? > > > > Some terms: > - Apache Commons is an Apache _project_. > - Apache Commons Lang is a _component_ of the _project_. > > Each component has its own level of functionality and granularity. Some are > lower level, like Commons Lang and Commons IO and do not depend on anything > at runtime. > Others offer higher levels of functionality like Commons VFS, Commons > Configuration, Commons Digester, and Commons Weaver. > You'll notice that some of the lower-level components offer a single Maven > module and jar, while others offer many. > There is no uniform granularity to be expected. > > HTH, > Gary > > > > > > Gilles Sadowski <gillese...@gmail.com> 于2020年6月12日周五 下午9:07写道： > > > > > Hello. > > > > > > Le ven. 12 juin 2020 à 13:51, Xeno Amess <xenoam...@gmail.com> a > écrit : > > > > > > > > 1. How can a project *** becomes commons-***, or how did a > commons-*** > > > > project started? What is the actual procedural? > > > > > > For new components, this list would be the place to make the > > > proposal. A discussion would decide if "Apache Commons" is > > > the right place (given the interest/capacity of the current team). > > > > > > > 2. How are commons projects related? > > > > > > They are not necessarily related. Usually it is considered > > > a feature if a component has zero dependency (as it is was > > > easier to avoid "JAR hell"). > > > However, there are also drawbacks, e.g. duplicating functionality > > > (and work) needed by several components. > > > > > > > Are they under a same (or at least > > > > similar) management mechanism? Or just sharing a common prefix? > > > > > > Do you mean the development tools (maven, git)? > > > There some measure of "standardization" through the parent POM > > > file, but nothing is really enforced. The code style depends on the > > > regular contributors (and how old the codebase was when it was > > > considered "mature"). > > > > > > > 3. How is commons projects' version control, based on function or > based > > > on > > > > time? > > > > > > A backward-compatible release has its minor version number > > > increased; otherwise both the major number and the base package > > > are changed. > > > > > > > 4. Why some projects are on svn, some on gitbox, and some on github? > > > > > > All actively developed components were (will be) moved to "gitbox" > > > (decision made a few years ago, cf. "dev" M archive). > > > Those remaining on SVN are probably mainly "dormant" (except > > > perhaps for some security fix). > > > > > > IIUC, a "GitHub" mirror is automatically created for every new > > > "gitbox" Apache project. > > > > > > > 5. What problems shall be put on mailing list, and what problems > shall > > be > > > > put on Jira? > > > > > > ML: proposal, discussion on design, ... > > > JIRA: identified bugs (with references and/or unit test), accepted > > > feature, discussion on implementation details, ... > > > > > > > 6. Is there quite some dead projects in commons? And how to > detect/mark > > > > them? > > > > > > Depends on the definition of "dead". > > > None of the components in "proper" are considered dead, even if > > > they are not actively developed anymore (whether this is "good" > > > or "bad" is another question). > > > I haven't seen anything in "sandbox" being developed for a long > > > time (until the last few days where "Commons Graph" seems it > > > may be revived). > > > Unless I'm mistaken, a project in "dormant" has been subject to > > > decision for stopping its development. > > > > > > > 7. What is the general waiting time for a pr to be reviewed(and > > rejected > > > or > > > > accepted)? In my own observation the waiting time is between [1 days, > > 1.5 > > > > years) , is it a little...large? > > > > > > It boils down to the level of involvement of a committer for the > > > component being the target of the PR. > > > Developers being volunteers, it certainly also depends on the > > > balance between the usefulness of the PR and the work required > > > from the reviewer. > > > > > > > 8. What should we do when we have a pr delayed for a long time? And > how > > > > long is thought to be an unusual long time for waiting? 3 days.1 > > week,or > > > 1 > > > > month? > > > > > > They might have been forgotten, or there may other issues. > > > Examples? > > > > > > > > > > > Sorry for having so many questions, but I'm just very curious. > > > > > > Hope the above answers have helped. > > > > > > Regards, > > > Gilles > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
