You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@juddi.apache.org by al...@apache.org on 2017/09/23 18:04:25 UTC

[2/3] juddi git commit: JUDDI-975 updates the site descriptor to use the maven fluidio skin, adds the jira changes plugin

http://git-wip-us.apache.org/repos/asf/juddi/blob/ce80f7c2/src/site/xdoc/thanks.xml
----------------------------------------------------------------------
diff --git a/src/site/xdoc/thanks.xml b/src/site/xdoc/thanks.xml
deleted file mode 100644
index d52c7c3..0000000
--- a/src/site/xdoc/thanks.xml
+++ /dev/null
@@ -1,59 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!--
- * Copyright 2001-2009 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *      http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- *
- */ -->
-<document>
-  <properties>
-    <title>Donated Software Licenses</title>
-  </properties>
-  <body>
-    <section name="Donated Software Licenses">
-	    <p>The jUDDI Project uses a few commercial products in the development 
-	    process. We are grateful for the community licenses which were provided 
-	    to the project at no costs. 
-	    </p>
-    </section>
-
-	<section name="JIRA">
-	    <p>
-	    Bug and issue tracker <a href="http://www.atlassian.com/software/jira/">
-	    Jira by Atlassion</a>.
-	    </p>
-    </section>
-
-    <section name="JProfiler">        
-      <p>
-         Java profiler <a href="http://www.ej-technologies.com/products/jprofiler/overview.html">
-         JProfiler by ej-technologies</a>.
-      </p>
-    </section>
-      
-    <section name="XLT">            
-         Xceptance LoadTest (XLT) for both regression as well as load tests by <a href="http://www.gqpartners.com/">Global Quality Partners, LLC</a> 
-         and <a href="http://www.xceptance.com/">Xceptance 
-         Software Technologies, Inc.</a> Load and performance tests were created and 
-         executed by our sponsors using Xceptance LoadTest (XLT) from Xceptance 
-         Software Technologies, Inc., of which Global Quality Partners, LLC is 
-         the exclusive North American distributor. To enable the Apache jUDDI 
-         project to continue and extend these tests, Xceptance has provided 
-         an unlimited XLT license and donated the source code of the test suite 
-         to the Apache jUDDI project. XLT is built and scripted in pure Java, 
-         providing a highly scalable and easily adaptable technology that can be 
-         used across development, quality assurance, and consulting teams.
-    </section>
-      
-  </body>
-</document>

