Free jaxb reference implementation software for linux

Objective Modula-2 programming language is a hybrid between Smalltalk and Modula-2 based on the object model and runtime of Objective-C.
The design is an example how native Cocoa/GNUstep support can be added to static imperative programming languages without implementing a bridge.
Objective Modula-2s scope encompasses the design of the Objective Modula-2 programming language and the implementation of a compiler to implement it. The initial compiler will generate Objective-C source code.
Enhancements:
- This code is used to verify ideas and concepts which come up in the course of defining the language.
- It is in an early stage, incomplete and subject to frequent changes.

Procinfo NG is a ground-up rewrite of the procinfo program. Procinfo NGs goal is to make the code more readable (and reusable) and to restore broken functionality of the original program.
The original program was written for Linux 1.0, and updated through 2.2. This version is for 2.6.
Enhancements:
- Updates were made to match what some Linux distributions have done to procinfo-18.
- Support for MSI and XEN interrupts were added.
- Some non-x86 architectures are handled.
- Assorted bugs and 80-character console nonsense were fixed.

Web Reference Database is a bibliographic manager that can import and export references in various formats (including BibTeX, Endnote, MODS XML, and OpenOffice).
It can make formatted lists of citations in HTML, RTF, PDF, or LaTeX, and offers powerful searching, rich metadata, and RSS support
Enhancements:
- This release offers major function enhancements and bugfixes.
- Batch import from various bibliographic formats (including BibTeX, Endnote, RIS, ISI, and MODS XML) is now supported, as is import from a PubMed ID.
- An OpenDocument spreadsheet for use with OpenOffice.org can be exported, and formatted citation lists can be generated as HTML, RTF, PDF, or LaTeX. An SRU/W service and support for unAPI, OpenURL, and COinS metadata have been added.
- These allow the data to be used by the next generation of bibliographic clients.
- A new command line client is also included.

Jiplet is short for Java SIP Servlet. Jiplet Container project is an open-source container for server-side SIP applications. An application developer can create a SIP application written in Java using the Jiplet API and deploy the application in the container.
The container provides a number of framework services including support for SIP message parsing and formatting, scoped variables, authentication and authroization, thread-pooling, logging, custom class loading, management interface, etc. It enables application developer to create server-side SIP applications using a component-based model similar to that envisioned by the J2EE architecture.
In fact, it fits very well with the J2EE paradigm for software development and deployment. The jiplet container software can either be run as a standalone Java application or deployed as a service residing in a J2EE server. When running as a J2EE service, the jiplet container can access many of the features offered by the J2EE server.
In addition, The jiplet container is built with the service provider model in mind. In this model, a service provider can host customized SIP applications from their customers in a secure manner similar to the servlet hosting offered by many service providers.
The jiplet container is very similar to a Java HTTP servlet container in concept. A Java HTTP servlet is a Java class that handles HTTP messages from web browsers. Similarly, a jiplet is a Java class that handles SIP messages from SIP user agents (SIP phones and SIP servers).
A servlet container like Apache Tomcat can host one or more web applications (contexts), each consisting of one or more servlets. Similarly, the jiplet container can host one or more SIP applications (contexts) consisting of one or more jiplets.
Similar to the servlet API authored by Sun Microsystems, the jiplet container provides a set of Java classes that jiplet applications extend or use. The services provided by these classes are very similar to those of the servlet API including scoped variables, request forwarding from one jiplet to another, etc.
As in a servlet container, new jiplet applications, or contexts, can be deployed using a zipped file called spr (war is the Java servlet terminology). Since there are differences between the HTTP and SIP protocols, the servlet and the jiplet containers have some notable differences.
However, the jiplet is not a formal specification like the servlet specification. It is also not an implementation of the SIP servlet specification (JSR 116) authored by Sun and its community of users. There are many similarities between the jiplet and the SIP servlet in terms of features. If you are familiar with SIP servlets, you will feel right at home with the jiplet container.
We are planning to continue developing the jiplet container based on feedback provided by that the open-source community. We are hoping that open-source developers will extend this tool and the specification instead of a committee.
Main features:
- Open-source API for developing server-side SIP applications. Based on the JAIN-SIP API.
- Offers component-based development model.
- Servlet-like development and runtime environment.
- Access to powerful JAIN-API from SIP applications.
- JMX management interface for interfacing with management systems.
- Web-based user interface for managing jiplet applications.
- Support for scoped variables including application, session, request, transaction and dialog-scoped variables.
- Support for forwarding SIP messages from one jiplet to another.
- Container-managed authentication and authorization.
- Support for application timers.
- Can run as a standalone application or it can be integrated with JBOSS as a J2EE service.
- Comprehensive support for the service-provider model.
Enhancements:
- The final release (version 1.2) of the NIST SIP stack Reference Implementation has been incorporated into the Jiplet Container and reference applications.
- The new listening point architecture has been integrated into the Jiplet Container SIP connector.
- One connector can now use more than one IP address for SIP messaging.
- Convenience methods have been added to the Jiplet class for jiplet developers to handle additional listening points and SIP providers.
- The Jiplet Container message proxying has been updated to work in a multi-homed environment.
- The software has been tested with Jboss 4.0.5.GA.

