I think PDFBox and/or POI did something like that with XML Beans. Gary
On Sun, Dec 19, 2021 at 5:10 PM Matt Sicker <boa...@gmail.com> wrote: > > I thought there was some old XML library that was resurrected here at Apache > because other PMCs were still using it as a dependency. That might have been > more so related to the Attic. > > Anyways, as can be seen already, making non-controversial changes to 1.x that > both the PMC and our users could accept could turn out to be fairly > difficult, especially compared to the level of effort remaining in 2.x to > ensure our 1.x backward compatibility support is further polished. I haven’t > looked closely at 1.x (beyond some recent checks to see if the JNDI issue was > exploitable there, too) in a few years, and even then it had a lot of > technical debt to pay off simply related to the build environment and release > process. It’s one thing to patch a class and throw a jar into the ever > expanding repository that is Maven Central, but it’s a larger effort to > publish an Apache release. > > Here are some resources about what’s required for a release along with some > reference material that’s applicable for any Apache project: > * https://www.apache.org/legal/release-policy.html > <https://www.apache.org/legal/release-policy.html> > * https://infra.apache.org/release-distribution.html > <https://infra.apache.org/release-distribution.html> > * https://infra.apache.org/release-publishing.html > <https://infra.apache.org/release-publishing.html> > * https://infra.apache.org/release-signing.html > <https://infra.apache.org/release-signing.html> > > Note that the release requirements for ASF projects cannot be left out. There > are less strict release requirements when going through the Incubator, but at > least one release using the normal ASF release requirements is required to > graduate. > > Please take these ASF requirements in mind when considering the amount of > work remaining to be done to even get 1.x back into a releasable state > compared to the alternatives discussed in this thread. > > -- > Matt Sicker > > > On Dec 19, 2021, at 15:58, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > WRT words, IIRC Apache only has top-level projects (for example, > > Apache Logging Services, Apache Commons, Apache HttpComponents), > > within that you can have components, not other projects, for example, > > Apache Log4j, Apache Commons IO, Apache HttpComponents HttpCore. > > > > Gary > > > > On Sun, Dec 19, 2021 at 4:29 PM Ralph Goers <ralph.go...@dslextreme.com> > > wrote: > >> > >> The Logging Services project is an “umbrella” project that manages all the > >> logging projects, including Log4j 1.x. > >> We would not be in favor of having Log4j 1.x become a new standalone PMC. > >> > >> But yes, any Logging Services PMC member can veto a code change in any of > >> the sub-projects. > >> I don’t know that it has ever happened. > >> > >> Ralph > >> > >>> On Dec 19, 2021, at 2:13 PM, Vladimir Sitnikov > >>> <sitnikov.vladi...@gmail.com> wrote: > >>> > >>>> All new ASF projects go through the incubator. Sub-projects don’t have to > >>> but when an entirely new community is being > >>> > >>> I'm a member of PMC Calcite and JMeter, however, I have not submitted > >>> projects to the incubator yet. > >>> > >>>> Once graduated the podling > >>> PMC members would become part of the Logging Services PMC. > >>> > >>> Does that mean the current members of Logging Services PMC could veto code > >>> changes in the "new" log4j1? > >>> That sounds strange, and it defeats the reason to re-establish the new set > >>> of PMC members for log4j 1.x > >>> > >>> Vladimir > >> >