http://git-wip-us.apache.org/repos/asf/juddi/blob/ce80f7c2/src/site/xdoc/usersguide.xml
----------------------------------------------------------------------
diff --git a/src/site/xdoc/usersguide.xml b/src/site/xdoc/usersguide.xml
deleted file mode 100644
index 8336e95..0000000
--- a/src/site/xdoc/usersguide.xml
+++ /dev/null
@@ -1,195 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!--
- * Copyright 2001-2009 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *      http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- *
- */ -->
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "http://forrest.apache.org/dtd/document-v12.dtd">
-<document>
-  <properties>
-    <title>jUDDI User's Guide</title>
-  </properties>
-  <body>
-
-    <anchor id="requirements"/>
-    <section name="Requirements">
-      <p>jUDDI is a pure Java web application and as such can be deployed to
-        any application server or servlet engine that supports version 2.1 or
-        later of the servlet API. If you need an application server, we
-        recommend <link href="http://jakarta.apache.org/tomcat/">Jakarta
-        Tomcat</link>.  Note also that jUDDI requires Java 1.3 or later. As
-        with any Java web application, deployment to your application server
-        or servlet engine will vary on a product-by-product basis.
-      </p>
-      <p>Instructions for deploying jUDDI to several application servers have
-        been donated and are available in the <link href="http://wiki.apache.org/ws/jUDDI">HOW-TO</link>
-        section of the jUDDI wiki.
-      </p>
-      <p>jUDDI also requires an external datastore in which to persist the 
-        registry data it manages.  Typically this is a relational database
-        management system such as MySQL, Oracle or DB2. Support for several 
-        open source and commercial database products are included. See the 
-        section below titled <link href="#datastore">Persistence</link> for 
-        more information.
-      </p>
-    </section>
-
-    <anchor id="config"/>
-    <section name="Configuration">
-      <p>To properly configure and deploy jUDDI it will be helpful to understand
-        a bit about it's architecture. jUDDI consist of a core request processor
-        that unmarshalls incoming UDDI requests, invoking the appropriate UDDI
-        function and marshalling UDDI responses (marshalling and unmarshalling
-        is the process of converting XML data to/from Java objects).
-      </p>
-      <p>To invoke a UDDI function jUDDI employs the services of three
-        configurable sub-components or modules that handle persistence (the
-        DataStore), authentication (the Authenticator) and the generation of
-        UUID's (the UUIDGen). jUDDI is bundled and pre-configured to use
-        default implementations of each of these modules to help your registry
-        up and running quickly. These sub-components and a description of 
-        the default implementations are described below.
-      </p>
-      <p>Several public Java interfaces for creating your own DataStore,
-        Authenticator and UUIDGen module implementations are available. Please
-        see the <link href="#moddev">module development</link> section of this 
-        guide for more information regarding jUDDI module development.
-      </p>
-    </section>
-
-    <anchor id="datastore"/>
-    <section name="Persistence (jUDDI DataStore)">
-      <p>jUDDI needs a place to store it's registry data so it should come as 
-        no surprise that jUDDI is pre-configured to use JDBC and any one of 
-        several different DBMSs to do this.
-      </p>            
-      <p>The process of setting this up is straight forward. Start by creating 
-        a new jUDDI database using the instructions for your preferred DBMS 
-        which you will find in the 'sql' directory of your jUDDI distribution. 
-        At the time of this writing instructions for the following products 
-        were available:
-      </p>
-      <p>
-        <ul>
-          <li>MySQL</li>
-          <li>DB2</li>
-          <li>HSQLdb (HypersonicSQL)</li>
-          <li>Sybase</li>
-          <li>PostreSQL</li>
-          <li>Oracle</li>
-          <li>TotalXML</li>
-          <li>JDataStore (Borland)</li>
-        </ul>
-      </p>
-      <p>If support for your DBMS is not listed you might try posting a message
-        to the juddi-user list to see if someone has already developed support
-        for it.  You can also try to create the scripts yourself by using the 
-        instructions for a supported DBMS as a guide. Please consider 
-        contributing your work back to the project so the next person won't 
-        have the same issue.
-      </p>      
-      <p>To complete the DataStore set up you'll need to configure a JNDI
-        Datasource with a name of <b>'jdbc/juddiDB'</b> in the application 
-        server or servlet engine that you're deploying to. Datasource setup 
-        varies on an product-by-product basis so review documentation for 
-        your application server. If you're deploying to Jakarta Tomcat,  take a 
-        look at Tomcat's <link  href="http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-howto.html">JNDI 
-        Datasource HOW-TO</link> for assistance.
-      </p>
-    </section>
-
-    <anchor id="authenticator"/>
-    <section name="Authentication (jUDDI Authenticator)">
-      <p>Authenticating a jUDDI publisher is a two-step process. The first step
-        confirms that the ID/password combination provided by the user in a 
-        get_authToken request is valid. The default Authenticator implementation 
-        simply approves any authentication attempt. It is expected that a 
-        typical jUDDI deployment will use an external authentication 
-        mechanism.  It is our hope that additional jUDDI authentication 
-        implementations will be developed by jUDDI users as they determine how 
-        they would like authentication to take place in their particular 
-        environment. See the jUDDI Developers Guide for more information on 
-        developing a custom jUDDI authentication module for your environment.
-      </p>
-      <p>The second step confirms that the publisher has been defined to
-        jUDDI. A publisher is said to be defined when a row identifying the
-        publisher exists in the PUBLISHER table of the jUDDI datastore. At the
-        moment the only way to do this is via SQL. An example of defining a
-        new publisher named John Doe would look like this:
-      </p>
-      <p>
-        <b>
-        <pre>        
-          INSERT INTO PUBLISHER (PUBLISHER_ID,PUBLISHER_NAME,ADMIN,ENABLED)
-          VALUES ('jdoe','John Doe','false','true');
-        </pre>
-        </b>
-      </p>
-      <p>The PUBLISHER table consists of several columns but only four of them
-        are required and they are defined as follows:
-      </p>
-      <p>
-        <table>
-         <tr><th>Column Name</th><th>Description</th></tr>
-         <tr><td>PUBLISHER_ID</td><td>The user ID the publisher uses when authenticating. IMPORTANT: This should be the same value used to authenticate with the external authentication service.</td></tr>
-         <tr><td>PUBLISHER_NAME</td><td>The publisher's name (or in UDDI speak the Authorized Name).</td></tr>
-         <tr><td>ADMIN</td><td>Indicate if the publisher has administrative privileges. Valid values for this column are 'true' or 'false'. The ADMIN value is currently not used.</td></tr>
-         <tr><td>ENABLED</td><td>Indicate if the publishers account is enabled and eligible for use.</td></tr>
-        </table>
-      </p>
-      <p>The jUDDI web application will (eventually) be extended to facilitate
-        the Publisher creation process. The value of the ADMIN column in the
-        PUBLISHER table above will be used to determine who has the privilege
-        to create new jUDDI publishers.
-      </p>
-    </section>
-
-    <anchor id="uuidgen"/>
-    <section name="UUID Generation (jUDDI UUIDGen)">
-      <p>There's nothing for you to do here but I thought I'd offer a little
-        information about how, why and where jUDDI makes use of UUID generation.
-      </p>
-      <p>The UDDI specification indicates that each Business, Service, Binding
-        and TModel (Technical Model) is to be uniquely identified by a
-        Universally Unique ID (UUID). Additionally, jUDDI also uses the UUID
-        generator to create AuthTokens.
-      </p>
-      <p>Generation of a UUID typically requires access to hardware level
-        information that (unfortunately) is not easily accessible from Java.
-        Fortunately, the UUID specification offers an alternative method for
-        generating these ID's when this hardware information is not present.
-        By default the jUDDI implements this alternative method.
-      </p>
-    </section>
-
-    <anchor id="logging"/>
-    <section name="Logging">
-      <p>When deploying jUDDI you may wish to make changes to the
-       juddi.properties and log4j.properties files. These files are located in
-       the juddi webapp's WEB-INF/classes directory. They're here because
-       they need to be in the classpath for jUDDI to locate and load them at
-       runtime. One Log4j property value that you'll most likely want to set
-       is log4j.appender.LOGFILE.File which specifies the name and location of
-       the jUDDI log file.
-      </p>
-    </section>
-
-    <anchor id="moddev"/>
-    <section name="Module Development">
-      <p>Coming Soon.
-      </p>
-    </section>
-
-  </body>
-</document>

