Group items tagged

iPOJO is a service component runtime aiming to simplify OSGi application development. It natively supports ALL the dynamism of OSGi. Based on the concept of POJO, application logic is developed easily. Non-functional properties are just injected in the component at runtime. iPOJO strength points are : components are developed as POJO, nothing else is required ! the component model is extensible, so feel free to adapt it to your needs the standard component model manages service providing and service dependencies, and so can require any other OSGi services iPOJO manages the component instance lifecycle and the environment dynamics as it has never been possible iPOJO provides a powerful composition system to create highly dynamic applications iPOJO supports annotations, XML or Java-based API to define the component

" Jump to: navigation, search Welcome to our Wiki. This is the Wiki home page for the Buckminster Component Assembly project, an Eclipse Tools sub project. Buckminster is a component resolution & materialization framework. Its purpose is to get software components for you and materialize them in a context of choice, typically a workspace or file system. This applies whether you are looking at what's available on your local machine, within your development organization or in the public open source cloud. Buckminster reuses existing investments in a wide range of build and source management tools - Maven, ANT, CVS, SVN, PDE, etc. It removes ambiguity from component descriptions, enables component sharing and increases productiveness when applied in development, build, assembly and deploy scenarios. "

"Texo provides JPA annotations, model and template driven development technology powered by EMF for web application (WAR) development projects. Texo uses components currently present in the Eclipse Modeling Framework (EMF) and Eclipse Modeling Framework Technology (EMFT) projects. Texo is a proposed open source component in the Eclipse Modeling Framework Technology (EMFT) project. "

Sapphire - develop UI without wiring individual widgets Little has changed in the way Java desktop UI is written since the original Java release. Technologies have changed (AWT, Swing, SWT, etc.), but fundamentals remain the same. The developer must choose which widgets to use, how to lay those widgets out, how to store the data being edited and how to synchronize the model with the UI. Even the best developers fall into traps of having UI components talk directly to other UI components rather than through the model. Inordinate amount of time is spent debugging layout and data-binding issues. Sapphire aims to raise UI writing to a higher level of abstraction. The core premise is that the basic building block of UI should not be a widget (text box, label, button, etc.), but rather a property editor. Unlike a widget, a property editor analyzes metadata associated with a given property, renders the appropriate widgets to edit that property and wires up data binding. Data is synchronized, validation is passed from the model to the UI, content assistance is made available, etc. This fundamentally changes the way developers interact with a UI framework. Instead of writing UI by telling the system how to do something, the developer tells the system what they intend to accomplish. When using Sapphire, the developer says "I want to edit LastName property of the person object". When using widget toolkits like SWT, the developer says "create label, create text box, lay them out like so, configure their settings, setup data binding and so on". By the time the developer is done, it is hard to see the original goal in the code that's produced. This results in UI that is inconsistent, brittle and difficult to maintain.

If you're just starting to build a JSF 2 application, or you've already started building one and you'd like to add ICEfaces, it's simple to do: Add and tags JSF 2 includes head and body components that can be added to the page by using the and tags. ICEfaces 2 makes use of these components to automatically add certain scripts and other elements to the page, so the and tags are required on any pages of your application that use ICEfaces 2.

Many interactive Web applications are composed of brittle collections of interdependent Web pages. Such applications can be hard to maintain and extend. The Front Controller pattern defines a single component that is responsible for processing application requests. A front controller centralizes functions such as view selection, security, and templating, and applies them consistently across all pages or views. Consequently, when the behavior of these functions need to change, only a small part of the application needs to be changed: the controller and its helper classes.

Many interactive Web applications are composed of brittle collections of interdependent Web pages. Such applications can be hard to maintain and extend. The Front Controller pattern defines a single component that is responsible for processing application requests. A front controller centralizes functions such as view selection, security, and templating, and applies them consistently across all pages or views. Consequently, when the behavior of these functions need to change, only a small part of the application needs to be changed: the controller and its helper classes.

