Re: Standardized jar manifest entries? (Re: How do you version jar files?)
You should also have a look at the jjar project in Jakarta Commons and also the related discussion threads on jakarta-commons on the subject. There are some common ideas :) -Vincent - Original Message - From: Danny Angus [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Cc: 'Ant Users List' [EMAIL PROTECTED] Sent: Friday, November 16, 2001 2:01 PM Subject: RE: Standardized jar manifest entries? (Re: How do you version jar files?) I like this, a lot, if I had a +1 here I'd use it.. its simple its addresses a real need it would facilitate the production of tools to deal with the nightmare that is .jars and the classpath Ant could check jars against dependencies, and build the jars from scratch only if need be. A new tool could be produced to manage the jar collections on a machine, (an Ant subproject?) and export the list to the classpath, only one entry for each package-name, and that the highest version. Of course that suggests there should be a fourth entry like Package-stability: alpha | beta | release so you could a) see this info, and b) decide what version should be used based on stability. d. -Original Message- From: Jeff Turner [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 12:36 PM snip So how about defining a Jakarta-wide standard subset of jar manifest entries? Something very simple, eg: Package-name: xalan Package-version: 2.2 Package-depends: xerces, 1.4.3 Then write a standard Java tool that can query any conforming jar, and print this info. The dependency information would allow the tool to recursively trace down dependencies, and print a complete list. snip Does that sound workable? Don't be distracted by talk of taxonomies and classloaders.. those are just applications. All I'm proposing right now is 3 standardized manifest entries, and a tool to read them. That alone, if adopted widely, would be of great benefit in a world of proliferating unidentifiable jars. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Business-Oriented XML
on 11/16/01 8:58 PM, Dave Jarvis [EMAIL PROTECTED] wrote: sql select * FROM WIC.FOURNIS WHERE COD_CLIENT=? ORDER BY NOM_FOURNIS /select using value-of expr=#WIC_CLIENT/ /using container name=results/ /sql Why the heck would you want to do this anyway? You have to be nuts to write SQL by hand anymore and why would you want to embed it into your code anyway? You guys have totally lost touch with simple concepts like 'MVC'... Ewww... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Business-Oriented XML
Hello, again.
Neeme Praks wrote:
Have you ever had a look at Apache Cocoon project? That achieves all the
Yes.
benefits you outlined in your paper plus more.
Here are a few items BOX addresses that Cocoon does not (as far as I can
discern; please correct my errors):
o doesn't provide an inherent state-based architecture (it's an aside,
not focus)
o doesn't automatically apply a different view of logic based on the
domain
o extremely complex; it mixes multiple languages and odd syntax (e.g.,
connectDatabase)
o makes it easy to couple presentation and logic (see below)
o lacks an integrated expression parser
o doesn't expose a consistent syntax for doing tasks such as:
- file I/O
- sending XML to remote servers
- calling native code (Java, C, Perl, etc.)
- SQL statements
o cookies, FORM parameters, and URL encoded variables are not treated
uniformly
o doesn't use plain XML (i.e., embeds other language source directly)
If there's interest, I would be more than happy to illustrate a full
cycle of data acquisition (via HTML FORM) to SQL deposit, retrieval, and
final HTML page. For those who enjoy gory details, I've made a brief
comparison of Cocoon and BOX for two very simple examples. The first is
a little counter program, the second shows how to do SQL in both
tongues.
Sincerely,
Dave Jarvis
-=( First Example )=-
]] Cocoon's Logic (18 lines of code; tied to Java) [[
?xml version=1.0?
?cocoon-process type=xsp?
?cocoon-process type=xslt?
?xml-stylesheet href=page-html.xsl type=text/xsl?
xsp:page language=java
xmlns:xsp=http://www.apache.org/1999/XSP/Core;
xsp:logic
static private int counter = 0;
private synchronized int count() {
return counter++;
}
/xsp:logic
page
pI've been requested xsp:exprcount()/xsp:expr times./p
/page
/xsp:page
]] Cocoon's XSP (6 lines of generated code) [[
?xml version=1.0?
?cocoon-process type=xslt?
?xml-stylesheet href=page-html.xsl type=text/xsl?
page
pI've been requested 0 times./p
/page
]] Cocoon's XSL (10 lines of code) [[
?xml version=1.0?
xsl:stylesheet
xsl:output method=html encoding=US-ASCII/
xsl:template match=page
xsl:apply-templates/
/xsl:template
xsl:template match=p
xsl:apply-templates/
/xsl:template
/xsl:stylesheet
BOX code, in my opinion, is much simpler and straightforward, as there
is no intermediary XSP page:
]] BOX's Logic (7 lines of code; tied to XML) [[
?xml version=1.0?
businessLogic
main
session name=count expr=#count + 1/
tag name=count expr=#count/
/main
/businessLogic
]] BOX's XML (4 lines of generated code) [[
?xml version=1.0?
document
count0/count
/document
]] BOX's XSL (7 lines of code) [[
?xml version=1.0?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:output method=html encoding=US-ASCII/
xsl:template match=document
PI've been requested xsl:value-of select=count/ times./P
/xsl:template
/xsl:stylesheet
By adding babel tags around the English text, you automatically get
a stylesheet that is in the viewer's language (based on their browser's
Accept-Language). This is part of the architecture; no extra futzing is
required. BOX makes it difficult to couple logic and presentation. For
example, to write a p tag with logic, you must write tag
name=p/. XSL is where the p tag belongs; not snuggled in with
logic.
Let's look at a slightly more complex example, involving SQL. First
Cocoon, then BOX.
-=( Second Example )=-
]] Cocoon Logic (20 lines of code) [[
?xml version=1.0 encoding='ISO-8859-1' standalone=no?
?xml-stylesheet href=../xsl/wic_fournisseursListe.xsl
type=text/xsl?
?cocoon-process type=xsp?
?cocoon-process type=xslt?
!DOCTYPE page SYSTEM ./librairies/entity.dtd
xsp:page
language=java
xmlns:xsp=http://www.apache.org/1999/XSP/Core;
xmlns:session=http://www.apache.org/1999/XSP/Session;
xmlns:request=http://www.apache.org/1999/XSP/Request;
xmlns:response=http://www.apache.org/1999/XSP/Response;
xmlns:sql=http://www.apache.org/1999/SQL;
xmlns:log=http://www.arctis.com/2000/XSP/Log;
create-session=true
page title=Liste des fournisseurs
xsp:logic
try {
sql:execute-query
connectDatabase;
sql:doc-elementFOURNISSEURS/sql:doc-element
sql:row-elementFOURNISSEUR/sql:row-element
sql:query
SELECT * FROM WIC.FOURNIS
WHERE COD_CLIENT = 'session:get-value name=WIC_CLIENT/'
ORDER BY NOM_FOURNIS
/sql:query
/sql:execute-query
}
catch (Exception e) {
response:send-redirect location=wic_erreur.xml?Langue=FR/
}
/xsp:logic
/page
/xsp:page
]] Cocoon XSL (43 lines of code) [[
?xml version=1.0 encoding='ISO-8859-1'?
?cocoon-format type=text/xsl?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns=http://www.w3.org/TR/xhtml1/strict;
xsl:import
Re: Business-Oriented XML
On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote: Hello, again. Neeme Praks wrote: Have you ever had a look at Apache Cocoon project? That achieves all the Yes. benefits you outlined in your paper plus more. Here are a few items BOX addresses that Cocoon does not (as far as I can discern; please correct my errors): o doesn't provide an inherent state-based architecture (it's an aside, not focus) Nope, they threw out the reactor (state machine) pattern as being too hard to manage. o doesn't automatically apply a different view of logic based on the domain Certainly can :) Have a look at Cocoon 2's class org.apache.cocoon.selection.HostSelector. o extremely complex; it mixes multiple languages and odd syntax (e.g., connectDatabase) That's just your particular XSP, which uses an XML entity connectDatabase; to pull in other XSP. If you put your logic in logicsheets as intended, then your XSP pages are pure XML. o makes it easy to couple presentation and logic (see below) Actually, XSP makes it easy to mix *content* and logic (presentation is in XSLs). o lacks an integrated expression parser o doesn't expose a consistent syntax for doing tasks such as: - file I/O - sending XML to remote servers Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP equivalent of James Strachan's xtags taglib). - calling native code (Java, C, Perl, etc.) - SQL statements o cookies, FORM parameters, and URL encoded variables are not treated uniformly o doesn't use plain XML (i.e., embeds other language source directly) Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2 has a very generic architecture, and I've no doubt that your code could be integrated as an XSP alternative. --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
