Re: Google Summer of Code, Apache ANT project ideas?
On Jun 6, 2005, at 2:53 PM, Stephane Bailliez wrote: Erik Hatcher wrote: I like the ideas of using backport175 and/or qdox. I think either of these approaches will be much lighter and faster than using XDoclet. AFAIK backport175 and XDoclet both make use of qdox. Unless XDoclet rearchitected since I last used it, it uses a custom parser, not qdox. XDoclet2 is a different story, but as far as I know that has never been that viable to use. What would backport175 or XDoclet bring that cannot be done with qdox in our case ? backport175 would allow us to use JDK 1.5-looking annotations making it trivial to convert to true annotations later. This could be done with pure qdox, sure, but it would require reimplementing what has already been done in backport175 on top of qdox. XDoclet provides a sophisticated templating mechanism also, which neither backport175 nor qdox have built in. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
Erik Hatcher wrote:
Doug - I've added it as project ID ant-xdocs to that wiki page. As for
technologies - I'm not sure if Velocity and XDoclet are the best
technologies to use right now. Let's solicit input from others here on
their architecture ideas.
+1 to XDoclet; the only alternative would be Java1.5 annotations and we
do not want to go there.
If it has one problem, its footprint is atrocious: You have to set the
ANT_OPTS env variable up to get enough memory. Now, if Xdoclet forked...
0 to velocity.
One thing I do want is automated generation of task docs for third party
projects. I actually use the existing sandbox to do this, but it isnt
ideal...I have to ant into the sandbox, do some fixup before and
after. That is painful, and only works when the Ant CVS tree is checked
out...
!-- this target does the extra xdocs initialisation --
target name=init-xdocs depends=init
property name=build.antdocs.dir location=${build.dir}/xdocs/
property name=gen.dir location=${build.antdocs.dir}/gen/
property name=gen.dir location=${build.antdocs.dir}/gen/
property name=build.docs.dir location=${build.antdocs.dir}/docs/
property name=build.xdocs.dir
location=${build.antdocs.dir}/xdocs/
property name=xdocs.dir location=${env.ANT_HOME}/proposal/xdocs /
property name=src.package value=org/smartfrog/tools/ant/ /
path id=xdoclet.extra.classpath
path refid=smartfrog.classpath/
pathelement location=${smartfrog.tasks.jar}/
/path
property name=xdoclet.extra.classpath.asprop
refid=xdoclet.extra.classpath/
/target
!-- probe for xdocs, which is only in CVS, not redist packages --
target name=probe-xdocs depends=init-xdocs
available property=xdocs.found file=${xdocs.dir}/build.xml/
/target
target name=want-xdocs depends=probe-xdocs
fail unless=xdocs.found
We need the proposal/xdocs source tree from Ant in
${env.ANT_HOME}/proposal/xdocs
/fail
/target
target name=xdocs depends=want-xdocs,package
description=Run xdoclet over the ant tasks to create doc pages
if=xdocs.found
echo
running xdocs with classpath=${xdoclet.extra.classpath.asprop}
/echo
ant inheritAll=${ant.inheritAll} inheritRefs=${ant.inheritRefs}
dir=${xdocs.dir}
target=gen-and-prepare-for-docs
property name=src.dir location=${src.package}/
property name=src.root location=src/
property name=xdoclet.extra.classpath
value=${xdoclet.extra.classpath.asprop}/
property name=gen.dir location=${gen.dir}/
property name=xdocs.dir location=${build.xdocs.dir}/
property name=build.docs.dir location=${build.docs.dir}/
/ant
/target
target name=dvsl depends=xdocs
description=use velocity to generate the docs
ant inheritAll=${ant.inheritAll} inheritRefs=${ant.inheritRefs}
dir=${xdocs.dir}/dvsl
property name=src.dir location=src/org/smartfrog/tools/ant//
property name=build.dir location=${build.antdocs.dir}/
property name=taskdocs.src location=${gen.dir}/
property name=xdocs.dir location=${build.xdocs.dir}/
property name=docs.dest location=${build.docs.dir}/
/ant
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: Google Summer of Code, Apache ANT project ideas?
Dominique has started researching for an xml dialect for the manual. There is something in bugzilla [1] and SVN (dont know where). If I remember right the way should be 1) analyse java sources and external (?) files 2) generate xml 3) transform to readable manual (HTML, PDF) For 2) it´s important to include examples. Maybe we could include targets from the junit testcases (mostly relying on a buildfile [2]) as an option. Base idea is: DRY (dont repeat yourself). For 3) we could also use Cocoon or Forrest. Jan [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=34116 [2] /src/etc/testcases/ -Ursprüngliche Nachricht- Von: Erik Hatcher [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 4. Juni 2005 02:05 An: Ant Developers List Betreff: Re: Google Summer of Code, Apache ANT project ideas? On Jun 3, 2005, at 3:24 PM, Daniels, Doug wrote: Yeah I was way off on Velocity I thought it was part of XDocs but really its that servlet engine. You weren't really far off. There is DVSL transformations in the current mix which is Velocity. Velocity isn't a bad choice necessarily. I was merely opening the door for discussion on how to craft this thing - no need to stick with the legacy way just because it's already partly there. A new and improved process may save time and be cleaner in the long run. What's wrong with XDocs it seems like a good way to parse through the Ant Tasks meta-data javadoc comments and extract the information we need for documentation. Nothing is wrong with it per se, but it's a pretty heavy process. Maybe using one of the faster/lighter/simpler Java parsers out there would be better. Requiring XDoclet for 3rd party tasks to generate documentation may be a bit heavy handed and prohibitive. What other types of capability were you looking for? Being able to fold examples into the documentation is a critical part of it, and being able to generate documentation in HTML, PDF, and other formats is quite desirable. The project deliverable would most likely be an Ant Task that could perform this document auto-generation right? I think so. Where can I find the previous XDoc stuff that was developed? It's in Ant's CVS under proposals/xdocs. Incidentally this is what generated Appendix E of Java Development with Ant (and could have been used to write the first edition of O'Reilly's Ant: The Definitive Guide :). Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
Steve Loughran wrote: Erik Hatcher wrote: Doug - I've added it as project ID ant-xdocs to that wiki page. As for technologies - I'm not sure if Velocity and XDoclet are the best technologies to use right now. Let's solicit input from others here on their architecture ideas. +1 to XDoclet; the only alternative would be Java1.5 annotations and we do not want to go there. If it has one problem, its footprint is atrocious: You have to set the ANT_OPTS env variable up to get enough memory. Now, if Xdoclet forked... What about using qdox[1] directly rather than going through xdoclet ? [1] - http://qdox.codehaus.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
+1 to XDoclet; the only alternative would be Java1.5 annotations and we do not want to go there. I would reiterate the same thing. What about using qdox[1] directly rather than going through xdoclet ? [1] - http://qdox.codehaus.org/ interesting, never have used itI would think that ease of use and performance would have to be a magnitude better then xdoc to validate its usage. cheers, Jim Fuller - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Google Summer of Code, Apache ANT project ideas?
As an alternative to directly using the Java 1.5 annotations you could user the JSR-175 backport of the annotations spec. Also on codehaus as http://backport175.codehaus.org/ Cheers Don -Original Message- From: James Fuller [mailto:[EMAIL PROTECTED] Sent: 06 June 2005 11:20 To: Ant Developers List Subject: Re: Google Summer of Code, Apache ANT project ideas? +1 to XDoclet; the only alternative would be Java1.5 annotations and we do not want to go there. I would reiterate the same thing. What about using qdox[1] directly rather than going through xdoclet ? [1] - http://qdox.codehaus.org/ interesting, never have used itI would think that ease of use and performance would have to be a magnitude better then xdoc to validate its usage. cheers, Jim Fuller - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
Don Stewart wrote: As an alternative to directly using the Java 1.5 annotations you could user the JSR-175 backport of the annotations spec. Also on codehaus as http://backport175.codehaus.org/ Cheers Don yes, except we have to deal with building on OSS javac compilers; I dont think jikes is annotation ready. the bigger issue with annotations is that their real role is to provide metadata in the .class files, above and beyond the @deprecated markers. We dont need that with ant *today*. Annotations would make more sense if you could annotate methods to explicitly export them as elements/attributes, or explicitly hide them, more to the point. You could even add extra information about the cardinality of things (like elements must be unique, exclusive, etc.) this would be useful to both docs and dynamically generated schemas. But that is a lot of extra complexity. EJB-land is going that way, as their life is already complex, and java1.5 promises simplicity... -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
Steve Loughran wrote: Don Stewart wrote: As an alternative to directly using the Java 1.5 annotations you could user the JSR-175 backport of the annotations spec. Also on codehaus as http://backport175.codehaus.org/ Cheers Don yes, except we have to deal with building on OSS javac compilers; I dont think jikes is annotation ready. It is unfortunate that having to deal with OSS javac and JVMs is holding back technology adoption -- which is clearly the case. the bigger issue with annotations is that their real role is to provide metadata in the .class files, above and beyond the @deprecated markers. We dont need that with ant *today*. Annotations would make more sense if you could annotate methods to explicitly export them as elements/attributes, or explicitly hide them, more to the point. You could even add extra information about the cardinality of things (like elements must be unique, exclusive, etc.) this would be useful to both docs and dynamically generated schemas. But that is a lot of extra complexity. EJB-land is going that way, as their life is already complex, and java1.5 promises simplicity... Annotations can be source only as well as embedded in classfiles. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
On Jun 6, 2005, at 9:42 AM, Steve Loughran wrote: Don Stewart wrote: As an alternative to directly using the Java 1.5 annotations you could user the JSR-175 backport of the annotations spec. Also on codehaus as http://backport175.codehaus.org/ Cheers Don yes, except we have to deal with building on OSS javac compilers; I dont think jikes is annotation ready. backport175 is in javadoc comments though, so there shouldn't be any compiler issues with that. right? I like the ideas of using backport175 and/or qdox. I think either of these approaches will be much lighter and faster than using XDoclet. the bigger issue with annotations is that their real role is to provide metadata in the .class files, above and beyond the @deprecated markers. We dont need that with ant *today*. With backport175 you get access to the annotations at runtime if you want. Same could be done with a qdox/XDoclet approach by building a descriptor that is then available at runtime. It was always my hope that IDE's would leverage this sort of metadata to better interact with Ant build files. Annotations would make more sense if you could annotate methods to explicitly export them as elements/attributes, or explicitly hide them, more to the point. You could even add extra information about the cardinality of things (like elements must be unique, exclusive, etc.) this would be useful to both docs and dynamically generated schemas. But that is a lot of extra complexity. EJB-land is going that way, as their life is already complex, and java1.5 promises simplicity... I'm not sure if you are pro/con for backport175 by reading your response. backport175 seems to offer a cleaner system to the XDoclet stuff I originally did. What are the cons to using it? Erik -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
Erik Hatcher wrote: I like the ideas of using backport175 and/or qdox. I think either of these approaches will be much lighter and faster than using XDoclet. AFAIK backport175 and XDoclet both make use of qdox. What would backport175 or XDoclet bring that cannot be done with qdox in our case ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
On Jun 3, 2005, at 3:24 PM, Daniels, Doug wrote: Yeah I was way off on Velocity I thought it was part of XDocs but really its that servlet engine. You weren't really far off. There is DVSL transformations in the current mix which is Velocity. Velocity isn't a bad choice necessarily. I was merely opening the door for discussion on how to craft this thing - no need to stick with the legacy way just because it's already partly there. A new and improved process may save time and be cleaner in the long run. What's wrong with XDocs it seems like a good way to parse through the Ant Tasks meta-data javadoc comments and extract the information we need for documentation. Nothing is wrong with it per se, but it's a pretty heavy process. Maybe using one of the faster/lighter/simpler Java parsers out there would be better. Requiring XDoclet for 3rd party tasks to generate documentation may be a bit heavy handed and prohibitive. What other types of capability were you looking for? Being able to fold examples into the documentation is a critical part of it, and being able to generate documentation in HTML, PDF, and other formats is quite desirable. The project deliverable would most likely be an Ant Task that could perform this document auto-generation right? I think so. Where can I find the previous XDoc stuff that was developed? It's in Ant's CVS under proposals/xdocs. Incidentally this is what generated Appendix E of Java Development with Ant (and could have been used to write the first edition of O'Reilly's Ant: The Definitive Guide :). Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Google Summer of Code, Apache ANT project ideas?
Hi, I'm a student at University of Massachusetts Dartmouth, and I've been using ANT extensively for school projects, as well as a fairly large project at work. I love using ANT, it's a very elegant tool, and I've always been interested in helping develop Ant on my free time, but I've never been able to get motivated enough. Now Google is running a Summer of Code program for students (http://code.google.com/summerofcode.html). Basically the student accepts a proposed project from a participating open source sponsor (IE: Apache), then they pick a mentor from that organization and works on that project for the summer. Apache is taking project ideas from Apache members for the summer of code (http://wiki.apache.org/general/SummerOfCode2005), so I didn't know if any ANT developers had any interesting bugs, feature requests, etc. that would be a good 1 or 2 month development task. I'm really interested in the ANT project, and the closest project proposal I've seen so far is a MSBuild implementation for the Mono project, which looks very interesting and I might apply for that, I was even thinking of writing some kind of converter from MSBuild format to an ANT build format then use ANT to build it. You can look at my resume to see any relevant experience that might be important for a proposed project: http://ddaniels.50webs.com/DougDanielsJrResume2005-06-02.doc Doug Daniels
Re: Google Summer of Code, Apache ANT project ideas?
Doug - glad you're interested in the SoC. One idea that would be tremendously helpful to Ant would be to revamp the documentation system such that task/type documentation is auto- generated. I started the proposal/xdocs project several years ago, but it never caught on. I'm not sure where it stands currently in terms of documentation generation. I'm swamped, but would be your mentor on such an effort if no other Ant committer was set on doing so. Erik On Jun 3, 2005, at 9:41 AM, Daniels, Doug wrote: Hi, I'm a student at University of Massachusetts Dartmouth, and I've been using ANT extensively for school projects, as well as a fairly large project at work. I love using ANT, it's a very elegant tool, and I've always been interested in helping develop Ant on my free time, but I've never been able to get motivated enough. Now Google is running a Summer of Code program for students (http:// code.google.com/summerofcode.html). Basically the student accepts a proposed project from a participating open source sponsor (IE: Apache), then they pick a mentor from that organization and works on that project for the summer. Apache is taking project ideas from Apache members for the summer of code (http://wiki.apache.org/general/SummerOfCode2005), so I didn't know if any ANT developers had any interesting bugs, feature requests, etc. that would be a good 1 or 2 month development task. I'm really interested in the ANT project, and the closest project proposal I've seen so far is a MSBuild implementation for the Mono project, which looks very interesting and I might apply for that, I was even thinking of writing some kind of converter from MSBuild format to an ANT build format then use ANT to build it. You can look at my resume to see any relevant experience that might be important for a proposed project: http://ddaniels.50webs.com/DougDanielsJrResume2005-06-02.doc Doug Daniels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Google Summer of Code, Apache ANT project ideas?
Erik, Sounds great, maybe you can submit it on the Apache SoC proposal page(http://wiki.apache.org/general/SummerOfCode2005), and I'll submit my application to google with Apache as my selected organization. I guess I'd propose it something like: The Apache Ant project needs a way to auto-generate task/type documentation. The proposed solution would use Velocity and xdocs to create a standard way to document the old and new Ant tasks to keep the documentation up to date and easily updatable in the future automatically. By the way I have your book and it was a great help with what I've been working on at my job. I was thinking of writing up an Ant tutorial describing an interesting build system we came up with utilizing Ant's import task to create a common build hierarchy infrastructure, that can be extended to new products very easily. It really helps when we have to add a new product in and all we do is define some properties and throw a build.xml stub in and it is then included into our software package. Doug Daniels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
On 6/3/05, Erik Hatcher [EMAIL PROTECTED] wrote: Doug - glad you're interested in the SoC. One idea that would be tremendously helpful to Ant would be to revamp the documentation system such that task/type documentation is auto- generated. I started the proposal/xdocs project several years ago, but it never caught on. I'm not sure where it stands currently in terms of documentation generation. Hehe. [Shameless plug] If someone wants to address a somewhat reusable xdoclet documentation tool, the cruisecontrol project is probably also interested. The current doc is nice: http://cruisecontrol.sourceforge.net/main/configxml.html but manually generated. See http://jira.public.thoughtworks.org/browse/CC-202 I'm swamped, but would be your mentor on such an effort if no other Ant committer was set on doing so. :) J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code, Apache ANT project ideas?
Doug - I've added it as project ID ant-xdocs to that wiki page. As for technologies - I'm not sure if Velocity and XDoclet are the best technologies to use right now. Let's solicit input from others here on their architecture ideas. Erik On Jun 3, 2005, at 1:46 PM, Daniels, Doug wrote: Erik, Sounds great, maybe you can submit it on the Apache SoC proposal page(http://wiki.apache.org/general/SummerOfCode2005), and I'll submit my application to google with Apache as my selected organization. I guess I'd propose it something like: The Apache Ant project needs a way to auto-generate task/type documentation. The proposed solution would use Velocity and xdocs to create a standard way to document the old and new Ant tasks to keep the documentation up to date and easily updatable in the future automatically. By the way I have your book and it was a great help with what I've been working on at my job. I was thinking of writing up an Ant tutorial describing an interesting build system we came up with utilizing Ant's import task to create a common build hierarchy infrastructure, that can be extended to new products very easily. It really helps when we have to add a new product in and all we do is define some properties and throw a build.xml stub in and it is then included into our software package. Doug Daniels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Google Summer of Code, Apache ANT project ideas?
Yeah I was way off on Velocity I thought it was part of XDocs but really its that servlet engine. What's wrong with XDocs it seems like a good way to parse through the Ant Tasks meta-data javadoc comments and extract the information we need for documentation. What other types of capability were you looking for? The project deliverable would most likely be an Ant Task that could perform this document auto-generation right? Where can I find the previous XDoc stuff that was developed? Doug Daniels -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Friday, June 03, 2005 2:09 PM To: Ant Developers List Subject: Re: Google Summer of Code, Apache ANT project ideas? Doug - I've added it as project ID ant-xdocs to that wiki page. As for technologies - I'm not sure if Velocity and XDoclet are the best technologies to use right now. Let's solicit input from others here on their architecture ideas. Erik On Jun 3, 2005, at 1:46 PM, Daniels, Doug wrote: Erik, Sounds great, maybe you can submit it on the Apache SoC proposal page(http://wiki.apache.org/general/SummerOfCode2005), and I'll submit my application to google with Apache as my selected organization. I guess I'd propose it something like: The Apache Ant project needs a way to auto-generate task/type documentation. The proposed solution would use Velocity and xdocs to create a standard way to document the old and new Ant tasks to keep the documentation up to date and easily updatable in the future automatically. By the way I have your book and it was a great help with what I've been working on at my job. I was thinking of writing up an Ant tutorial describing an interesting build system we came up with utilizing Ant's import task to create a common build hierarchy infrastructure, that can be extended to new products very easily. It really helps when we have to add a new product in and all we do is define some properties and throw a build.xml stub in and it is then included into our software package. Doug Daniels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Google Summer of Code, Apache ANT project ideas?
Erik, I'll hold off on the google application until I research it a little more and hear back from what others think we could use to build this, auto documentation generator. Doug Daniels -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Friday, June 03, 2005 2:09 PM To: Ant Developers List Subject: Re: Google Summer of Code, Apache ANT project ideas? Doug - I've added it as project ID ant-xdocs to that wiki page. As for technologies - I'm not sure if Velocity and XDoclet are the best technologies to use right now. Let's solicit input from others here on their architecture ideas. Erik On Jun 3, 2005, at 1:46 PM, Daniels, Doug wrote: Erik, Sounds great, maybe you can submit it on the Apache SoC proposal page(http://wiki.apache.org/general/SummerOfCode2005), and I'll submit my application to google with Apache as my selected organization. I guess I'd propose it something like: The Apache Ant project needs a way to auto-generate task/type documentation. The proposed solution would use Velocity and xdocs to create a standard way to document the old and new Ant tasks to keep the documentation up to date and easily updatable in the future automatically. By the way I have your book and it was a great help with what I've been working on at my job. I was thinking of writing up an Ant tutorial describing an interesting build system we came up with utilizing Ant's import task to create a common build hierarchy infrastructure, that can be extended to new products very easily. It really helps when we have to add a new product in and all we do is define some properties and throw a build.xml stub in and it is then included into our software package. Doug Daniels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