* Buckminster is a set of frameworks and tools for automating build, assemble & deploy (BA&D) development processes in complex or distributed component-based development. Buckminster allows development organizations to define fine-grained "production

"The Maven Archiver is mainly used by plugins to handle packaging. The version numbers referenced in the Since column on this page are the version of the Maven Archiver component - not for any specific plugin. To see which version of Maven Archiver a plugin uses, go to the site for that plugin. "

Hibernate Tutorial. In this hibernate tutorial, we will learn basics of hibernate, inheritance mapping, collection mapping, component mapping, HQL, HCQL, Named Query, Caching and Integration of Hibernate with other frameworks.

The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time. Before you start using SLF4J, we highly recommend that you read the two-page SLF4J user manual. In case you wish to migrate your Java source files to SLF4J, consider our migrator tool which can migrate your project into SLF4J in minutes. In case an externally-maintained component you depend on uses a logging API other than SLF4J, such as commons logging, log4j or j.u.l, have a look at SLF4J's binary-support for legacy APIs.

The Aries project is delivering a set of pluggable Java components enabling an enterprise OSGi application programming model. This includes implementations and extensions of application-focused specifications defined by the OSGi Alliance Enterprise Expert Group (EEG) and an assembly format for multi-bundle applications, for deployment to a variety of OSGi based runtimes. The OSGi R4 V4.2 Enterprise Specification can be found here: http://www.osgi.org/Download/Release4V42 To understand the complete scope of the Aries project, see the Aries proposal document on the incubator wiki.

Aspect-oriented computing is continuing to increase in popularity. The modularity inherent in OSGi and Eclipse offers unique opportunities for managing and applying aspects by supplying them in bundles and directing their application to particular sets of bundles. This incubator work area is dedicated to delivering an integration of aspects and OSGi. The goal is to allow developers to use the Equinox together with AspectJ by combining the benefits of both worlds. Using a load-time weaving extension you are able to add AspectJ aspects to your bundle-based system just by putting them into general OSGi bundles. It does not matter if the pointcuts you defined inside the aspects contain join points that are defined by classes within the same bundle or any other bundle in your installation. The load-time weaving extension will take care that your aspects are woven with the appropriate classes at load-time. To illustrate this lets assume the following situation: You would like to write an aspect that traces something within the JDT plug-ins of Eclipse. Without some kind of load-time aspect weaving you would somehow need to recompile those JDT plug-ins using AJDT (for example) together with your aspect. By using the load-time aspect weaving extension all you need is to implement your aspect and add that bundle to your system. The load-time aspect weaving extension takes care of weaving your aspect with the JDT code as it is loaded. And it doesn't matter if a new JDT is installed by the user later on. The next time your application is started the load-time aspect weaving will take care of weaving your aspect into these bundles as well, if necessary. With this technology is becomes possible to modularize crosscutting concerns across different plug-ins while keeping the idea of separate compilation for bundles. Goals Provide Runtime Modularity and Versioning for Crosscutting Concerns: Aspects are used to implement crosscutting concerns. However such concerns usually compr

The Apache Software Foundation has resigned its seat on the Java SE/EE Executive Committee. Apache has served on the EC for the past 10 years, winning the JCP "Member of the Year" award 4 times, and recently was ratified for another term with support from 95% of the voting community. Further, the project communities of the ASF, home to Apache Tomcat, Ant, Xerces, Geronimo, Velocity and nearly a 100 mainstay java components have implemented countless JSRs and serve on and contribute to many of the JCPs technical expert groups. We'd like to provide some explanation to the community as to why we're taking this significant step.

I think many people have the same feeling (of course including me)

HttpClient is a HTTP/1.1 compliant HTTP agent implementation based on HttpCore. It also provides reusable components for client-side authentication, HTTP state management, and HTTP connection management. HttpComponents Client is a successor of and replacement for Commons HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to upgrade.

