Re: Task for Reading POMs

2004-08-18 Thread Kyle Adams
Brett Porter wrote:

 This probably isn't going to be as easy as you hope - for instance
 POMs often rely on property interpolation and inheritence of other
 files.

Which is why I'm extending XmlProperty.  XmlProperty provides the
property interpolation (with semanticAttributes turned on) and by
extending it, my custom task can handle inheritance.  But I'd be open to
other methods of reading a POM, including...

 Is there any reason not to use org.apache.maven.MavenUtils?

Good question (though perhaps better suited for Maven's developer
list).  In a perfect world, I'd love to use the same classes that Maven
uses for reading in POMs.  In that same vein, I'd love to see Java tool
makers standardize on a schema for project descriptors, so you could
have one POM that Eclipse, JBuilder, Java Studio Creator, Ant, Maven,
and [insert your favorite IDE/project/build tool here] would know how to
read.

But...

Those classes are currently bundled up into the Maven JAR, and there's
a high degree of dependency on other Maven-specific classes.  I ran into
this while writing Ant tasks that wrapped around Maven's dependency
verifier and the artifact plugin.  Looking at MavenUtils code, it
appeared to be the same situation (correct me if I'm wrong).

I'd jump all over using those classes if they were separated out into a
sort of jPOM project :-) with a generic API for reading/writing a
standard POM and a lightweight, non-Maven-specific, library-type JAR.  I
think that would also make a standardized POM much more attractive to
Java tool developers.

Am I out in left field here, or does that sound reasonable?

Kyle

_

Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Task for Reading POMs

2004-08-16 Thread Kyle Adams
Brett Porter wrote:

 I think that's what JAM does. Don't know the URL off the top of my
head.

The URL is http://www.javagen.com/jam.jsp and I'm actually working on
this task in relation to JAM :-)  JAM can't directly read a POM; rather
there are Maven plugins provided as part of JAM that allow you to
generate JAM-specific config files from a POM.  In the interest of
tighter integration with Maven, I'd like to create an Ant task that
could read the POM directly and bypass the keep JAM config files in
sync with POM step.

I've been looking around XmlProperty and noticed a bit of oddness when
it comes to the visibility of the methods.  Some, like
addNodeRecursively(Node, String, Object) are private.  Then
addNodeRecusively calls processNode(Node, String, Object), which is
public.  Finally, addNodeRecursively(Node, String) uses the default
package visibility.

It would be nice (from my perspective) if all of the methods above were
protected, making it easy for me to extend XmlProperty and create a
PomProperty task.  Is there a ryhme or reason for their existing
visibilities that I'm missing?

Kyle

_

Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Task for Reading POMs

2004-08-13 Thread Kyle Adams
Before I go re-inventing the wheel, I wanted to check and see if anyone
else was working/had worked on scratching the same itch:

I'd like to be able to utilize Maven's POM for describing a project;
XmlProperty gets me most of the way there, but there are a few things
(like imported POMs) that it doesn't handle.  Consequently I'd like the
write a PomProperty (probably extending XmlProperty) to handle these
extra bits of functionality.

Thanks,
Kyle

_

Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: XML, XSL, and Ant

2003-10-25 Thread Kyle Adams
 Kyle should receive an updated jar any time now.

Indeed I did (though it took awhile before I un-busied enough to test it).

And indeed it works quite nicely, for both resolving entities in a stylesheet, 
and resolving entities/dtds in anything xsl:import'ed, xsl:includ'ed and 
document()'ed.

Nice fix!

Kyle

_

Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: XML, XSL, and Ant

2003-10-23 Thread Kyle Adams
 We should be able to change this if SAXSource is supported, I'll take
 a stab at it - but I will need testers before I'm willing to merge my
 changes into the 1.6 branch.  If I'd send you a changed ant-trax.jar,
 could you test it in your Ant 1.6beta environment?

No problem - I've got a simple test case already setup that's currently 
failing, so I'm all set for testing :-)

Kyle

_

Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



XML, XSL, and Ant

2003-10-22 Thread Kyle Adams
This is an extension of a thread that originally began in users 
(http://marc.theaimsgroup.com/?t=10667642568r=1w=2), but is moving more 
towards a dev-type discussion.

I've noticed some odd behaviors in how style utilizes xmlcatalog - I'm not 
sure if they're bugs, or just the way things work.

1) xmlcatalog only applies to source XML document - if there are 
entities/dtds in the stylesheet, these can't be resolved by xmlcatalog.  
Confirmed on Ant 1.5.3/Xalan 2.2, D11/Xerces 2.3.0 and Ant 1.6, B2/Xalan 
2.5.1/Xerces 2.5.0/10-22-2003 snapshot of commons-resolver.

2) Any XML documents accessed via the document() function in the XSL will not 
have their entities/dtds resolved.  Confirmed on Ant 1.5.3/Xalan 2.2, 
D11/Xerces 2.3.0

Are these just the way things are with resolvers, or should the resolver be 
catching entities/dtds in the XSL and/or any XML documents validated during a 
transformation?

