The Saxon-B 9.1 package is a collection of tools for processing XML documents.
The main components are:
- An XSLT 2.0 processor, that can be used from the command line, or invoked
from a Java application by use of the standard JAXP API. Saxon can be
integrated with Java applications using the JAXP API, which means it is
possible for a Java application to switch between different XSLT processors
without changing the application code. As well as conforming closely with the
XSLT 2.0 specification, Saxon offers a number of powerful extensions.
- An XPath 2.0 processor accessible via an API to Java applications.
- An XQuery 1.0 processor that can be used from the command line, or invoked
from a Java application by use of an API.
- An XML Schema 1.0 processor. This can be used on its own to validate a schema
for correctness, or to validate a source document against the definitions in
a schema. It is also used to support the schema-aware functionality of the
XSLT and XQuery processors.
So you can use Saxon to process XML by writing XSLT stylesheets, by writing
XQuery queries, by writing Java applications, or by combinations of the
approaches.
===> The following configuration options are available for saxon-devel-9.1.0.8_1,1:
DOCS=on: Build and/or install documentation
DOM4J=off: dom4j support
JDOM=off: Jdom support
XOM=off: XOM support
===> Use 'make config' to modify these settings
Mk/**java.mk: Convert bsd.java.mk to USES
The following features have been added or changed:
- Instead of USE_JAVA use USES=java. This defaults to
USES=java:build,run if NO_BUILD is undefined. Else it defaults to
USES=java:run
- Instead of USE_ANT=yes use USES=java:ant which also implies
USES=java:build
- Instead of JAVA_BUILD=yes use USES=java:build. Does not imply run or
extract
- Instead of JAVA_EXTRACT=yes use USES=java:extract does not imply
build or run
- Instead of JAVA_RUN=yes use USES=java:run does not imply extract or
build
- Instead of USE_JAVA=<version> use USES=java and JAVA_VERSION=<version>
Approved by: mat (portmgr), glewis
Differential Revision: https://reviews.freebsd.org/D48201
Remove WWW entries moved into port Makefiles
Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.
This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.
Approved by: portmgr (tcberner)
Add WWW entries to port Makefiles
It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.
Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.
There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.
(Only the first 15 lines of the commit message are shown above )
Clean up after java/openjdk6 and java/openjdk6-jre removal
java/openjdk6 support was removed from Mk/bsd.java.mk (r512662) and
java/openjdk6 and java/openjdk6-jre were removed from the ports tree
(r512663). Now this patch completely removes remaining stuff from the
ports tree.
PR: 241953 (exp-run)
Reviewed by: glewis
Approved by: portmgr (antoine)
Differential Revision: https://reviews.freebsd.org/D22342
When there is a do-install target, do not use a post-install target, do
everything at once. Sometime, rename post-install into a options helper
target.
I did not fix ports that were such a mess that I could not figure out
what they really wanted to do. I also did not change ports that had
some version of an auto-plist code in post-install, for the same reason.
With hat: portmgr
Sponsored by: Absolight
Fix ports that confused the meaning of WRKDIR and WRKSRC.
PR: 204056
Submitted by: mat
Reviewed by: bapt
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D2735
Remove indefinite articles and trailing periods from COMMENT, plus
minor COMMENT typos and surrounding whitespace fixes. A few Makefiles
where not included as they contain Latin-1 characters that break
the Phabricator workflow. Categories T-V.
CR: D509
Approved by: portmgr (antoine)
Now that the Java 1.3 and Java 1.4 ports are deprecated and will expire soon,
remove support for them from bsd.java.mk. As Jikes is not available in Java 1.5
or higher, remove it from bsd.java.mk too (suggested by hq@) and from the ports
which used it (only occurences were USE_JIKES=no). Support for the Blackdown VM
is also removed, as it is not available in Java 1.5 and higher.
Also remove the mapping from Java 1.1-1.4 to Java 1.5+ in bsd.java.mk to detect
old, broken ports; therefore bump the minimal value of JAVA_VERSION to 1.5.
While here, replace static values of JAVA_VERSION in files/*.in by
%%JAVA_VERSION%% .
PR: ports/158969
Submitted by: rene
Tested on: pointyhat-west -exp
Bump portrevision due to upgrade of devel/gettext.
The affected ports are the ones with gettext as a run-dependency
according to ports/INDEX-7 (5007 of them) and the ones with USE_GETTEXT
in Makefile (29 of them).
PR: ports/124340
Submitted by: edwin@
Approved by: portmgr (pav)
- Update to 8.7
- Use 'exec' in the launcher shell script to comply with Porter's Handbook
guidelines
- Use OPTIONS to add support for JDom and XOM [1]
PR: 86093 [1]
Suggested by: Rene Ladan <r.c.ladan@student.tue.nl> [1]
Update to 8.6.1 (maintenance release for the 8.6 branch)
Saxon 8.6.x is a complete and conformant implementation of the Candidate
Recommendations for XSLT 2.0, XQuery 1.0, and XPath 2.0 published on 3 November
2005
- Update 8.5.1 (maintenance release)
- No longer install saxon8-jdom.jar ; it will be back soon but as an OPTIONal
component
PR: 86093
Submitted by: Rene Ladan <r.c.ladan@student.tue.nl>
- Back out version upgrade from last commit: Saxon 8.2 requires JAXP 1.3 which
it is not possible (AFAICT) to port for now, due to the GUI installer used by
Sun. JAXP 1.3 is included in J2SE 1.5 so Saxon 8.2 will be back in the ports
tree when we get a working JDK 1.5.
- Rename a temporary variable to keep portlint(1) happy
- Removed unnecessary run dependency on Xerces-J (given XML APIs and some XML
parser are included in JDK 1.4+ Standard API)
- Tweaked CLASSPATH in launcher script: Only Saxon installed JARs are indeed
required for command-line operations (see above)
- Added some more "" in launcher script to ensure spaces in paths and args will
not break anything
- Update to 8.1.1
- New launcher script 'saxon-xquery' to perform XQuery queries
- PREFIX -> LOCALBASE in launcher script
- (CP ; CHOWN) -> CPIO
- Register run dependency on Xerces-J
- Dynamic plist
- More relevant homepage URL in pkg-descr
- Take maintainership
. Alter the saxon.sh script to set the JAVAVM variable to the value chosen
by bsd.java.mk during the build. This fixes a problems where the
javavmwrapper (used by the script) could have potentially picked an
incorrect JDK to use.
. Bump PORTREVISION.
PR: 69157
Submitted by: Herve Quiroz <herve.quiroz@esil.univ-mrs.fr>
. Add a saxon-devel port for the development version of Saxon:
"The Saxon 8.0 package is a collection of tools for processing XML documents.
The main components are:
- An XSLT 2.0 processor, that can be used from the command line, or invoked
from a Java application by use of the standard JAXP API. Saxon can be
integrated with Java applications using the JAXP API, which means it is
possible for a Java application to switch between different XSLT processors
without changing the application code. As well as conforming closely with the
XSLT 2.0 specification, Saxon offers a number of powerful extensions.
- An XPath 2.0 processor accessible via an API to Java applications.
- An XQuery 1.0 processor that can be used from the command line, or invoked
from a Java application by use of an API.
- An XML Schema 1.0 processor. This can be used on its own to validate a schema
for correctness, or to validate a source document against the definitions in
a schema. It is also used to support the schema-aware functionality of the
XSLT and XQuery processors.
So you can use Saxon to process XML by writing XSLT stylesheets, by writing
XQuery queries, by writing Java applications, or by combinations of the
approaches."
PR: 68637
Submitted by: Herve Quiroz <herve.quiroz@esil.univ-mrs.fr>