You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by rl...@codelibre.net on 2022/06/22 22:21:11 UTC
Future of xalan-c
Dear all,
I wanted to write this email to sound out where the project is, where it is
going, and whether or not it has a future. If it does not have a future, is
it time to wrap up the project and move it to the Attic?
To start with, a bit of context. This is a summary of the project's commit
activity over the previous 22 years:
Back in July 2020, just a little under two years ago, I released Xalan-C
1.12. This was the first release since Xalan-C 1.11 in October 2012, and it
incorporated a number of patches which had been accumulated over the course
of years by several downstream distributors.
https://apache.github.io/xalan-c/releases.html#major-changes shows the major
changes in this release. On the above graph, this release is comprised of
the commits from 2019 to 2020. I was the sole committer for this release.
The previous 1.11 release was made in October 2012 with Steven J. Hathaway
being the principal contributor.
The previous 1.10 release was made in October 2005 with David N Berton and
Dmitry Hayes being the principal contributors.
The previous 1.9 release was made in December 2004 with June Ng, Matthew
Hoyt, David N Berton and Dmitry Hayes being the principal contributors.
The previous 1.8 release was made in April 2004 with Matthew Hoyt, David N
Berton and Dmitry Hayes being the principal contributors.
The main points I'd like to make here are the following:
* Active development of Xalan-C effectively finished with the 1.10
release in 2005. The vast majority of work since then has been little more
than essential bugfixing and portability work to support new platforms and
toolchains.
* 1.11 was a bugfix release. It was primarily comprised of essential
bugfixes, and fixes for building with different toolchains on different
platforms and some documentation work. There was one code improvement of
note: "Add number and nodeset types as top-level stylesheet parameters"
* 1.12 was a bugfix release. It was primarily comprised of essential
bugfixes, and fixes for building on different platforms, with the CMake
support generalising that to build on current platforms, plus the
documentation switch to Markdown. There were zero new features or
improvements outside essential bugfixing.
* There is essentially ~zero developer mailing list activity
* There is essentially ~zero user mailing list activity
* Community involvement on GitHub is present but at very low and
sporadic levels. We have three PRs from contributors other than myself
(https://github.com/apache/xalan-c/pulls?q=is%3Apr+is%3Aclosed). One was a
triviality, two were portability fixes just altering platform-specific
ifdefs. There is one open PR
(https://github.com/apache/xalan-c/pulls?q=is%3Aopen+is%3Apr). This looks
simple but I'm not sure of the impact in case of unexpected subtleties.
I became involved in the project for pragmatic reasons-I worked on a project
using XSLT and picked up Xalan-C as a dependency. I wrote and contributed
the CMake support and worked on the 1.12 release for that reason. But I
don't know the underlying codebase, and I can't do any real feature
development or deep bugfixing. I don't have the expertise with XSLT, or the
time to do this. And since I no longer work on any projects using Xalan-C,
I'm no longer realistically able to do any further maintenance work either.
If I hadn't done the most recent work and made the 1.12 release, it's most
likely that the incorporation of community patchsets and making a point
release would not have happened. No one aside from me has worked on Xalan-C
since Steven J Hathaway's last work in 2012.
I don't personally think there is sufficient community involvement or
developer involvement to realistically support Xalan-C as an active project
in any sense. There is no one working on it. And while I'm sure there are
some users, there's next to no active engagement of users as a community.
I've made a good effort to keep the project going for the near- to
medium-term. The CMake build made it possible to build on all contemporary
platforms. The documentation switch to Markdown made it possible to build
without obsolete and unavailable Java libraries. The bugfixes we included
in 1.12 fixed a number of critical issues. So 1.12 should serve as a usable
release for the foreseeable future even in the absence of further
development.
However, I don't see a future for anything beyond 1.12 unless there is a
dramatic change. XSLT usage is declining, and Xalan-C doesn't support XSLT
2.0 and beyond. Rather than letting the current situation linger on
indefinitely, I wanted to suggest we take stock of where we are, and if
there is consensus to do so, I think it would be advisable to draw a line at
this point and end the project gracefully.
Kind regards,
Roger
RE: Future of xalan-c
Posted by Paul Kinnucan <pa...@mathworks.com>.
Hi,
The MATLAB API for XML Processing (MAXP) is based on Xalan-c and is vey much alive. Thus, retiring Xalan-c would be a major blow for us, especially as Xalan-c is unable to execute the DocBook XSL-FO style sheet. We were planning to file a bug report regarding this issue.
We too great;u appreciate the hard and skillful work that went into Xalan-c, including Roger's update of the build infrastructure, and would be sorry to see it retired.
Regards,
Paul Kinnucan
Development Manager
MATLAB and Simulink Report Generators
MathWorks
1 Lakeside Campus Drive
Natick, MA 01760
paulk@mathworks.com
508-647-7271
-----Original Message-----
From: Bill Blough <de...@blough.us.INVALID>
Sent: Friday, June 24, 2022 9:31 AM
To: dev@xalan.apache.org
Cc: c-users@xalan.apache.org
Subject: Re: Future of xalan-c
Hi Roger,
First and foremost, thanks for all the work you've done on Xalan.
On Wed, Jun 22, 2022 at 11:21:11PM +0100, rleigh@codelibre.net wrote:
>
> I don't personally think there is sufficient community involvement or
> developer involvement to realistically support Xalan-C as an active
> project in any sense. There is no one working on it. And while I'm
> sure there are some users, there's next to no active engagement of users as a community.
>
> I've made a good effort to keep the project going for the near- to
> medium-term. The CMake build made it possible to build on all
> contemporary platforms. The documentation switch to Markdown made it
> possible to build without obsolete and unavailable Java libraries.
> The bugfixes we included in 1.12 fixed a number of critical issues.
> So 1.12 should serve as a usable release for the foreseeable future
> even in the absence of further development.
>
> However, I don't see a future for anything beyond 1.12 unless there is
> a dramatic change. XSLT usage is declining, and Xalan-C doesn't
> support XSLT
> 2.0 and beyond. Rather than letting the current situation linger on
> indefinitely, I wanted to suggest we take stock of where we are, and
> if there is consensus to do so, I think it would be advisable to draw
> a line at this point and end the project gracefully.
I expect that pretty much all of the systems using Xalan these days are legacy systems. That is, I highly doubt anyone is writing new software that uses it.
So the only involvement I would expect would be the occasional reporting of a bug that hasn't turned up yet, or build system or compiler version related issues as systems are upgraded.
As far as I can tell, Xalan works well for what it does, and in my experience most legacy software doesn't receive a lot of changes/upgraded other than the bare minimum to stay compliant with audits, etc.
As you said, XSLT usage (and XML for that matter) is declining, so in my opinion, doing major feature work (such as supporting newer XSLT
standards) has very little to no payoff from a cost/benefit perspective.
So in that regard, I agree that Xalan isn't likely to see another major release.
However, there are still users, and sometimes things break as systems get upgraded. So I guess a question is, do we feel it's worth it to support these users by way of small maintenance efforts on an as-needed basis, even though we know that usage is trending down over time, and that there will never be another major release?
Or, perhaps a bigger question is, will there be enough devs to continue the project, even for just the small maintenance efforts?
Forgive me if I'm reading too much into your message, but I'm wondering if you bringing this up is due to wanting to step away from the project?
If that's the case, then ultimately we need to determine if there will continue to be enough people to conduct votes. If not, then there will be little choice in the matter.
Personally, I'd like to see Xalan stay around, if for no other reason than to continue support for those existing legacy users. Though I realize that's an easy thing for me to say, as I haven't been very active in the past couple of years (in any of the FLOSS projects I'm involved with, not just Xalan specifically).
Regardless, thanks for bringing this up. I think it's a good thing for all projects to ask themselves from time to time.
Best regards,
Bill
--
GPG: 5CDD 0C9C F446 BC1B 2509 8791 1762 E022 7034 CF84
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org For additional commands, e-mail: dev-help@xalan.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org
For additional commands, e-mail: dev-help@xalan.apache.org
RE: Future of xalan-c
Posted by rl...@codelibre.net.
> From: Bill Blough <de...@blough.us>
> On Wed, Jun 22, 2022 at 11:21:11PM +0100, rleigh@codelibre.net wrote:
> >
> > I don't personally think there is sufficient community involvement or
> > developer involvement to realistically support Xalan-C as an active
> > project in any sense. There is no one working on it. And while I'm
> > sure there are some users, there's next to no active engagement of users
as
> > a community.
> However, there are still users, and sometimes things break as systems get
> upgraded. So I guess a question is, do we feel it's worth it to support
these
> users by way of small maintenance efforts on an as-needed basis, even
> though we know that usage is trending down over time, and that there will
> never be another major release?
>
> Or, perhaps a bigger question is, will there be enough devs to continue
the
> project, even for just the small maintenance efforts?
This is certainly the kind of question I'd like us to consider.
One part of that is determining the ongoing maintenance efforts required to
make a point release for any bugfixes, and/or for reviewing and merging any
provided changes.
If you go to https://github.com/apache/xalan-c and look at the CI status for
the latest merged change, you'll see it's got a red "X" next to it.
If you look at that in more detail, you'll see that both the Travis builds
and the AppVeyor builds are both failing.
Travis: https://github.com/apache/xalan-c/runs/4304118187, looks like two
failing MacOS X builds. Likely issues on the Travis side rather than on our
part
AppVeyor:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/xalan-c/builds/4164
2715, some odd link error
If we're going to be making any further changes, even just merging pull
requests, we need a working CI setup. Unfortunately, maintaining such a
setup is a significant commitment.
The Travis (Linux, MacOS X) setup needs migrating over to use GitHub actions
after the Travis company went off the rails; not sure what the Apache
project arrangements are for doing that.
The AppVeyor setup needs updating to use a more recent base image with
up-to-date dependencies provisioned with vcpkg.
And once working, they both need ongoing maintenance effort to keep them
current and working.
None of this is especially difficult. But it is very time-consuming.
If you look at the setup for Xerces-C++, you'll see a working and more
comprehensive Travis setup
(https://github.com/apache/xerces-c/runs/5526468479) and a mostly working
AppVeyor setup
(https://ci.appveyor.com/project/ApacheSoftwareFoundation/xerces-c-gfvct/bui
lds/42880201)--two failing Cygwin variants (I think the image needs
updating). Ours is only testing one Windows variant, and doesn't even
attempt MinGW or Cygwin.
We could just remove all CI testing and merge changes as-is. However, I
wouldn't be too happy in removing that quality bar, I do feel it's a bare
minimum for guaranteeing that the code quality and portability are
acceptable.
The other side of things is determining if we have the necessary expertise
to review patches. https://github.com/apache/xalan-c/pull/39 needs review,
and it looks simple, but I don't have the existing expertise (or the time to
dig into it in detail to get that expertise) to properly review and test
this change. This change has been open for seven months.
> Forgive me if I'm reading too much into your message, but I'm wondering if
> you bringing this up is due to wanting to step away from the project?
> If that's the case, then ultimately we need to determine if there will
continue
> to be enough people to conduct votes. If not, then there will be little
choice
> in the matter.
I haven't actually used Xerces-C++ since making the 1.12 release, so my
current involvement and expected future involvement are currently zero, I'm
sorry to say.. While I would certainly like to be able to offer my time,
unfortunately I haven't had enough of it for some time now, and I don't
expect that to change.
I would like to step away, and this is certainly part of the reason for
bringing this up: I wouldn't want to leave the project leaving things
hanging and its status uncertain.
> Personally, I'd like to see Xalan stay around, if for no other reason than
to
> continue support for those existing legacy users. Though I realize that's
an
> easy thing for me to say, as I haven't been very active in the past couple
of
> years (in any of the FLOSS projects I'm involved with, not just Xalan
> specifically).
If we do have it moved to the Attic, it could be reactivated again in the
future if some future developers wish to resurrect it.
If there are remaining legacy users, it would be useful to hear from them.
At some level, if those remaining users need support, then I think they
would need to commit to supporting the project more directly themselves, and
picking up some of the maintenance and support burden.
At least from the open source side of things, I haven't seen any evidence of
any users these last few years. When I got it fixed up and working in
Debian, FreeBSD, homebrew and vcpkg, there were no reverse dependencies upon
Xalan-C++. Most of these systems either had dropped Xalan-C++ packaging due
to it being broken for years, or it never having been added in the first
place. Now, this is limited to packaged open-source software provided
through distribution package managers. But it's indicative of the overall
usage being close to zero, I'm afraid to say.
Kind regards,
Roger
RE: Future of xalan-c
Posted by Paul Kinnucan <pa...@mathworks.com>.
Hi,
The MATLAB API for XML Processing (MAXP) is based on Xalan-c and is vey much alive. Thus, retiring Xalan-c would be a major blow for us, especially as Xalan-c is unable to execute the DocBook XSL-FO style sheet. We were planning to file a bug report regarding this issue.
We too great;u appreciate the hard and skillful work that went into Xalan-c, including Roger's update of the build infrastructure, and would be sorry to see it retired.
Regards,
Paul Kinnucan
Development Manager
MATLAB and Simulink Report Generators
MathWorks
1 Lakeside Campus Drive
Natick, MA 01760
paulk@mathworks.com
508-647-7271
-----Original Message-----
From: Bill Blough <de...@blough.us.INVALID>
Sent: Friday, June 24, 2022 9:31 AM
To: dev@xalan.apache.org
Cc: c-users@xalan.apache.org
Subject: Re: Future of xalan-c
Hi Roger,
First and foremost, thanks for all the work you've done on Xalan.
On Wed, Jun 22, 2022 at 11:21:11PM +0100, rleigh@codelibre.net wrote:
>
> I don't personally think there is sufficient community involvement or
> developer involvement to realistically support Xalan-C as an active
> project in any sense. There is no one working on it. And while I'm
> sure there are some users, there's next to no active engagement of users as a community.
>
> I've made a good effort to keep the project going for the near- to
> medium-term. The CMake build made it possible to build on all
> contemporary platforms. The documentation switch to Markdown made it
> possible to build without obsolete and unavailable Java libraries.
> The bugfixes we included in 1.12 fixed a number of critical issues.
> So 1.12 should serve as a usable release for the foreseeable future
> even in the absence of further development.
>
> However, I don't see a future for anything beyond 1.12 unless there is
> a dramatic change. XSLT usage is declining, and Xalan-C doesn't
> support XSLT
> 2.0 and beyond. Rather than letting the current situation linger on
> indefinitely, I wanted to suggest we take stock of where we are, and
> if there is consensus to do so, I think it would be advisable to draw
> a line at this point and end the project gracefully.
I expect that pretty much all of the systems using Xalan these days are legacy systems. That is, I highly doubt anyone is writing new software that uses it.
So the only involvement I would expect would be the occasional reporting of a bug that hasn't turned up yet, or build system or compiler version related issues as systems are upgraded.
As far as I can tell, Xalan works well for what it does, and in my experience most legacy software doesn't receive a lot of changes/upgraded other than the bare minimum to stay compliant with audits, etc.
As you said, XSLT usage (and XML for that matter) is declining, so in my opinion, doing major feature work (such as supporting newer XSLT
standards) has very little to no payoff from a cost/benefit perspective.
So in that regard, I agree that Xalan isn't likely to see another major release.
However, there are still users, and sometimes things break as systems get upgraded. So I guess a question is, do we feel it's worth it to support these users by way of small maintenance efforts on an as-needed basis, even though we know that usage is trending down over time, and that there will never be another major release?
Or, perhaps a bigger question is, will there be enough devs to continue the project, even for just the small maintenance efforts?
Forgive me if I'm reading too much into your message, but I'm wondering if you bringing this up is due to wanting to step away from the project?
If that's the case, then ultimately we need to determine if there will continue to be enough people to conduct votes. If not, then there will be little choice in the matter.
Personally, I'd like to see Xalan stay around, if for no other reason than to continue support for those existing legacy users. Though I realize that's an easy thing for me to say, as I haven't been very active in the past couple of years (in any of the FLOSS projects I'm involved with, not just Xalan specifically).
Regardless, thanks for bringing this up. I think it's a good thing for all projects to ask themselves from time to time.
Best regards,
Bill
--
GPG: 5CDD 0C9C F446 BC1B 2509 8791 1762 E022 7034 CF84
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org For additional commands, e-mail: dev-help@xalan.apache.org
Re: Future of xalan-c
Posted by Steven Hathaway <sh...@e-z.net>.
Thanks for your comments. And thanks to Roger for the Xalan-C 1.12 release.
The legacy projects I worked on which required Xalan-C have been
retired. The new projects requiring my services leave me with no time to
continue with Xalan-C.
The SaxonC project has received most of the legacy Xalan-C project users
and continues to have support.
The ability to maintain the Xalan-C code base requires extensive C++ and
STL expertise. Newer C++ compiler specifications and deprecation of some
STL templating features required by the current Xalan-C code base make
it difficult to maintain without significant involvement. The project
requires developers that are expert in C++ compiler feature migration
and STL template troubleshooting. The ability to effectively reverse
engineer the C++ and STL code base is almost a necessity.
The dependency on Xerces-C also has maintenance issues. The Xalan-C and
Xerces-C constitutes an orchestrated feature set in order to build
operational libraries.
My passion for Xalan-C still exists, and I have prototypes for new
features, but I have no time to move these prototypes into a production
environment.
IMHO it appears that Xalan-C may be a candidate for the Apache Attic.
Sincerely,
Steven J. Hathaway
On 6/24/2022 6:31 AM, Bill Blough wrote:
> Hi Roger,
>
> First and foremost, thanks for all the work you've done on Xalan.
>
> On Wed, Jun 22, 2022 at 11:21:11PM +0100, rleigh@codelibre.net wrote:
>> I don't personally think there is sufficient community involvement or
>> developer involvement to realistically support Xalan-C as an active project
>> in any sense. There is no one working on it. And while I'm sure there are
>> some users, there's next to no active engagement of users as a community.
>>
>> I've made a good effort to keep the project going for the near- to
>> medium-term. The CMake build made it possible to build on all contemporary
>> platforms. The documentation switch to Markdown made it possible to build
>> without obsolete and unavailable Java libraries. The bugfixes we included
>> in 1.12 fixed a number of critical issues. So 1.12 should serve as a usable
>> release for the foreseeable future even in the absence of further
>> development.
>>
>> However, I don't see a future for anything beyond 1.12 unless there is a
>> dramatic change. XSLT usage is declining, and Xalan-C doesn't support XSLT
>> 2.0 and beyond. Rather than letting the current situation linger on
>> indefinitely, I wanted to suggest we take stock of where we are, and if
>> there is consensus to do so, I think it would be advisable to draw a line at
>> this point and end the project gracefully.
> I expect that pretty much all of the systems using Xalan these days are legacy
> systems. That is, I highly doubt anyone is writing new software that uses it.
> So the only involvement I would expect would be the occasional reporting
> of a bug that hasn't turned up yet, or build system or compiler version
> related issues as systems are upgraded.
>
> As far as I can tell, Xalan works well for what it does, and in my
> experience most legacy software doesn't receive a lot of
> changes/upgraded other than the bare minimum to stay compliant with
> audits, etc.
>
> As you said, XSLT usage (and XML for that matter) is declining, so in my
> opinion, doing major feature work (such as supporting newer XSLT
> standards) has very little to no payoff from a cost/benefit perspective.
> So in that regard, I agree that Xalan isn't likely to see another major
> release.
>
> However, there are still users, and sometimes things break as systems get
> upgraded. So I guess a question is, do we feel it's worth it to support
> these users by way of small maintenance efforts on an as-needed basis, even
> though we know that usage is trending down over time, and that there
> will never be another major release?
>
> Or, perhaps a bigger question is, will there be enough devs to
> continue the project, even for just the small maintenance efforts?
> Forgive me if I'm reading too much into your message, but I'm wondering
> if you bringing this up is due to wanting to step away from the project?
> If that's the case, then ultimately we need to determine if there will
> continue to be enough people to conduct votes. If not, then there will
> be little choice in the matter.
>
> Personally, I'd like to see Xalan stay around, if for no other reason
> than to continue support for those existing legacy users. Though I
> realize that's an easy thing for me to say, as I haven't been very
> active in the past couple of years (in any of the FLOSS projects I'm
> involved with, not just Xalan specifically).
>
> Regardless, thanks for bringing this up. I think it's a good thing for
> all projects to ask themselves from time to time.
>
> Best regards,
> Bill
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org
For additional commands, e-mail: dev-help@xalan.apache.org
RE: Future of xalan-c
Posted by rl...@codelibre.net.
> From: Bill Blough <de...@blough.us>
> On Wed, Jun 22, 2022 at 11:21:11PM +0100, rleigh@codelibre.net wrote:
> >
> > I don't personally think there is sufficient community involvement or
> > developer involvement to realistically support Xalan-C as an active
> > project in any sense. There is no one working on it. And while I'm
> > sure there are some users, there's next to no active engagement of users
as
> > a community.
> However, there are still users, and sometimes things break as systems get
> upgraded. So I guess a question is, do we feel it's worth it to support
these
> users by way of small maintenance efforts on an as-needed basis, even
> though we know that usage is trending down over time, and that there will
> never be another major release?
>
> Or, perhaps a bigger question is, will there be enough devs to continue
the
> project, even for just the small maintenance efforts?
This is certainly the kind of question I'd like us to consider.
One part of that is determining the ongoing maintenance efforts required to
make a point release for any bugfixes, and/or for reviewing and merging any
provided changes.
If you go to https://github.com/apache/xalan-c and look at the CI status for
the latest merged change, you'll see it's got a red "X" next to it.
If you look at that in more detail, you'll see that both the Travis builds
and the AppVeyor builds are both failing.
Travis: https://github.com/apache/xalan-c/runs/4304118187, looks like two
failing MacOS X builds. Likely issues on the Travis side rather than on our
part
AppVeyor:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/xalan-c/builds/4164
2715, some odd link error
If we're going to be making any further changes, even just merging pull
requests, we need a working CI setup. Unfortunately, maintaining such a
setup is a significant commitment.
The Travis (Linux, MacOS X) setup needs migrating over to use GitHub actions
after the Travis company went off the rails; not sure what the Apache
project arrangements are for doing that.
The AppVeyor setup needs updating to use a more recent base image with
up-to-date dependencies provisioned with vcpkg.
And once working, they both need ongoing maintenance effort to keep them
current and working.
None of this is especially difficult. But it is very time-consuming.
If you look at the setup for Xerces-C++, you'll see a working and more
comprehensive Travis setup
(https://github.com/apache/xerces-c/runs/5526468479) and a mostly working
AppVeyor setup
(https://ci.appveyor.com/project/ApacheSoftwareFoundation/xerces-c-gfvct/bui
lds/42880201)--two failing Cygwin variants (I think the image needs
updating). Ours is only testing one Windows variant, and doesn't even
attempt MinGW or Cygwin.
We could just remove all CI testing and merge changes as-is. However, I
wouldn't be too happy in removing that quality bar, I do feel it's a bare
minimum for guaranteeing that the code quality and portability are
acceptable.
The other side of things is determining if we have the necessary expertise
to review patches. https://github.com/apache/xalan-c/pull/39 needs review,
and it looks simple, but I don't have the existing expertise (or the time to
dig into it in detail to get that expertise) to properly review and test
this change. This change has been open for seven months.
> Forgive me if I'm reading too much into your message, but I'm wondering if
> you bringing this up is due to wanting to step away from the project?
> If that's the case, then ultimately we need to determine if there will
continue
> to be enough people to conduct votes. If not, then there will be little
choice
> in the matter.
I haven't actually used Xerces-C++ since making the 1.12 release, so my
current involvement and expected future involvement are currently zero, I'm
sorry to say.. While I would certainly like to be able to offer my time,
unfortunately I haven't had enough of it for some time now, and I don't
expect that to change.
I would like to step away, and this is certainly part of the reason for
bringing this up: I wouldn't want to leave the project leaving things
hanging and its status uncertain.
> Personally, I'd like to see Xalan stay around, if for no other reason than
to
> continue support for those existing legacy users. Though I realize that's
an
> easy thing for me to say, as I haven't been very active in the past couple
of
> years (in any of the FLOSS projects I'm involved with, not just Xalan
> specifically).
If we do have it moved to the Attic, it could be reactivated again in the
future if some future developers wish to resurrect it.
If there are remaining legacy users, it would be useful to hear from them.
At some level, if those remaining users need support, then I think they
would need to commit to supporting the project more directly themselves, and
picking up some of the maintenance and support burden.
At least from the open source side of things, I haven't seen any evidence of
any users these last few years. When I got it fixed up and working in
Debian, FreeBSD, homebrew and vcpkg, there were no reverse dependencies upon
Xalan-C++. Most of these systems either had dropped Xalan-C++ packaging due
to it being broken for years, or it never having been added in the first
place. Now, this is limited to packaged open-source software provided
through distribution package managers. But it's indicative of the overall
usage being close to zero, I'm afraid to say.
Kind regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org
For additional commands, e-mail: dev-help@xalan.apache.org
Re: Future of xalan-c
Posted by Bill Blough <de...@blough.us.INVALID>.
Hi Roger,
First and foremost, thanks for all the work you've done on Xalan.
On Wed, Jun 22, 2022 at 11:21:11PM +0100, rleigh@codelibre.net wrote:
>
> I don't personally think there is sufficient community involvement or
> developer involvement to realistically support Xalan-C as an active project
> in any sense. There is no one working on it. And while I'm sure there are
> some users, there's next to no active engagement of users as a community.
>
> I've made a good effort to keep the project going for the near- to
> medium-term. The CMake build made it possible to build on all contemporary
> platforms. The documentation switch to Markdown made it possible to build
> without obsolete and unavailable Java libraries. The bugfixes we included
> in 1.12 fixed a number of critical issues. So 1.12 should serve as a usable
> release for the foreseeable future even in the absence of further
> development.
>
> However, I don't see a future for anything beyond 1.12 unless there is a
> dramatic change. XSLT usage is declining, and Xalan-C doesn't support XSLT
> 2.0 and beyond. Rather than letting the current situation linger on
> indefinitely, I wanted to suggest we take stock of where we are, and if
> there is consensus to do so, I think it would be advisable to draw a line at
> this point and end the project gracefully.
I expect that pretty much all of the systems using Xalan these days are legacy
systems. That is, I highly doubt anyone is writing new software that uses it.
So the only involvement I would expect would be the occasional reporting
of a bug that hasn't turned up yet, or build system or compiler version
related issues as systems are upgraded.
As far as I can tell, Xalan works well for what it does, and in my
experience most legacy software doesn't receive a lot of
changes/upgraded other than the bare minimum to stay compliant with
audits, etc.
As you said, XSLT usage (and XML for that matter) is declining, so in my
opinion, doing major feature work (such as supporting newer XSLT
standards) has very little to no payoff from a cost/benefit perspective.
So in that regard, I agree that Xalan isn't likely to see another major
release.
However, there are still users, and sometimes things break as systems get
upgraded. So I guess a question is, do we feel it's worth it to support
these users by way of small maintenance efforts on an as-needed basis, even
though we know that usage is trending down over time, and that there
will never be another major release?
Or, perhaps a bigger question is, will there be enough devs to
continue the project, even for just the small maintenance efforts?
Forgive me if I'm reading too much into your message, but I'm wondering
if you bringing this up is due to wanting to step away from the project?
If that's the case, then ultimately we need to determine if there will
continue to be enough people to conduct votes. If not, then there will
be little choice in the matter.
Personally, I'd like to see Xalan stay around, if for no other reason
than to continue support for those existing legacy users. Though I
realize that's an easy thing for me to say, as I haven't been very
active in the past couple of years (in any of the FLOSS projects I'm
involved with, not just Xalan specifically).
Regardless, thanks for bringing this up. I think it's a good thing for
all projects to ask themselves from time to time.
Best regards,
Bill
--
GPG: 5CDD 0C9C F446 BC1B 2509 8791 1762 E022 7034 CF84
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org
For additional commands, e-mail: dev-help@xalan.apache.org
Re: Future of xalan-c
Posted by Bill Blough <de...@blough.us>.
Hi Roger,
First and foremost, thanks for all the work you've done on Xalan.
On Wed, Jun 22, 2022 at 11:21:11PM +0100, rleigh@codelibre.net wrote:
>
> I don't personally think there is sufficient community involvement or
> developer involvement to realistically support Xalan-C as an active project
> in any sense. There is no one working on it. And while I'm sure there are
> some users, there's next to no active engagement of users as a community.
>
> I've made a good effort to keep the project going for the near- to
> medium-term. The CMake build made it possible to build on all contemporary
> platforms. The documentation switch to Markdown made it possible to build
> without obsolete and unavailable Java libraries. The bugfixes we included
> in 1.12 fixed a number of critical issues. So 1.12 should serve as a usable
> release for the foreseeable future even in the absence of further
> development.
>
> However, I don't see a future for anything beyond 1.12 unless there is a
> dramatic change. XSLT usage is declining, and Xalan-C doesn't support XSLT
> 2.0 and beyond. Rather than letting the current situation linger on
> indefinitely, I wanted to suggest we take stock of where we are, and if
> there is consensus to do so, I think it would be advisable to draw a line at
> this point and end the project gracefully.
I expect that pretty much all of the systems using Xalan these days are legacy
systems. That is, I highly doubt anyone is writing new software that uses it.
So the only involvement I would expect would be the occasional reporting
of a bug that hasn't turned up yet, or build system or compiler version
related issues as systems are upgraded.
As far as I can tell, Xalan works well for what it does, and in my
experience most legacy software doesn't receive a lot of
changes/upgraded other than the bare minimum to stay compliant with
audits, etc.
As you said, XSLT usage (and XML for that matter) is declining, so in my
opinion, doing major feature work (such as supporting newer XSLT
standards) has very little to no payoff from a cost/benefit perspective.
So in that regard, I agree that Xalan isn't likely to see another major
release.
However, there are still users, and sometimes things break as systems get
upgraded. So I guess a question is, do we feel it's worth it to support
these users by way of small maintenance efforts on an as-needed basis, even
though we know that usage is trending down over time, and that there
will never be another major release?
Or, perhaps a bigger question is, will there be enough devs to
continue the project, even for just the small maintenance efforts?
Forgive me if I'm reading too much into your message, but I'm wondering
if you bringing this up is due to wanting to step away from the project?
If that's the case, then ultimately we need to determine if there will
continue to be enough people to conduct votes. If not, then there will
be little choice in the matter.
Personally, I'd like to see Xalan stay around, if for no other reason
than to continue support for those existing legacy users. Though I
realize that's an easy thing for me to say, as I haven't been very
active in the past couple of years (in any of the FLOSS projects I'm
involved with, not just Xalan specifically).
Regardless, thanks for bringing this up. I think it's a good thing for
all projects to ask themselves from time to time.
Best regards,
Bill
--
GPG: 5CDD 0C9C F446 BC1B 2509 8791 1762 E022 7034 CF84