Thanks,
Kyle

_

Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Adding support for XMLCatalog in EjbJar

2003-05-21 Thread Kyle Adams
I've taken a first stab at adding support for nested xmlcatalog
elements within ejbjar, but I'm running into some problems I thought
I'd run by the list.

First glance, it appeared pretty easy.  Add a few methods and insert
the following bit of code in the execute method:

if (xmlCatalog != null) {
saxParser.getXMLReader().setEntityResolver(xmlCatalog);
}

Since saxParser gets passed into the various vendor-specific deployment
tool classes, I thought that would do the trick.  But it's not (why
would I be writing this otherwise :-) ?).  The problem is that I'm not
familiar enough with SAX; previous hacking involved adding XMLCatalog
support to tasks that used DOM.  Also, I'm not intimately familiar with
the inner workings of the org.apache.tools.ant.taskdefs.optional.ejb.*
classes.

So I thought I'd throw this out there and see if I'm doing something
stupid/easily fixed.  Diff included below for full disclosure.

Thanks,
Kyle

===

--- EjbJar.java.old 2003-05-21 16:54:44.0 -0400
+++ EjbJar.java 2003-05-21 16:52:50.0 -0400
@@ -74,6 +74,7 @@
 import org.apache.tools.ant.types.Path;
 import org.apache.tools.ant.types.EnumeratedAttribute;
 import org.apache.tools.ant.types.FileSet;
+import org.apache.tools.ant.types.XMLCatalog;
 
 /**
  * Provides automated EJB JAR file creation.
@@ -226,6 +227,18 @@
 /** The list of deployment tools we are going to run. */
 private ArrayList deploymentTools = new ArrayList();
 
+/** for resolving entities such as dtds */
+private XMLCatalog xmlCatalog = new XMLCatalog();
+
+
+/**
+ * Add the catalog to our internal catalog
+ *
+ * @param xmlCatalog the XMLCatalog instance to use to look up
DTDs
+ */
+public void addConfiguredXMLCatalog(XMLCatalog xmlCatalog) {
+this.xmlCatalog.addConfiguredXMLCatalog(xmlCatalog);
+}
 
 /**
  * Add a deployment tool to the list of deployment tools that will
be
@@ -538,6 +551,14 @@
 }
 
 /**
+ * Initialize internal instance of XMLCatalog
+ */
+public void init() throws BuildException {
+super.init();
+xmlCatalog.setProject(getProject());
+}
+
+/**
  * Invoked by Ant after the task is prepared, when it is ready to
execute
  * this task.
  *
@@ -574,6 +595,9 @@
 SAXParserFactory saxParserFactory =
SAXParserFactory.newInstance();
 saxParserFactory.setValidating(true);
 SAXParser saxParser = saxParserFactory.newSAXParser();
+if (xmlCatalog != null) {
+   
saxParser.getXMLReader().setEntityResolver(xmlCatalog);
+}
 
 DirectoryScanner ds =
getDirectoryScanner(config.descriptorDir);
 ds.scan();



Re: J2EE Deployment Models

2003-05-20 Thread Kyle Adams
Gah - this really was supposed to go to the ant users mailing list.  My
apologies; I just set my mind on autopilot.

Resending... now.

Kyle


J2EE Deployment Models

2003-05-19 Thread Kyle Adams
This is not an Ant-specific question, but I'm not aware of any general 
build/deploy/promotion practices e-mail lists, and this is the closest
thing to that.  If 
someone does know of such a list/newsgroup, let me know and I redirect
my query 
as appropriate.

Our current deployment for J2EE apps is to use an EAR.  Inside the
EAR's base 
directory, we have a lib directory, which contains JARs that the EJB
JARs may 
reference in their Class-Path entry (ie, fop.jar, log4j.jar, etc.). 
Also within the base 
directory are all the WARs and EJB JARs that make up the EAR.

We have a third party source providing us with an EAR that uses a
radically 
different deployment model, and I'd be curious to hear opinions and
thoughts on it.  
Within the EAR the application is split up into three different
groupings: 
presentation, common, and service tiers.  Each group is a JAR file,
containing 
within it whatever EJB JARs or WARs fall within that logical grouping. 
So there are 
3 layers of packging that occur - the EJBs and WARs get wrapped up into
a 
generic JAR by group, and then the 3 groups composing the application
get 
wrapped up into an EAR.

As build manager and deployer, our build, deploy, and promotion
processes (and by 
that, I mean the automated scripts, including Ant files) would face
signifigant 
change to support this new model.  I also have concerns about how
standard or 
non-standard this type of deployment model is.  We really try to stick
close to the 
specs for J2EE and avoid anything that ties us to non-standard
practices, or 
vendor lock-in.

Thoughts?


Thanks,

Kyle Adams
Developer, Gordon Food Service


XLTC task?

2003-04-04 Thread Kyle Adams
Just checking before I re-invent the wheel - is anyone else aware of an
Ant task for compiling XSL stylesheets into translets?

Kyle A.