Update of /cvsroot/metamorphosis/krysalis-version/src/documentation/content/xdocs
In directory sc8-pr-cvs1:/tmp/cvs-serv18959/src/documentation/content/xdocs
Modified Files:
index.xml book.xml
Added Files:
faq.xml
Log Message:
Docs & also Constraints
--- NEW FILE: faq.xml ---
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "./dtd/document-v11.dtd">
<document>
<header>
<title>Krysalis-Version Ant Tasks - FAQ</title>
<authors>
<person id="arb_jack" name="Adam R. B. Jack" email="[email protected]"/>
</authors>
</header>
<body>
<note>Ask and they'll be added...</note>
<section><title>How does this differ from a Manifest.mf?</title>
<p>Primarily: It builds a framework for programatic version management...</p>
<p>Automation is the key, have a Version framework to write code on top off. No real reason why the framework can't read manifests to generate version objects (and right now it does).</p>
</section>
<section><title>How does this differ from a <code>java.lang.Package</code>?</title>
<p>Primarily: It builds a framework for programatic version management...</p>
<p>Automation is the key, have a Version framework to write code on top off. No real reason why the framework can't look at Packages to generate version objects (and right now it does).</p>
</section>
<section><title>How does this differ from naming the JAR to include the version?</title>
<p>Again, programatic -- but still -- it ought work w/ tools (like Ruper) to generate files names</p>
<p>Also, when developing classes aren't always in JARs.</p>
<p>Automation is the key, have a Version framework to write code on top off. No real reason why the framework can't read JAR filename formats to generate version objects (but right now it does NOT).</p>
</section>
</body>
</document>
Index: index.xml
===================================================================
RCS file: /cvsroot/metamorphosis/krysalis-version/src/documentation/content/xdocs/index.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** index.xml 17 Feb 2003 06:27:25 -0000 1.4
--- index.xml 17 Feb 2003 18:54:52 -0000 1.5
***************
*** 19,23 ****
<p>Environments
are populated from the system (boot) classpath, app server classpaths, application classpaths,
! and many more. The hierarchy of class loaders is increasingly complex, as are the environments
they produce.</p>
<p>
--- 19,23 ----
<p>Environments
are populated from the system (boot) classpath, app server classpaths, application classpaths,
! and many more. The hierarchies of class loaders are increasingly complex, as are the environments
they produce.</p>
<p>
***************
*** 25,29 ****
lower level packages (XML parsers and such) are often shared. Software components, inside
applications, get whatever the application packager decided upon, combined with the
! deployment environment. Furthermore, operators deply (more than likely unintentionally)
into environments unexpected by developers.
</p>
--- 25,29 ----
lower level packages (XML parsers and such) are often shared. Software components, inside
applications, get whatever the application packager decided upon, combined with the
! deployment environment. Furthermore, operators deploy (more than likely unintentionally)
into environments unexpected by developers.
</p>
***************
*** 31,44 ****
software runs in the environment it finds itself in, which is frequently not
the same as that which it was developed or tested against. Such environments constitute
! vast unknowns, and such deployements/environments are <strong>inherently untested</strong>.
! This is no way to manage small or large software environments.
</p>
! <p><strong>JAR-hell</strong> occurs when software is deployed into a runtime environment that
! is unsuitable, but nothing other than full integration testing would detect this. Ensuring
the compatibility of a variety of dependent packages is duanting, doing it amongst the
variety supported by a hierarchy of complex class loaders, is <strong>inhuman</strong>.
</p>
<p>Manual environment debugging is not something a human ought be forced to waste time
! upon. With that thought <strong>Krysalis-Version was born</strong>...
</p>
<p><strong>Krysalis-version</strong> attempts to automate the tasks of:
--- 31,46 ----
software runs in the environment it finds itself in, which is frequently not
the same as that which it was developed or tested against. Such environments constitute
! vast unknowns, and such deployments/environments are <strong>inherently untested</strong>.
! This is no way to manage large or small software environments.
</p>
! <p><strong>JAR-hell</strong> occurs when software is deployed into a runtime environment which
! is unsuitable, but nothing other than full integration testing would detect this. Having multiple software
! packages dependent upon the same piece of software, with unpredictable incompatibilities, is pure hell.
! Ensuring
the compatibility of a variety of dependent packages is duanting, doing it amongst the
variety supported by a hierarchy of complex class loaders, is <strong>inhuman</strong>.
</p>
<p>Manual environment debugging is not something a human ought be forced to waste time
! upon, let alone every time they deploy. With that thought ... <strong>Krysalis-Version was conceived</strong>.
</p>
<p><strong>Krysalis-version</strong> attempts to automate the tasks of:
***************
*** 48,54 ****
<li>Knowing what <strong>runtime version</strong> of a package exists in a runtime environment.</li>
<li>Determining any <strong>version constraints</strong> that exists on packages, as determined by the author, site operator, or other.</li>
! <li>Evaluating constraints against the runtime environment, automatically detecting
previously 'documented' incompatibilities. (A developer or tester can communicate
known compatibilities and incompatibilities with the software.)</li>
</ul>
<p>As such it implements the following components (cents, ant tasks, tools and plug-ins) on top of it's own API:</p>
--- 50,57 ----
<li>Knowing what <strong>runtime version</strong> of a package exists in a runtime environment.</li>
<li>Determining any <strong>version constraints</strong> that exists on packages, as determined by the author, site operator, or other.</li>
! <li>Evaluating constraints against the runtime environment, automatically detecting
previously 'documented' incompatibilities. (A developer or tester can communicate
known compatibilities and incompatibilities with the software.)</li>
+ <li>Debugging environments.</li>
</ul>
<p>As such it implements the following components (cents, ant tasks, tools and plug-ins) on top of it's own API:</p>
Index: book.xml
===================================================================
RCS file: /cvsroot/metamorphosis/krysalis-version/src/documentation/content/xdocs/book.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** book.xml 17 Feb 2003 06:27:25 -0000 1.5
--- book.xml 17 Feb 2003 18:54:53 -0000 1.6
***************
*** 20,24 ****
<menu label="FAQs">
! <menu-item label="Introduction" href="faq/index.html"/>
<menu-item label="Ant FAQs" href="ant/faq.html"/>
</menu>
--- 20,24 ----
<menu label="FAQs">
! <menu-item label="Version FAQs" href="faq.html"/>
<menu-item label="Ant FAQs" href="ant/faq.html"/>
</menu>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.