Pluto is the Reference Implementation of the Java Portlet Specfication. The current version of this specification is JSR 168.
Portlets are designed to run in the context of a portal. They are written to the Portlet API which are similar to the Servlet API.
In contrast to servlets, portlets may not do things like sending redirects or errors to browsers directly, forwarding requests or writing arbitrary markup to the output stream to assure that they don?t distract the portal web application which uses them.
Another difference compared to servlets is that portlets rely on portal specific infrastructure functions such as access to user profile information, standard interface for storing/retrieving persistent settings, getting client information, etc. Generally,
portlets are administrated more dynamically than servlets typically are.
A portlet container provides a runtime environment for portlets implemented according to the Portlet API. In this environment portlets can be instantiated, used and finally destroyed. The portlet container is not a stand-alone container like the servlet container; instead it is implemented as a thin layer on top of the servlet container and reuses the functionality provided by the servlet container.
Pluto serves as portlet container that implements the Portlet API and offers developers a working example platform from which they can test their portlets. However, its cumbersome to execute and test the portlet container without a driver, in this case, the portal.
Plutos simple portal component is built only on the portlet containers and the JSR 168s requirements. (In contrast, the more sophisticated, Jetspeed project concentrates on the portal itself rather than the portlet container, and considers requirements from other groups.)
Enhancements:
- Added Pluto 1.1 index page and basic documentation
- PLUTO 164: response contentType can change after getWriter()
- PLUTO 155: URL encoding in pluto 1.0.1-RC4 issue when using apache with jk2
- PLUTO 157: portlet.tld taglib is using jsp version 1.1. JSR168 spec requires JSP version 1.2
- PLUTO 152: Support maven deployment to a remote repository
- PLUTO 130: portlet:namespace fails inside JSTL c:set
- PLUTO-107: Admin portlet fails to add page. Hot deployment now supported.
- PLUTO-92: Deployer strips elements from web.xml (Deploy War Portlet)

The OpenSCADA project aims to create a full-featured and state-of-the-art SCADA (Supervisory Control and Data Acquisition) system to be used in industrial and civil engineering applications to control distributed systems from a master location.
The OpenSCADA project was started in order to create a common standard for SCADA applications. This includes specifications, interfaces and reference implementations.
Enhancements:
- This release has many new features and enhancements to existing functionality.
- The interfaces and the reference implementation were cleaned up a little bit.
- The new upstream version of Utgard was added.

Jaffer project is a Java implementation of Appletalk File Protocol v3.1 using TCP Transport. Performance on a Gigabit network exceeds both Samba and Netatalk. No, Really. Disable debugging.
Quick start:
This program will act like a native Appletalk file server. You must run it as root to use Appletalks normal port 548. But its just as happy running on any unpriviledged port. To access shadow passwords, the server must be run as root.
Your client must be a Mac OS X 10.2 or newer system.
Download a recent build and source code.
Or browse the source in svn.
Run the server:
java -jar jaffer.jar -config [config-file]
or, alternatively, for quick testing:
java -jar jaffer.jar -server [port] [volume-name] [path-to-export]
From the OS X Client, mount the new volume:
mount_afp afp://[user]:[pass]@[host]:[port]/[volume-name] [mount-point]
The [user]:[pass]@ part of the url is optional. If omitted, the mount will be attempted as a Guest user.
Developers:
Most of your work will most likely be done in the AFP_Session class implementing additional AFP calls. When you do this, please be mindful of comments in the code. They are sparse, but very important. When you add call implementations, please make sure they are represented in the AFP_Constants file and annotated with the page number in the AFP3.1 reference PDF.
Most of the implementation is geared towards AFP3.1 which means that some of the helper and common methods are not usable for AFP2.3 or earlier protocols.
Enhancements:
- added zipfs, refactoring for jdk1.5

Xerces2 project is the next generation of high performance, fully compliant XML parsers in the Apache Xerces family.
This new version of Xerces introduces the Xerces Native Interface (XNI), a complete framework for building parser components and configurations that is extremely modular and easy to program.
The Apache Xerces2 parser is the reference implementation of XNI but other parser components, configurations, and parsers can be written using the Xerces Native Interface.
Xerces2 is a fully conforming XML Schema processor.
Xerces2 also provides a complete implementation of the Document Object Model Level 3 Core and Load/Save W3C Recommendations and provides a complete implementation of the XML Inclusions (XInclude) W3C Recommendation. It also provides support for OASIS XML Catalogs.
Xerces2 is able to parse documents written according to the XML 1.1 Recommendation, except that it does not yet provide an option to enable normalization checking as described in section 2.13 of this specification.
It also handles namespaces according to the XML Namespaces 1.1 Recommendation, and will correctly serialize XML 1.1 documents if the DOM level 3 load/save APIs are in use.
Main features:
- eXtensible Markup Language (XML) 1.0 Third Edition Recommendation
- Namespaces in XML Recommendation
- eXtensible Markup Language (XML) 1.1 First Edition Recommendation
- Namespaces in XML 1.1 Recommendation
- XML Inclusions (XInclude) Version 1.0 Recommendation
- Document Object Model (DOM) Level 3 Core, Load and Save, (DOM) Level 2 Core, Events, and Traversal and Range Recommendations
- Simple API for XML (SAX) 2.0.2 Core and Extensions
- Java APIs for XML Processing (JAXP) 1.3
- XML Schema 1.0 Structures and Datatypes Second Edition Recommendations
Enhancements:
- As of this release, Xerces distribution includes the Xalan serializer.
- Xerces and Xalan now share a common serialization codebase.
- The DOM Level 3 serialization support which was in Xerces has been migrated into the Xalan serializer, and Xerces native serializer has been deprecated.
- This release also upgrades the xml-commons resolver to version 1.2 (which provides support for OASIS XML Catalogs 1.1), introduces a few minor features, and fixes several bugs.