http://git-wip-us.apache.org/repos/asf/juddi/blob/ce80f7c2/src/site/xdoc/who.xml
----------------------------------------------------------------------
diff --git a/src/site/xdoc/who.xml b/src/site/xdoc/who.xml
deleted file mode 100644
index f01d6ff..0000000
--- a/src/site/xdoc/who.xml
+++ /dev/null
@@ -1,47 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!--
- * Copyright 2001-2009 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *      http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- *
- */ -->
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "http://forrest.apache.org/dtd/document-v12.dtd">
-<document>
-  <properties>
-    <title>The jUDDI project team</title>
-  </properties>
-  <body>
-    
-    <section name="Who We Are">
-      <p>
-        The jUDDI Project operates on a meritocracy: the more you do,
-        the more responsibility you will obtain. This page lists all
-        of the people who have gone the extra mile and are
-        Committers. If you would like to get involved, the first step
-        is to join the mailing lists.
-      </p>
-      <p>
-        We ask that you please do not send us emails privately asking
-        for support. We are non-paid volunteers who help out with the
-        project and we do not necessarily have the time or energy to
-        help people on an individual basis. Instead, we have setup
-        mailing lists which often contain hundreds of individuals who
-        will help answer detailed requests for help. The benefit of
-        using mailing lists over private communication is that it is
-        a shared resource where others can also learn from common
-        mistakes and as a community we all grow together.
-      </p>
-    </section>
-
-  </body>
-</document>


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@juddi.apache.org
For additional commands, e-mail: commits-help@juddi.apache.org