Shrinkwrap provides a simple mechanism to assemble archives like JARs, WARs, and EARs with a friendly, fluent API. JavaArchive archive = ShrinkWrap.create(JavaArchive.class,"archive.jar")    .addClasses(MyClass.class,MyOtherClass.class)    .addResource("mystuff.properties"); From there you may deploy directly into any supported integration container like JBoss EmbeddedAS, GlassFish v3 Embedded, Jetty, or OpenEJB.  Or perhaps you'd like to export the archive to a file or exploded directory structure.  Maybe you'd prefer to serialize it over the network to a remote host.  The possibilities are limitless. To boot, ShrinkWrap is the supported deployment mechanism of the Arquillian project, and together we render the testing of true enterprise components amiable as a puppy.  Where Java EE brought a POJO programming model to application development, we've brought it to testing.  You handle your business logic; we'll do the rest. To foster community participation, the majority of documentation and examples are available through our Wiki. Releases are available either via our Downloads section, or through the JBoss Maven Repository, which we recommend is configured in ${userHomeDir}/.m2/settings.xml:

Atmosphere is a POJO based framework using Inversion of Control (IoC) to bring push/Comet and Websocket to the masses! Finally a framework which can run on any Java based Web Server, including Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb and JBoss, Resin, etc. without having to learn how Comet or WebSocket support has been differently implemented by all those Containers. The Atmosphere Framework has both client (JQuery PlugIn) and server components. Servlet 3.0 is supported along with framework like Jersey (natively), GWT (natively), Wicket, Guice, Spring etc. and programming language like JRuby, Gr oovy and Scala. We also support massive scalability with our Cluster plugin architecture (JGroups, JMS/ActiveMQ, Redis, XMPP,i etc.)

This project will mainly contain utility stuff for diverse purpose. Initially it will primarily comprise of Spring Utilities which will perform the following purposes: Load a single resource properties file from pre-configured locations with priority based override. Application context registrar to make the context available to other interested components. Use Cacheable Jersey Client Use a generic RESTful WS Client OpenSearchDescriptor JAX-RS Provider based on XOM based DOM I/O Useful utilities for Atom Syndication Feed, such as pagination over entities, retrieval of resource to certain depth, etc.

Quartz is a full-featured, open source job scheduling service that can be integrated with, or used along side virtually any Java EE or Java SE application - from the smallest stand-alone application to the largest e-commerce system. Quartz can be used to create simple or complex schedules for executing tens, hundreds, or even tens-of-thousands of jobs; jobs whose tasks are defined as standard Java components that may execute virtually anything you may program them to do. The Quartz Scheduler includes many enterprise-class features, such as JTA transactions and clustering. Quartz is freely usable, licensed under the Apache 2.0 license.

The goal of the Eclipse Scout project is making it easy to build distributed enterprise applications based on the Eclipse platform. It consists of a runtime framework providing transparent service communication between the client and backend part and is shipped with a rich set of common user interface components. The user interface is not built for a particular rendering technology but it encapsulates the core functionality into a headless model. GUI factories are available for rendering the client model into a particular target UI platform. SWT and Swing are supported out of the box and an AJAX GUI factory could be easily added. Developing Scout applications is supported by the Scout SDK, a plug-in set built on top of Eclipse PDE and Eclipse JDT. The Scout SDK works directly on the bare Java resources and assists the development task by providing an augmented view on the underlying Java code. Additionally, it comes with a rich set of wizards and operations for modifying the Scout application project just by editing the underlying Java code. There is no meta-data required. Hence a developer can switch between editing resources using Eclipse's standard editors and leveraging the features of Scout SDK at any point in time. Eclipse Scout can be used to create multi-tier client/server applications, standalone client applications or OSGi-based server applications. Basically, there are three main advantages when choosing Scout as your framework for building such applications. First, the Scout runtime is service oriented by design. Almost every functionality is provided as an OSGi service. Every OSGi bundle may make use of them. Second, Scout provides a rich set of UI elements being uncoupled from a particular GUI technology. And third, building distributed client/server applications is as easy as if both parts would run within the same local JVM.