[CJ-dev] commonjava-projects/commonjava-enterprise-services/projects/service-manager project.properties,NONE,1.1 project.xml,NONE,1.1

[John C. <joh...@co...>]

Update of /cvsroot/commonjava/commonjava-projects/commonjava-enterprise-services/projects/service-manager
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10019/projects/service-manager

Added Files:
	project.properties project.xml 
Log Message:
modified to make core, ejb, jms, jdbc, raw-service sub-projects, and to add JNDI name rewriting to the core ServiceLocator.

--- NEW FILE: project.properties ---
maven.username=maven

maven.repo.remote=http://www.ibiblio.org/maven,http://www.commonjava.org/maven
maven.repo.central=www.commonjava.org
maven.repo.central.directory=/usr/local/maven-repository

cactus.home.tomcat4x=/usr/local/j2ee/tomcat/current

maven.war.src=src/test-config
maven.junit.usefile=${basedir}/junit.log


--- NEW FILE: project.xml ---
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE project [
   <!ENTITY core-deps SYSTEM "../core/core-deps.ent">
]>

<project>
  <pomVersion>3</pomVersion>
  <id>commonjava-es-serviceman</id>
  <name>Enterprise Services</name>
  <groupId>commonjava</groupId>
  <currentVersion>2.2</currentVersion>
  <organization>
    <name>CommonJava Open Component Project</name>
    <url>http://www.commonjava.org</url>
  </organization>
  <inceptionYear>2002</inceptionYear>
  <package>org.commonjava.j2ee.services.svc</package>
  
  <description>
    Enterprise Services simply provides a lookup mechanism for EJBs DataSource's, JMS, and generic
    JNDI-bound service objects. It uses config-jndi to store and configure the various JNDI profiles
    to be used for each type of lookup, with the possibility of using a different JNDI tree for each
    type. Additionally, each lookup type also supports local lookups, which simply uses an empty
    InitialContext constructor for the JNDI access. 
    
    In the future, it will also provide a mapping service implicitly, which will allow code to 
    depend upon a certain set of pseudo-JNDI binding names, which then resolve via mappings to "real"
    JNDI bindings for the components in question. This will decouple the development process from the
    deployment process, in that the hard-coded (in one place or another) names will be separated from 
    the runtime names.
  </description>
  
  <dependencies>
    &core-deps;
  </dependencies>
  
  <build>
    <sourceDirectory>src/main/java</sourceDirectory>
    <unitTestSourceDirectory>src/test/java</unitTestSourceDirectory>
    <unitTest>
      <resources>
        <resource>
          <directory>src/main/resources</directory>
          <includes>
            <include>META-INF/**</include>
          </includes>
        </resource>
        <resource>
          <directory>src/test/resources</directory>
          <includes>
            <include>configuration.xml</include>
          </includes>
        </resource>
      </resources>
    </unitTest>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <includes>
          <include>META-INF/**</include>
        </includes>
      </resource>
    </resources>
  </build>
  
</project>