Fwd: Ant Website error? or feature?
Passing on a private Ant documentation related issue. I'm guessing the only solution is to add a target=... to the top browser window to such hyperlinks. Or eventually move away from using frames. Erik Begin forwarded message: From: Steve Meredith [EMAIL PROTECTED] Date: April 19, 2006 8:11:47 AM EDT To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Ant Website error? or feature? Hi Just to let you know that If I visit http://ant.apache.org/ then click on [manual] from the menu taking me to http://ant.apache.org/manual/index.html and accidentally click on [apache ant] link in the first sentence I get sent to http://ant.apache.org/manual/index.html but inside a sub-window...and so on, and so on... How do I remove the cascading affect? Or is this meant to happen? I emailed this question to someone before (can't remember who ) but got fobbed off with a why would you want to do that response (shame). So, in the interest of possible site improvement, I picked three emails addresses 'out of the hat' just to let someone know who might want to make a change -or is it a feature ;-) Kind Regards Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Development with Ant
On Jul 26, 2005, at 5:30 AM, Steve Loughran wrote: Actually, maybe we should put together some official ant team presentations, for use in in-house or external talks, something like the following set. This could be something to get the user community involved in too... -intro to ant -why testing matters more than you think -whats new in ant1.7 (the apachecon slides are this) -.net with ant -C++ with ant -Ant XML processing -script in ant -continuous integration I'd be happy to contribute the slides I've done on Ant to various symposiums and conferences. The thing is, though, that slides are mostly useless - it's the presenter that makes the difference :) Where should these slides (in PDF format would probably be best) go? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant-xdocs
The Summer of Code projects have already begun, so at this point it is not possible to sign on with Google to do this project. If you are interested in tackling this project anyway, you're in the right place! My recommendation is you check out Ant's codebase, try to run the xdocs build and see where you get with it and then report back here. Erik On Jul 8, 2005, at 2:09 PM, Leandro_Dorileo/[EMAIL PROTECTED] wrote: Hi Erik I would like to have some infos about the ant-xdocs in the ASF subject propose to the Summer of Code, I saw that you are the possible mentor in this subject. Have this subject already been adopted? Best regards * Leandro Dorilêo Desenvolvedor Java ÁBACO Tecnologia de Informação Ltda Qualidade: Um Compromisso de todos! ( (0xx65) 617-0777 ( FAX 623-0646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer code
Anyone know what the procedure is for following up on these requests? It'd be a shame to let these folks go unanswered, but I'm not in a position to devote time to managing much. Erik On Jun 13, 2005, at 10:00 PM, Fang Liu wrote: Dear madam or sir: I have applied to *ant-xdocs* for the google summer code and I have aslo sent a mail to you, but both the mail and the application are not responsed. I wonder this project is availiable. I am a second year graduate student in Shanghai Jiaotong University. I have the capability and confidence to finish this project. What I want to do is giving unified tags to use xdocs as well as a common interface for 3rd party lib. If this project is still availiable, please give me a chance to finish it. Thank you, and hope to see your reply soon. -- Liu Fang Department of Computer Sciences and Engineering Shanghai Jiaotong University 1954 Huashan Road Shanghai,China.200030 Tel(Lab): +86-21-52543318(206) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: google summer code: ant-xdocs and another idea about ANT
On Jun 9, 2005, at 4:36 PM, xiaofeng xia wrote: I am a first year Ph.D student majoring in Computational Math at Emory University. I want to participate the Summer of Google Code. I am especially interested in the project ant-xdocs on http://wiki.apache.org/general/SummerOfCode2005 . Can you let me know who is going to mentor this project? I'm way too swamped to devote much time to it, but it is a project I care for. Perhaps another committer has the time to assist with it? Should I submit the proposal via Google Code or send the proposal for review firstly? Who should I contact? I think you're in the right place, though following what Google's process is the right way to go. I've been too swamped to read the details of how it works. You see, when people use ANT to do functional tests, diff is a necessary tool to generate test results. The function of this diff will be as the same as the diff command on Unix. Since no diff command on Windows, it could be useful to develop a similar but pure Java diff as an ANT task. There are already pure Java implementations of diff available. Wrapping it as an Ant task would be pretty trivial. I don't think this diff idea is something of interest for the Google SoC. What ideas do you have that relate to the ant-xdocs proposal? Erik - 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 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?
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?
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]
Re: about ANT-XDOCS
On Jun 3, 2005, at 8:43 PM, Lucas Arruda wrote: Hi, I wonder if you could send me some information (or places where i can get it from) about this project: Your first mentored assignment is to find the archives of this e-mail list and look at the recent messages regarding this topic :) Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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?
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: Commercial products on the related products page?
I had hopes that we'd use the wiki for this sort of stuff in the future, allowing it to be self-serve. The downside is that it's not included in the current distributions, but we could probably do some sort of get to pull wiki content into distributions as a snapshot. Erik On May 13, 2005, at 8:12 AM, Stefan Bodewig wrote: Hi, Slava Imeshev of Viewtier Systems sent me a private email asking whether it was OK to include links to commercial products on our related projects page. The original email - minus the actual patch and Slava's phone number - is reproduced below (with Slava's permission, of course). We already point to commercial IDEs for example, so I don't see any reason why we shouldn't do so for a buildserver, but maybe you feel different about it? Cheers Stefan From: Slava Imeshev [EMAIL PROTECTED] Subject: Patch to /ant/xdocs/projects.xml To: Stefan Bodewig [EMAIL PROTECTED] Date: Thu, 12 May 2005 23:49:35 -0700 Organization: Viewtier Systems, Inc. Hello Stefan, I was wondering if you accept commercial additions to the Ant Related Projects page at /ant/xdocs/projects.xml. If this is the case, I'd like to suggest a patch (enclosed) that adds Parabuild to /ant/xdocs/projects.xml. Parabuild is a multiplatform build automation server. Ant users are our main target audience. The URL of the product home is http://www.viewtier.com/products/parabuild/index.htm Please don't hesitate to contact me if you have any questions. Regards, Slava Imeshev President Viewtier Systems, Inc. 800 West El Camino Real, Suite 180 Mountain View, CA, 94040 - 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: [VOTE] Ant 1.6.4 release
On May 10, 2005, at 2:48 AM, Antoine Levy-Lambert wrote: Do we want to release ant 1.6.4 on Thursday, May 19th (this would at least suit Eclipse) [X] Yes [ ] No +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: regression in handling of java failures
On Apr 14, 2005, at 5:24 AM, Steve Loughran wrote: Stefan Bodewig wrote: On Tue, 12 Apr 2005, Steve Loughran [EMAIL PROTECTED] wrote: I have it on reliable authority (chapter 5 of java development with ant), You trust that, even though you know who's written it? I trust the chapters that Erik wrote :) I just used XDoclet to generate everything, so any mistakes have to be in Ant's source code :) Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Alexey Solofnenko
+1 On Apr 6, 2005, at 1:28 AM, Conor MacNeill wrote: I would like to propose Alexey Solofnenko as an Ant committer. Alexey is a long time contributor to Ant and is also active on our user list helping people with good suggestions and ideas. here's my +1 Conor - 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: complex signing logic in signjar
It's becoming more and more used. Several projects I've been involved in that use WebStart use signjar. Erik On Mar 22, 2005, at 11:18 AM, Steve Loughran wrote: Stefan Bodewig wrote: Steve, I think signjar is one of the least used tasks in Ant. IIRC we even shipped a version of Ant where signjar didn't work at all (I think Ant 1.2) and it took quite some time until anybody complained. Methinks it is kind of underused from the command line too, else the bugs would have been fixed. if you provide the -signedjar param, and that file equals your source file, the JVM toasts. That is usually pretty hard to do; I am impressed. [signjar] # [signjar] # An unexpected error has been detected by HotSpot Virtual Machine: [signjar] # [signjar] # SIGBUS (0x7) at pc=0x40bb6a62, pid=25065, tid=1075183744 [signjar] # [signjar] # Java VM: Java HotSpot(TM) Server VM (1.5.0_01-b08 mixed mode) [signjar] # Problematic frame: [signjar] # C [libzip.so+0xfa62] [signjar] # - 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: [VOTE] Retire Antidote
+1 On Mar 21, 2005, at 11:01 AM, Stefan Bodewig wrote: This again is a vote that needs two-third of all active committers, oh my. Since Antidote's development has been stalled for a long time now - and there doesn't seem to be a big need for an Ant GUI given the great IDE support we have - I hereby propose to retire the Antidote subproject. Actions to be taken: * announce that development has been stopped, both on Ant's website and the user list. * remove the Antidote pages from the website. * zip up the ant-antidote CVS module and offer it via archive.apache.org to interested parties. * ask infrastructure to remove the ant-antidote CVS module. Stefan - 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: FileSets with optional basedir and absolute paths for includes
I'm all for making File*Set* actually be capable of a true set of files anywhere I choose. The basedir restriction is one of the single biggest walls I hit and workaround. So, +1 from me. Erik On Mar 8, 2005, at 6:45 PM, Matt Benson wrote: Time for controversy! There is an interesting thread at http://issues.apache.org/bugzilla/show_bug.cgi?id=5035 that touches on this issue. The key issue was that some tasks (including 3rd party ones) would break if AFS.getDir() were to return null. This is indeed true. I have implemented the subject line, and the following tasks/types had to be touched: M src/main/org/apache/tools/ant/taskdefs/Copy.java (made copying abs. paths imply flattening) M src/main/org/apache/tools/ant/taskdefs/Delete.java (log message accessed dir) M src/main/org/apache/tools/ant/taskdefs/DependSet.java (depend stuff needs a basedir for package resolution) M src/main/org/apache/tools/ant/taskdefs/Javadoc.java (requires dir w/ packagesets b/c of package resolution) M src/main/org/apache/tools/ant/taskdefs/ optional/ide/VAJImport.java (easier to assume with untestables) M src/main/org/apache/tools/ant/taskdefs/ optional/metamata/AbstractMetamataTask.java (easier to assume with untestables) M src/main/org/apache/tools/ant/taskdefs/ optional/ssh/Scp.java (too complex to deal with yet) M src/main/org/apache/tools/ant/types/ optional/depend/ClassfileSet.java (depend stuff needs a basedir for package resolution) However, as I stated on the referenced bug entry, the API has never AFAICT promised that getDir would return a non-null result. The overwhelming majority of tasks would be unaffected by this as many tasks would simply use the directory as the first parameter of new File(File, String). No harm done. This has been an outstanding request for a long time. I feel that it represents little risk; fileset's documentation can be liberally sprinkled with warnings that errors might be encountered using dir-less filesets with some third-party tasks, and we can encourage third-party providers to make sure they are compatible. If we scheduled this for 1.7 we could put ample warnings into 1.6.3 that this is coming. So what say you all? -Matt __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ - 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: AW: IDEA for free!?
JetBrains gave all Ant committers a free non-commercial license a few years ago and I've been using it ever since. It's nice they've generalized this. I am on the fence with IDEA and Eclipse. I use both interchangeably, but I lean towards IDEA because it is quicker and friendlier. Erik On Feb 9, 2005, at 2:07 AM, [EMAIL PROTECTED] wrote: Another thing. You are only allowed to use the software for one year. http://www.jetbrains.com/idea/opensource/license.html Upon Your acceptance of this License Agreement (the Agreement), JetBrains grants to You a non-exclusive and non-transferable 1-year license to use the Software, provided that You agree to the following ... Jan -Ursprüngliche Nachricht- Von: Dominique Devienne [mailto:[EMAIL PROTECTED] Gesendet am: Dienstag, 8. Februar 2005 23:38 An: Ant Developers List Betreff: FYI: IDEA for free!? JetBrains offers free IntelliJ IDEA licenses By ADT Staff JetBrains will announce this week that it will offer open-source developers no-cost user licenses for its IntelliJ IDEA integrated development environment for Java. The company says the offer is open to developers of qualifying open-source projects, without really specifying what that means, other than saying the project must be recognized by the open-source community. Developers taking part in the JetBrains initiative will be able to use JetBrains' tools with everything they need in one intelligent IDE, dramatically improving their productivity and quality of code, the company says. JetBrains will also provide support. Licenses will be valid for one year and will apply to all product upgrades during that period, with annual renewals required for continued use. More details on the qualification process are available at http://www.jetbrains.com/idea/opensource/application.htm. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal
You may consider creating a custom ant command script which unsets CLASSPATH before invoking the executable class. Erik On Jan 24, 2005, at 10:40 PM, Kev Jackson wrote: Hi, I'm working on a project right now with real neophyte developers, and one of the things I'm constantly having to do is to unset classpaths. They keep installing crappy software that sets a classpath variable (Oracle client being the main culprit here) and then when they use the project build file, it falls over because of alien jars on the classpath (not Ant's fault or anything). I'm sure that this is a commonplace occurence, so I propose the following... On the website (ant.apache.org), in bold letters across the front page PLEASE FOR THE LOVE OF $DEITY, UNSET YOUR CLASSPATH BEFORE RUNNING ANT!! or if not on the front page, at least in the manual section. I'm even willing to add the documentation to the xdocs or html Also I think it'd be a good idea to print this out when simply typing ant at the command line - not just build.xml does not exist Sorry, rant off Kev - 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: excludesfile must exist?
On Jan 25, 2005, at 5:58 AM, Stefan Bodewig wrote: Actually, on second thought, there is more to this. Remember that fileset default to includes=** and no excludes. Now consider delete fileset dir=extremely-important-files includesfile=some-not-so-important-files/ /delete If some-not-so-important-files isn't there, Ant will barf now. I guess most people prefer this over having Ant delete all files in the extremely-important-files directory instead. Yes, I agree with the current behavior for includesfiles, but to my current use the excludesfile is a different type of scenario. I want all files included except ones that are listed in an optional file. The available and excludesfile if=.../ works fine for me though, so I retract my original request :) Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: excludesfile must exist?
On Jan 24, 2005, at 3:29 AM, Stefan Bodewig wrote: On Fri, 21 Jan 2005, Erik Hatcher [EMAIL PROTECTED] wrote: I haven't been in the internals of Ant for a while, my apologies. I recall this coming up before any objections to changing how fileset handles excludesfile (and I'm assuming includesfile) such that existence of the file is not mandatory? Your usecase is exactly why we've added if/unless to the nested elements. This and the fear of breaking BWC since some builds actually rely on the current behavior. Ah, the age-old BWC anchor tied around our ankles. *sigh* Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: excludesfile must exist?
On Jan 21, 2005, at 4:33 PM, Matt Benson wrote: --- Erik Hatcher [EMAIL PROTECTED] wrote: I haven't been in the internals of Ant for a while, my apologies. I recall this coming up before any objections to changing how fileset handles excludesfile (and I'm assuming includesfile) such that existence of the file is not mandatory? [SNIP] +0 but looks like you could use available + if/unless of excludesfile elements in the meantime; I hesitate to presume you didn't know that, but I didn't until I just looked. :) I hadn't thought about that option, so thanks for reminding me! It still seems silly to error on a missing includes/excludes file, sort of like erroring on a missing properties file with property file=missing_file.properties/ Your recommendation will suffice for my purposes though :) Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
excludesfile must exist?
I haven't been in the internals of Ant for a while, my apologies. I recall this coming up before any objections to changing how fileset handles excludesfile (and I'm assuming includesfile) such that existence of the file is not mandatory? Logging that the file doesn't exist seems appropriate if we make this change. If the file doesn't exist, it should act as if that attribute was not specified. I'm speaking from Ant 1.6.2, and haven't looked to see if this has changed in the latest codebase yet. I just hit this issue in my current project where I'm trying to work around a handful of invalid XML files with xslt by using excludesfile. Thanks, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libraries cache
On Dec 5, 2004, at 6:23 PM, Russell Gold wrote: On Sun, 5 Dec 2004 06:57:09 -0500, Erik Hatcher [EMAIL PROTECTED] wrote: I can't think of any sound reasons for preserving hierarchy in WEB-INF/lib. Some vendors, especially of commercial software, choose to distribute their products as multiple jars. And some of them attempt to identify primary vs. subordinate jars through a hierarchy. Those jars then know about their relative locations and depend on them in their manifest classpaths. If you arbitrarily flatten your hierarchies you will get ClassNotFound exceptions in such cases. From Servlet 2.4 specification, section 9.5: The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets, beans, and other utility classes useful to the Web application. The Web application class loader must be able to load classes from any of these archive files. The Web application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. Also, any requests from the client to access the resources in WEB-INF/ directory must be returned with a SC_NOT_FOUND(404) response. There is later verbiage that says: Web containers must also be able to recognize declared dependencies expressed in the manifest entry of any of the library JARs under the WEB-INF/lib entry in a WAR. So it is ambiguous, at least to me (one part says in another says under), whether a hierarchy under WEB-INF/lib is kosher or not. I have never used anything but a flat structure there, and likely never will. I would very much like to see the lib element flatten, or some way to flatten any arbitrary fileset. I end up doing a copy to flatten a hierarchical directory before using lib, which is sub-optimal. Ant already has a concept of a mapper type, typically used for copy operations. Yes, I know :) It would be entirely consistent to extend its use to the lib subtask (which essentially does a copy in any case). Cake and eat it, too. lib is not a subtask, per se. It is a fileset datatype. The difference currently is that datatypes don't do anything, but contain data that tasks use. So while I'd love a flatten mapper on lib, I'm not sure it is consistent and makes sense in all places that a fileset can be used. I realize that the difference between a task and datatype has gotten smaller in 1.6, though. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libraries cache
On Dec 3, 2004, at 3:08 PM, Russell Gold wrote: 2. Once you have a repository, you need to extract files from it for use in WAR files, etc. Which means (a) a library policy to create a fileset from the collection (b) lib in WAR/EAR must flatten filesets during copy. No, you need a flattening mapper - but only if you need to copy the libraries. There may be sound reasons for preserving a hierarchy in a WAR/EAR. For most purposes, flattenmapper should suffice. I have defined a depencies-mapper which also strips version numbers in case the target has hard-coded its jar dependencies ad doesn't want the names to change with new versions. I can't think of any sound reasons for preserving hierarchy in WEB-INF/lib. I would very much like to see the lib element flatten, or some way to flatten any arbitrary fileset. I end up doing a copy to flatten a hierarchical directory before using lib, which is sub-optimal. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: Project ant-xdocs-proposal (in module ant) failed
You should consider using something besides XDoclet when starting fresh. XDoclet2 has been gaining momentum. And QDox and Doxygen may be worth looking into as well. XDoclet is a bear and requires of resources to run. XDoclet2 is supposedly much more streamlined. Sorry I've been absent from xdocs for a long while - lately I've been blissfully simple - staying away from EJB/Struts projects that got me into XDoclet in the first place. I'm quite happy with just javac, junit, and jar most of the time :) Erik On Dec 2, 2004, at 6:41 AM, Steve Loughran wrote: On Thu, 02 Dec 2004 09:32:22 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote: this is a bug in Gump which currently ignores the jvmargs setting telling it to add more memory to the build. I'm in the process of brushing up my minimal Python knowledge to a-bit-more-than-minimal-but-still-nothing-to-talk-of so I can fix it. Don't hold your breath 8-) Stefan I actually want to sit down and get this whole xdocs things working properly. Wonderful that it is, it was written two+ years ago, and hasnt been touched since. I use it for generating docs for external project (Axis, smartfrog) and that really hurts. What I'd like is -libraries fetch of needed components -generate docbook content for feeding into db2pdf or FOP -coverage of datatypes and nested elements -better support for example code -generate a quickref as well as the pages and a big PDF version -usable by other projects I'd probably start this in a new proposal subdir, as it would be fairly different. No time to start this this year, as I am off on a 3 week holiday, and have no laptop. 3 weeks with no laptop! -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: task testing style?
Both styles of testing have their merits. There are some mock objects in Ant's test infrastructure (MockBuildListener, for example). The most important thing, of course, is that tests are created that ensure that the production code is working as it should. Sure, there are more moving parts in the functional-style. Ideally there would be all flavors of testing in place to ensure all levels are functioning appropriately. There are certainly no objections about incorporating more mock-style testing into Ant's codebase. The more testing the better! The dilemma I've encountered when folks catch on to mock unit testing is that they get carried away with it and try to mock too much functionality rather than keeping it focused, at which point you end up with mock objects that are so complex that they require their own unit tests :) Erik On Nov 16, 2004, at 12:33 PM, Russell Gold wrote: The tests I have looked at in ant appear mostly to use a semi- functional test style: they use xml to define a task, run it, and then check some results (which may simply be the lack of an error). I am used to a more unit testing style, in which external classes or subsystems are stubbed out. For example, for my dependencies task, I want to confirm that a dependency is downloaded only if it is not already present, which I do by mocking the fetch mechanism. Is this approach being used somewhere in ant? Has there been any discussion of the two approaches to testing? - 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: VOTE - new committer - Martijn Kruithof
Better late than never: +1 Erik On Nov 5, 2004, at 10:19 AM, Matt Benson wrote: I would like to nominate Martijn Kruithof as an Ant committer. Martijn has been the source of a number of code submissions and suggestions over a number of years, including unsolicited contributions to solve problems that would otherwise have been left to the Ant committers. This, in combination with the quality of his work and his apparent effiency in producing it, has prompted his nomination. I will start with my own vote: [+1] Thanks, Matt __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - 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: VOTE - new ant committer Dominique Devienne
+1 On Sep 7, 2004, at 1:30 PM, Peter Reilly wrote: I would like to propose Dominique to become an ant committer (finally!). Heres my +1 vote. Peter - 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: VOTE: new committer - Jesse Glick
+1 On Sep 2, 2004, at 4:11 AM, Steve Loughran wrote: I'd like to nominate Jesse Glick (of netbeans/sun) as an ant committer. Netbeans is a heavy user of ant, and he regularly submits patches to code and docs to improve the integration -patches that benefit ant overall. Giving him commit rights would let him make these changes directly to the codebase, without having to struggle to get through the patch backlog. Here's my opening vote: +1 -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: Request for more access to IntrospectionHelper-stored info
Dominique, Have you looked deep into proposal/xdocs to see how its documentation generation was done? How much of what you're doing is reinventing what was done there? Sounds almost identical. I leveraged IntrospectionHelper as well as the XDoclet object model to get all the info I needed. Erik On Aug 17, 2004, at 9:47 AM, Dominique Devienne wrote: I'm working on a combination task/doclet to document Ant tasks/types. Currently, Ant gives access to enumerations of names for attributes and nested elements for a given type thru IntrospectionHelper, and once one has a name, the Java Class for that attribute/nested-element, but on the other hand it does not provide access to the actual method used to set the attribute or add/create the nested elements. My goal is to extract the Javadoc comments from the appropriate method for a given attribute/nested-element, out of the doclet, but I don't want to recode a brittle mapping from attribute name back to the corresponding Java method, especially when Ant already has this info, albeit with no public accessor. Furthermore, the new Ant 1.6+ add[Configured](Class) extensions points stored in addTypeMethods are again not accessible publicly at all. Does anyone objects to adding access to this information? Thanks, --DD - 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: Request for more access to IntrospectionHelper-stored info
On Aug 17, 2004, at 11:51 AM, Dominique Devienne wrote: From: Erik Hatcher [mailto:[EMAIL PROTECTED] On Aug 17, 2004, at 9:47 AM, Dominique Devienne wrote: I'm working on a combination task/doclet to document Ant tasks/types. Have you looked deep into proposal/xdocs to see how its documentation generation was done? How much of what you're doing is reinventing what was done there? Sounds almost identical. I leveraged IntrospectionHelper as well as the XDoclet object model to get all the info I needed. Glad to hear what I'm doing is not too wrong headed then ;-) No I didn't, because I'm not willing to take on the XDoclet dependency. Quite understandable about that dependency - it is heavy, no question. I've had good success with plain doclets in the past, and I don't see Javadoc as being slow either (it's the StandardDoclet that's slow, not Javadoc itself). Also, I want an XSL-driven solution. proposal/xdocs generates XML files for each task, which could of course easily be XSL'd. The current XML - HTML generation is done using DVSL. But reinventing the wheel or not, the fact remains that the additional accessors I'm requesting in IntrospectionHelper are needed for any solution that doesn't want to re-code the attribute/nested-element logic in reverse, or the whole logic of the add[Configured](Class) extension points. Yeah, I definitely recoded that type of stuff in TaskTagsHandler.java. I've been postponing the documentation of my many tasks for too long, and it's time I get something working. I'm not willing to hand write documentation in HTML, but I want to assemble it from Javadoc comments and possibly auxiliary XML or plain text files (Wiki-style). --DD Keep us posted on what you come up with! I created proposal/xdocs to generate the task reference appendix in JDwA, and tossed it out there as a possible way to document tasks/types in the hopes it would get more attention that it has. I believe Steve has used it to generate task documentation in Axis, and it has been used a little to generate the documentation of some of Ant's newer tasks (the HTML pages that don't quite fit in). Ant's task documentation could definitely use some automated generation. At least the work I've done on tagging Ant's source code should help you in your efforts, with the @ant.* tags. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer : Steve Cohen
+1 On Jun 8, 2004, at 2:29 PM, Antoine Lévy-Lambert wrote: Hi, I would like to propose Steve Cohen as a new committer for ant. He has done a number of contributions concerning the ftp task and the starteam tasks. Steve will help us solve issues regarding commons-net based tasks in ant, and also generally participate in improving ant. Let me begin with my +1. Antoine - 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: Alias names for imported targets
I would *love* for this to be in 1.6.2 Alas, I've no time in the near future to look into it myself though, sorry. Erik On Jun 4, 2004, at 8:13 AM, Stefan Bodewig wrote: Hi, Erik already brought that up. Target foo imported from project named bar is known as foo in my build file unless I override it (in which case it becomes bar.foo. I'd like to have the alias name bar.foo available even if I don't override it. I haven't looked into the code yet, but are there any principal objections? Target time-frame would be 1.6.2. Stefan - 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]
namespaced targets via import
I've know about this, but a friend just brought it up to me again and maybe I've mentioned this before imported.xml project name=imported target name=some-target/ /project build.xml project name=build import file=imported.xml target name=another-target depends=imported.some-target/ /project Doesn't work, since some-target is not overridden. It would be nice if all imported build file targets were namespaced regardless of whether the targets were overridden or not. What are the implications of making this change? Thanks, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: junitreport slowed down by properties
On Mar 26, 2004, at 9:06 AM, Stephane Bailliez wrote: BTW, I didn't quite understand why displaying the properties used some JavaScript, rather than a pure HTML table, as an external file. I don't know, Erik did it so he can probably answer. Just seemed a nice way to have them display on the same page. I concur with the properties discussion though... I have not used those Ant properties in ages with the unit tests and we should probably make some type of switch to turn them off if desired. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposal new task Proxy
How does this compare to setproxy? http://ant.apache.org/manual/OptionalTasks/setproxy.html On Mar 4, 2004, at 9:04 AM, Edson Alves Pereira wrote: Hello dudes, i´ve made a task to make ant access outside my local network throught our proxy server, i found it usefull and i´d like to make it part of ant distribution to other people use it also. What do you think should i add this task to ant? Regards, Edson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs resources.html
I'm confused did something I committed say something about Ant 1.3??? That article I wrote was about Ant 1.5. Erik On Feb 24, 2004, at 6:33 AM, [EMAIL PROTECTED] wrote: http://www.fawcette.com/javapro/2003_02/magazine/features/ehatcher/l Working with Ant 1.3 and 02/2003, Ant 1.3 - seems to be old :-) Not not invalid, ´cause basics haven´t changed (so much). Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs resources.html
What you quoted was not part of the commit - it was just around the stuff I changed. But the JUnit article I wrote for dW ages ago is really only for Ant 1.3. This was my first foray into tweaking with Ant's code, and it morphed into enhancements to junit/junitreport that became part of Ant 1.4. Erik On Feb 24, 2004, at 6:50 AM, [EMAIL PROTECTED] wrote: I'm confused did something I committed say something about Ant 1.3??? Yep: http://marc.theaimsgroup.com/?l=ant-devm=107761882429761w=2 subsection name=Automating the build and test process pThis article demonstrates an approach to the automated build and test \ process. Working with Ant 1.3 and the JUnit test framework, it shows how to automate \ a process that captures pertinent information about each test suite run, generates an \ attractive report, and e-mails the report./p That article I wrote was about Ant 1.5. Fine :) Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [New task] scripttypedef (or refectdef)]
So this would allow creating a filter, mapper, or other type dynamically? Nice! Just a sanity check - there is no way to do this with scripting stuff in 1.6.1 is there? package org.apache.tools.ant.taskdefs.optional; /** * Class to define an ant definition using a script that * can return a class that is a normal ant task/datatype. * If the language is beanshell it must be 2.0 or higher. * The other scripting currently known to work is * groovy (1.0beta3). * p * Note that if there is anything incorrect with the script * the warning message is quite cryptic. * /p * This class is based in part on o.a.t.ant.util.ScriptRunner. * The main difference is that it does not define * beans. This is for three reasons: * ol * liThe definition may be used in another project./li * liIt should be possible to convert to java later./li And the third reason is? :) Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: text support for macrodef
+1
On Jan 22, 2004, at 10:03 AM, Peter Reilly wrote:
I would like to add support to macrodef to allow the text content
of macros to be placed in the macro instance:
use is like this:
macrodef name=echotest textname=text
sequential
echo@{text}/echo
/sequential
/macrodef
echotest
Hello world
/echotest
The textname attribute value becomes a macrodef attribute that
gets set to the value of the text contents of the macro.
Peter
-
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: [VOTE] Release a library with the SSH tasks for Ant 1.5.x
+0 (doesn't benefit me, and I'm purely at Ant 1.6 now) On Jan 19, 2004, at 1:33 PM, Stefan Bodewig wrote: Hi all, I've hacked together some small build file snippet in the 1.5 branch that allows me to compile a stand-alone library for the SSH tasks. One of the results (the ZIP archive) can be found in http://cvs.apache.org/~bodewig/ant-ssh-tasks-1.5-1.0.zip. Please take a look at it and cast your vote: * shall we release such a library at all? * if so, is the above archive what we want to release? This is a release and as such needs at least three PMC members casting a +1. Stefan - 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: ant xdocs proposals
On Jan 14, 2004, at 3:18 PM, Antoine Lévy-Lambert wrote: The advantage of generating the xdocs from build/classes is that it makes the development cycle a bit shorter. For instance, if you add a new task in your development workspace, then you can generate the xdocs as soon as you have compiled the class, (and probably added it to defaults.properties) without waiting for this class to be in your ant installation. I stumbled against this because I have an installed ant 1.6.0 version, and it would not generate the xdocs for the Classloader and the Nice tasks which are 1.7alpha specific tasks. I was first wondering whether it was due to some bug in xdoclet, I even downloaded the sources and was already dreaming :-( of debugging ant + xdoclet to find out why I had ClassNotFoundException s when processing Classloader and Nice. This is really only a hairy issue for processing Ant code itself. In a general purpose sense for others using this xdocs stuff (like Steve does with Axis tasks, I believe) is only that the .java processed needs to have been compiled first and in the classpath (which is used for the IntrospectionHelper magic). Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant xdocs proposals
On Jan 12, 2004, at 5:43 PM, Antoine Lévy-Lambert wrote:
This one http://nagoya.apache.org/~rubys/gump/ant-xdocs-proposal.html
is complaining about missing prereqs
Missing prereq |/tmp/gump/xdoclet/target/lib/xdoclet-20040112.jar|
from xdoclet http://nagoya.apache.org/%7Erubys/gump/xdoclet.html
Missing prereq
|/tmp/gump/xdoclet/target/lib/xdoclet-apache-module-20040112.jar| from
xdoclet http://nagoya.apache.org/%7Erubys/gump/xdoclet.html
Missing prereq
|/tmp/gump/xdoclet/target/lib/xdoclet-bea-module-20040112.jar| from
xdoclet http://nagoya.apache.org/%7Erubys/gump/xdoclet.html
the jars which are declared missing there are present under other
names under proposal/xdocs/lib in the ant repository
But this is precisely the purpose of Gump, to find where the chain of
dependencies break that are hopefully transient because of
inter-project miscommunication or worse. In the current run it looks
like JavaCC failed to build which is what underlies xjavadoc.
here is what I have got :
-rw-r--r--1 antoine Kein91866 Jan 5 2003
commons-collections-2.0.jar
-rw-r--r--1 antoine Kein26388 Jan 5 2003
commons-logging.jar
-rw-r--r--1 antoine Kein 150795 Apr 30 2003
xdoclet-1.2b3-dev.jar
-rw-r--r--1 antoine Kein 192570 Apr 30 2003
xdoclet-ejb-module-1.2b3-dev.jar
-rw-r--r--1 antoine Kein39403 Apr 30 2003
xdoclet-web-module-1.2b3-dev.jar
-rw-r--r--1 antoine Kein56298 Apr 30 2003
xdoclet-xdoclet-module-1.2b3-dev.jar
-rw-r--r--1 antoine Kein 230443 Apr 30 2003
xjavadoc-1.0-SNAPSHOT.jar
other jars listed by gump as prereqs are not really required by
proposal/xdocs
We probably ought to upgrade what we have in the lib directory to
XDoclet 1.2 Final - it is unlikely to change anytime soon from that
version.
So could one of you guys fix the descriptors for ant xdocs proposal or
discuss a way forward to get this built ?
I don't have the time to really dig into the specifics, but it seems
that everything is working as it should with Gump, and it is finding
issues with dependencies. Or is it failing all the time? The idea is
for us to communicate the problem to the project causing the failure
and let them know what is wrong - they may be completely and happily
oblivious to a change they made that breaks everyone that depends on
them.
Other ideas/changes will come next :
- generate the xdocs from ant's build/classes directory + lib/optional
(ie what has just been built) rather than based on ${ant.home} (what
has been installed, might be different)
Sounds fair enough.
- use anakia to go from xml to html instead of dvsl . It will be more
consistent with the rest of the ant docs, maybe will be helpful to
generate tabs on the top of the page and content frames on the left
looking like what is there in the top level elements of
http://ant.apache.org
Or maybe Forrestize it? But I'll leave the prettying up of this to
those that are good at that stuff :)
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bug Tracking System
[X] +1 Bugzilla sucks - go to Jira [ ] -1 BugZilla rocks - if it ain't broke, don't fix it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Ant Wiki
So, please vote on this issue [X] +1 - I want an Ant Wiki [ ] -1 - I don't want a Wiki 1. send to the dev list (either directly such as BugZilla, or to an email alias as is done for CVS). Yes, changes sent to the dev list is fine with me - as long as they are sent to somewhere unique that I can subscribe to then I'm happy. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: comment task
On Jan 8, 2004, at 10:43 AM, Peter Reilly wrote: Hey Peter, can't you code that? ;-) --DD I think that this is coded already using the jexl property support in proposal/embed. OGNL http://www.ognl.org would be way slick also! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default setting of the javac includeAntRuntime attribute?
On Jan 4, 2004, at 6:04 PM, Kenneth Olving wrote: The default setting of 'true' for this attribute has always bothered me - from a CM perspective it is a bit of a nightmare when you get things in your cp that you didn't intend to be there. From a CM perspective, why not put Ant under control as well?! :) We do this - Ant itself is in our CVS server and all developers use that version in their local environments - which makes adding a dependency (such as junit.jar which notoriously must live in ANT_HOME/lib) a breeze for the team, transparent in fact. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant 1.6 - thanks!
Thank you to all that contributed to Ant 1.6! I have, unfortunately, been (mostly) out of the loop with Ant development for a while and am just now (believe it or not) getting up to speed on all the nice new features that have been added. Sure, I've known of their existence, and have tracked the activity daily, but there is nothing like first-hand experience. macrodef, import and subant are going to be major enhancers to several projects I work on. Specifically in Jakarta-land, I'm overhauling the build process for Lucene's sandbox (jakarta-lucene-sandbox repository) where I'm leveraging subant and import. Already within a day I've made dramatic steps to unify and clean up the multi-project build process. Cheers! Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposal/xdocs : Anakia versus dvsl
On Wednesday, December 17, 2003, at 03:31 PM, Antoine Lévy-Lambert wrote: anybody has an idea why in the xdocs proposal we are using dvsl to format into html the documentation, while we are using the anakia task for the rest of ant's web site ? Yup because someone stepped forward and contributed the DVSL to turn the XML into HTML. I had some ugly XSL in my original stuff. It is fair game to morph, as far as I'm concerned. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jose Alberto Fernandez as committer
No doubt... +1 On Friday, December 12, 2003, at 05:08 AM, Antoine Lévy-Lambert wrote: Hi, I would like to propose a vote for Jose Alberto Fernandez as new ant committer. Jose has expressed a lot of interest in ant, and had made a very interesting antlib proposal. His contributions to the discussions on the dev list are always interesting. Let me begin with my +1. Antoine - 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: DynamicConfigurator namespace problem
On Thursday, December 11, 2003, at 10:08 AM, Stefan Bodewig wrote: On Thu, 11 Dec 2003, Peter Reilly [EMAIL PROTECTED] wrote: I have no objection to passing just the localname if the other commiters see no problem with this. +1 If this means XDoclet won't break then a hearty +1 as well. Again, I apologize for not spotting this or trying it out sooner. Peter - am I wrong in thinking that XDoclet breaks with the way it is currently? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdoclet and the generated html files
I am following this thread. I'm glad Peter got past his original issue. I don't have much bandwidth at the moment to spend on this, but will help as I can. On Wednesday, December 10, 2003, at 04:11 AM, [EMAIL PROTECTED] wrote:\ @ant.internal=true Internal setters not to be documented in the manual Erik sais something about fallbacks on http://marc.theaimsgroup.com/?l=ant-devm=102474522902362w=2 ... but I haven´t understood that ... So putting @ant.element ignore=true on an element creator/adder-looking method, XDoclet ignores it and it does not make it to the generated descriptor. This is probably more relevant for attributes, so put @ant.attribute ignore=true on a setter which should not be documented (and you'll find we have several of these I believe). Explanations of the use of mergepoints by Erik on http://marc.theaimsgroup.com/?l=ant-devm=104186638402086w=2 Merge points are the way to go with the current XDoclet 1.2. But XDoclet2 is now in full force development, and perhaps it would make sense to develop the necessary infrastructure to support it. It has a much cleaner templating system (Velocity or Jelly currently) and using the standard #parse/#include stuff for merging information, which may be more straightforward than the current merge point mechanism. Alas, I have no time to devote to this at the moment either, but wanted to toss it out as an option for others to explore. I personally have not even gotten a chance to try out XDoclet2 myself. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nant task update
On Friday, November 28, 2003, at 04:13 AM, Steve Loughran wrote: Stefan Bodewig wrote: On Thu, 27 Nov 2003, Peter reilly [EMAIL PROTECTED] wrote: This is to be backward compatible with previous versions of ant. Actually, my mail is a success mail 8-) we could do a really cool soap task with this XMLFragment thingy, or add an xmlpost task that is more RESTy How does XMLFragment make things better in this regard than just putting it all in a CDATA section? I guess it implicitly enforces the well-formedness at least. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant build.sh build.bat
On Thursday, November 13, 2003, at 06:06 AM, Conor MacNeill wrote: well, we should decide whether building Ant on Win98 is important. Being able to run it there is important but building it could be considered less so. An option, therefore would be to drop Win98 build support. +1 on dropping Win98 build support. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Vote: local for 1.6
-0 (don't object enough to veto it) I would like to put the local property patch into ant 1.6. Normally I would wait for 1.7 for this, but it has a big and (I think) beneficial impact on macrodef/. The changes to macrodef are not Backward Compatible with the current implementation. The local task declares properties that only exist for the current scope, where scope is a target, or a sequential (any taskcontainer) or a macro instance. The patch is in http://issues.apache.org/bugzilla/show_bug.cgi?id=23942 Peter - 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: [vote] Ant 1.6 : further release plan
On Monday, October 13, 2003, at 04:04 PM, Antoine Lévy-Lambert wrote: I am thinking about preparing a second beta on Thursday evening (October 16th). +1 I would also like to make the 1.6 release on October 30th. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE]: Getting 1.6 out the door
+1 i have no spare cycles in this timeframe (or the rest of this year even) to devote to this release unless something is really pressing. i would have loved the xdocs stuff gain momentum and be used, but by no means should it hold up a release. On Friday, September 12, 2003, at 05:58 AM, Antoine Lévy-Lambert wrote: Hi, I would like to propose a release plan for voting : - features included in 1.6 : all the features currently present in head - freeze date for 1.6 branch : Monday, September 22 13:00 GMT - availability of ANT_16_B1 binaries : within one week of the freeze of the branch. The exact time will depend on whether I will have trouble with practical issues from the build down to the signing of the jar files to the update of the web site, of bugzilla, ... - release manager : myself (I hope this is OK, although I am not a PMC member). So, if this release plan is voted, on Monday, September 22 I will create the ANT_16_BRANCH tag. The CVS Head will then become ant 1.7alpha Cheers, Antoine - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 29, 2003 2:08 PM Subject: Re: Getting 1.6 out the door Peter is currently on vacation, I hope he'll be back soon enough to chime in. On Thu, 28 Aug 2003, Conor MacNeill [EMAIL PROTECTED] wrote: There will probably be a 1.6.1 release in between to clean up any issues we discover in 1.6 Maybe we should consequentyl call the first 1.6 release 1.6.0 then? 2. antlib I think this should be in yes. but I am not familiar with its state yet, I'm not happy with some code details but the overal functionality is there. We should be able to properly document it and see whether we all can agree that this is the antlib functionality we want. If we agree on it, we should put it into 1.6 - changing implementation details would be like fixing bugs IMHO. nor do I think it has had enough testing Of course not. Are we planning to antlib Ant's own optional jars? Not in 1.6(.0) IMHO. In 1.7 I think we need to look at removing antlibs from the root loader when their dependent jars are not available in ANT_HOME/lib. Yes. Comments? The permissions stuff is causing some problems and we need to get the new Launcher tested in a wider audience. Gump doesn't use it, it still uses Main as its entry point and switching it to use Launcher will cause a lot of problems (if we do it right and don't cheat by adding ant.jar to CLASSPATH, that is). Stefan - 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: cvs commit: ant/xdocs external.xml
It seems like a never-ending stream of these types of things. Obviously Stefan is very quick to apply these, but I'm wondering if it'd be better to just put a link to the Ant wiki pages and let folks self-maintain a list of these add-ons/extras. On Thursday, September 11, 2003, at 06:47 AM, [EMAIL PROTECTED] wrote: bodewig 2003/09/11 03:47:16 Modified:docs external.html xdocsexternal.xml Log: Add pointer to JWare/AntXtras Revision ChangesPath 1.134 +54 -0 ant/docs/external.html Index: external.html === RCS file: /home/cvs/ant/docs/external.html,v retrieving revision 1.133 retrieving revision 1.134 diff -u -r1.133 -r1.134 --- external.html 9 Sep 2003 13:18:35 - 1.133 +++ external.html 11 Sep 2003 10:47:16 - 1.134 @@ -2312,6 +2312,60 @@ /tr /table h4 class=subsection +a name=JWare/AntXtras Foundation/a +JWare/AntXtras Foundation + /h4 +pA collection of general Ant extension tasks divided into +four main categories:/p +ul + liBuild-Rules(asserts,prefers,etc.),/li + liFeedback(log4j,jlog,etc.),/li + liFlowcontrol(templates),/li + liand Helpers./li +/ul + table class=externals cellspacing=1 cellpadding=4 + tr + th colspan=1 rowspan=1 + valign=top align=left + Compatibility: + /th + td colspan=1 rowspan=1 + valign=top align=left + Ant 1.5.1 or later + /td + /tr + tr + th colspan=1 rowspan=1 + valign=top align=left + URL: + /th + td colspan=1 rowspan=1 + valign=top align=left + a href=http://www.antxtras.info/;http://www.antxtras.info//a + /td + /tr + tr + th colspan=1 rowspan=1 + valign=top align=left + Contact: + /th + td colspan=1 rowspan=1 + valign=top align=left + a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a + /td + /tr + tr + th colspan=1 rowspan=1 + valign=top align=left + License: + /th + td colspan=1 rowspan=1 + valign=top align=left + GNU Lesser General Public License (LGPL) + /td + /tr +/table +h4 class=subsection a name=Macker/a Macker /h4 1.98 +32 -0 ant/xdocs/external.xml Index: external.xml === RCS file: /home/cvs/ant/xdocs/external.xml,v retrieving revision 1.97 retrieving revision 1.98 diff -u -r1.97 -r1.98 --- external.xml 9 Sep 2003 13:18:36 - 1.97 +++ external.xml 11 Sep 2003 10:47:16 - 1.98 @@ -1211,6 +1211,38 @@ /table /subsection + subsection name=JWare/AntXtras Foundation + +pA collection of general Ant extension tasks divided into +four main categories:/p + +ul + liBuild-Rules(asserts,prefers,etc.),/li + liFeedback(log4j,jlog,etc.),/li + liFlowcontrol(templates),/li + liand Helpers./li +/ul + +table class=externals + tr +thCompatibility:/th +tdAnt 1.5.1 or later/td + /tr + tr +thURL:/th +tda href=http://www.antxtras.info/;http://www.antxtras.info//a/td + /tr + tr +thContact:/th +tda href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a/td + /tr + tr +thLicense:/th +tdGNU Lesser General Public License (LGPL)/td + /tr +/table + /subsection + subsection name=Macker pA build-time architectural testing tool, designed - 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: donate a new selector
On Tuesday, September 9, 2003, at 11:10 AM, Thorsten Möller wrote: Erik Hatcher [EMAIL PROTECTED] wrote: There already is a containsregexp in the latest version of Ant. Uups, I didn't see this because I only worked with Ant 1.5.x. Always best to check with the latest codebase when adding new features :) I have attached a file patch.txt generated by CVS rdiff (patch). Your patch was not diffed against anything. Could you diff against the lastest CVS version and then enter your patch as a Bugzilla enhancement request? Thanks, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: donate a new selector
There already is a containsregexp in the latest version of Ant. I'm
not sure how the implementations compare. Could you compare yours with
it and offer any benefits yours has as a patch against the HEAD version
of Ant's codebase?
Erik
On Friday, September 5, 2003, at 02:18 PM, Thorsten Möller wrote:
Hi,
I wrote a new selector named ContainsRegexpSelector. It works pretty
much
the same like the ContainsSelector except that it uses a regular
expression to decide wheter including a file in a particular fileset.
Because I think there is a commond need for such a selector I would
donate
the code to the Ant project. I did not test the code very exhaustive
but I
think it works ok (the code is mostly a composition from different Ant
classes, i.e. I copied a lot Also there is no documentation except the
Java Doc comments.
At the end you will find the code.
I would be very pleased to see the selector as a normal part in the
project some day.
Thorsten Möller
---
/*
* Created on 05.09.2003
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software
itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names Ant and Apache Software
*Foundation must not be used to endorse or promote products
derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.tools.ant.types.selectors;
import java.io.File;
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
import org.apache.tools.ant.types.Parameter;
import org.apache.tools.ant.types.selectors.BaseExtendSelector;
import org.apache.tools.ant.util.regexp.Regexp;
import org.apache.tools.ant.util.regexp.RegexpFactory;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Project;
/**
* Selector that filters files based on whether they contain a
* particular pattern expressed with a regular expression.
*
* Note: This class was directly copied from the Apache Ant project
* codeorg.apache.tools.ant.types.selectors.ContainsSelector/code
* class. This results in the Apache reference at the beginning of
* this file.
*
* @author Thorsten Möller - [EMAIL PROTECTED]
*
* $Revision: $; $Author: $; $Date: $
*/
public class ContainsRegexpSelector extends BaseExtendSelector
{
private boolean byline;
private String flags;
private Regexp regexp = null;
private static final RegexpFactory factory = new RegexpFactory();
public static final String PATTERN_KEY = pattern;
public static final String FLAGS_KEY = flags;
public static final String BYLINE_KEY = byline;
public ContainsRegexpSelector()
{
this.regexp = factory.newRegexp();
}
public String toString()
{
StringBuffer buf = new
Re: Request
On Wednesday, August 27, 2003, at 07:06 PM, Martin Gainty wrote: when build.properties contains j2ee.home=J:/J2EE/j2ee_sdk_win ant builds correctly When build.properties contains j2ee.home=J:\J2EE\j2ee_sdk_win ant doesnt build because it cannot resolve JAVA_HOME PLEASE make the forward and back slashes interchangeable this is an INVALID request in fact i marked a Bugzilla issue yesterday as INVALID for this. read about java.util.Properties file syntax. backslash is a metacharacter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Image scaling
Nice! +1 On Thursday, August 21, 2003, at 01:58 PM, Rob Oxspring wrote: First up, sorry for no unit tests - just doing enough to get by for now :) Anyway, I was using the image task to create thumbnails and couldn't figure out how to keep proportions of an image but keep it within a fixed size. My solution was to change the keepproportions attribute to be a little cleverer. The keepproportions attribute is no more and has been replaced by the proportions attribute has been added with the following features: proportions=ignore - treat the dimensions independantly (==keepproportions=false and is default) proportions=width - keep proportions based on the width (==keepproportions=true) proportions=height - keep proportions based on the height proportions=fit - keep proportions and fit in the supplied dimensions proportions=cover - keep proportions and cover the supplied dimensions So for example I can use the following to create thumbnails of my images and make sure they all fit within the 160x160 size whether the image is portrait or landscape. image destdir=samples/low overwrite=yes fileset dir=samples/full filename name=**/*.jpg/ /fileset scale width=160 height=160 proportions=fit/ /image Hope that's helpful to others, Rob - 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: Nested elements
Also, in addition to the information Jan has sent, have a look at the
Feb. issue of JavaPro magazine (its online). I wrote an article that
describes exactly what you are asking about.
Erik
On Thursday, August 21, 2003, at 02:12 AM, Andrei wrote:
Dear Antoine,
the problem is that i have to write the code for the uni-d task i
have to
support that sintax. I understand that i have to write some functions
add, or addConfigured but i don,t know how to write the functions. I
have
problems with the function body, i don't know what to write there.
Can you help me?
- Original Message -
From: Antoine Levy-Lambert [EMAIL PROTECTED]
To: Ant Developers List [EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 7:01 PM
Subject: Re: Nested elements
You should ask help from the person who wrote the uni-d task.
The source code of uni-d task should have an addConfig method.
There should be a datatype config corresponding to what you have in
the
config section.
The source code for config should have an addAttribute method
There should also be a datatype attribute.
You also need to do typedefs for attribute and config so that ant
understands these special datatypes.
Cheers,
Antoine
- Original Message -
From: Andrei [EMAIL PROTECTED]
To: Ant Developers List [EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 3:53 PM
Subject: Nested elements
I have a task called uni-d
target name=UniDTask
taskdef name=uni-d
classname=be.unid.generate.AntTask
classpath=${unid.dir}/uni-d.jar
classpathref=task.path
/
/target
and here i use it:
target name=task depends=UniDTask
uni-d
appdir=D:\Work\Uni-D\test\src\uni-d
definition=test1.xml
outputdir=../../build/src
spackage=be.unid.test.om
template=xejb
config
name=extra
attribute name=datasource
value=java:/ICtraceDS/
attribute jndi=IC-trace/
/config
/uni-d
This task add's the values for attributes:
appdir; definition; outputdir; spackage; template in
the
config section of a ini file. The problem is that i have to create
another
section in the ini file named extra and add the values for the
parameters
datasource and jndi in the extra section of ini file. For this
purpose i
must use the sintax in as you can se above:
config
name=extra
attribute name=datasource
value=java:/ICtraceDS/
attribute jndi=IC-trace/
/config
How can i do that?
Andrei
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PMC-VOTE] Ant 1.5.4
+1 On Tuesday, August 12, 2003, at 03:09 AM, Stefan Bodewig wrote: [It is the PMC's responsibility to ensure that our releases are OK, so only PMC member votes are binding, that shouldn't stop anybody else from speking her/his mind.] Conor has created the 1.5.4 distribution, it can be found at http://cvs.apache.org/~bodewig/ant-1.5.4/. In addition I've diffed the source and binary releases of 1.5.3-1 against their corresponding files and the results are in that directory as well (*-dist.diff). All javadocs differ, but I've verified that the only changes are style changes. Please vote for/against these archives as the 1.5.4 release. Here's my +1 for starters. Stefan - 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: [VOTE] Ant 1.5.4 Release Plan
+0 - go for it if you like! :) On Wednesday, August 6, 2003, at 01:41 PM, Steve Loughran wrote: Stefan Bodewig wrote: No long winded plan as this one should be rather trivial IMHO. +1 The plan: * We don't commit anything to the 1.5 branch anymore (we don't so so anyway). * On Monday August 11th during the morning (GMT) the release manager syncs the website changes from the HEAD branch to the 1.5 branch and creates a 1.5.4 release from it. Following the Release guidelines in our CVS module. * The release will be put into our distribution directory and the release manager will call for a PMC vote on it. * If the vote passes, the release will be announced to the public, otherwise the files will be removed from the distribution area again. Release Manager: I volunteer to take the role of the release manager, although I'll probably need some help to get all optional dependencies together. Some notes: The only changes over 1.5.3 will be the changes to javah and the VAJ tasks. Therefore I plan to explicitly state in the release notes as well as the announcements that there is no reason to upgrade from 1.5.3 unless you use javah on JDK 1.4.2 or VAJ. The announcement will also once again state that this is the last (planned) Ant release that will run on a 1.1 Java VM. All changes are based on patches from people who had problems with the two areas originally - and have been verified to work by multiple people. Therefore I don't think we'll need a release candidate or even beta build. Stefan - 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: [patch] MailMessage.java
Please create a Bugzilla issue for this and attach a patch file.
Erik
On Saturday, August 2, 2003, at 03:30 PM, Michael Davey wrote:
Hello,
Here is a patch for org/tools/mail/MailMessage.java that adds the
following:
* Support for message encoding (alphabets)
* Fixes to headers for when an optional header hasn't been set (used
to send blank headers) (we should check that at least one header from
the set: to, cc, bcc, resent-to, resent-cc, resent-bcc exists - but
don't at the moment)
* changes to some comments
--
Michael
Index: ant/src/main/org/apache/tools/mail/MailMessage.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/mail/MailMessage.java,v
retrieving revision 1.17
diff -u -r1.17 MailMessage.java
--- ant/src/main/org/apache/tools/mail/MailMessage.java 19 Jul 2003
11:20:23 - 1.17
+++ ant/src/main/org/apache/tools/mail/MailMessage.java 2 Aug 2003
17:40:03 -
@@ -66,6 +66,7 @@
import java.io.PrintStream;
import java.io.BufferedOutputStream;
import java.io.OutputStream;
+import java.io.UnsupportedEncodingException;
import java.net.Socket;
import java.net.InetAddress;
import java.util.Vector;
@@ -131,9 +132,15 @@
*/
public class MailMessage {
+/** default mailhost */
+public static final String DEFAULT_HOST = localhost;
+
/** default port for SMTP: 25 */
public static final int DEFAULT_PORT = 25;
+/** default encoding: iso-8859-1 */
+public static final String DEFAULT_ENCODING = iso-8859-1;
+
/** host name for the mail server */
private String host;
@@ -161,6 +168,8 @@
private Socket socket;
+private String encoding;
+
/**
* Constructs a new MailMessage to send an email.
* Use localhost as the mail server with port 25.
@@ -168,7 +177,7 @@
* @exception IOException if there's any problem contacting the
mail server
*/
public MailMessage() throws IOException {
-this(localhost, DEFAULT_PORT);
+this(DEFAULT_HOST, DEFAULT_PORT, DEFAULT_ENCODING);
}
/**
@@ -179,7 +188,7 @@
* @exception IOException if there's any problem contacting the
mail server
*/
public MailMessage(String host) throws IOException {
- this(host, DEFAULT_PORT);
+this(host, DEFAULT_PORT, DEFAULT_ENCODING);
}
/**
@@ -191,8 +200,14 @@
* @exception IOException if there's any problem contacting the
mail server
*/
public MailMessage(String host, int port) throws IOException {
+this(host, port, DEFAULT_ENCODING);
+ }
+
+ public MailMessage(String host, int port, String encoding)
+ throws IOException, UnsupportedEncodingException {
this.port = port;
this.host = host;
+this.encoding = encoding;
replyto = new Vector();
to = new Vector();
cc = new Vector();
@@ -299,19 +314,30 @@
return out;
}
+
+ // RFC 822 s4.1: From: header must be sent
+ // We rely on error checking by the MTA
void setFromHeader() {
setHeader(From, from);
}
+ // RFC 822 s4.1: Reply-To: header is optional
void setReplyToHeader() {
+if ( ! replyto.isEmpty() ) {
setHeader(Reply-To, vectorToList(replyto));
+}
}
+
void setToHeader() {
-setHeader(To, vectorToList(to));
+if ( ! to.isEmpty() ) {
+ setHeader(To, vectorToList(to));
+}
}
void setCcHeader() {
-setHeader(Cc, vectorToList(cc));
+if ( ! cc.isEmpty() ) {
+ setHeader(Cc, vectorToList(cc));
+}
}
String vectorToList(Vector v) {
@@ -327,7 +353,10 @@
}
void flushHeaders() throws IOException {
-// XXX Should I care about order here?
+// RFC 822 s4.1:
+// Header fields are NOT required to occur in any particular
order,
+//except that the message body MUST occur AFTER the headers
+// (the same section specifies a reccommended order, which we
ignore)
Enumeration e = headers.keys();
while (e.hasMoreElements()) {
String name = (String) e.nextElement();
@@ -389,11 +418,12 @@
// * * * * * Raw protocol methods below here * * * * *
- void connect() throws IOException {
+ void connect() throws IOException, UnsupportedEncodingException {
socket = new Socket(host, port);
out = new MailPrintStream(
new BufferedOutputStream(
- socket.getOutputStream()));
+ socket.getOutputStream()),
+ encoding);
in = new SmtpResponseReader(socket.getInputStream());
getReady();
}
@@ -493,6 +523,12 @@
super(out, true); // deprecated, but email is byte-oriented
}
+ public MailPrintStream(OutputStream out, String encoding)
+ throws UnsupportedEncodingException
+ {
+super(out, true, encoding); // deprecated, but email is
byte-oriented
+ }
+
// Mac does \n\r, but that's tough to distinguish from Windows
\r\n\r\n.
// Don't tackle that problem right now.
public void write(int b) {
-
To unsubscribe,
Re: xdocs - link to wiki?
On Tuesday, July 29, 2003, at 10:26 AM, Stefan Bodewig wrote: I'd be very careful with pulling down examples for our tasks from a page that anybody can edit (mostly anonymously) and include it in our distribution as definitive reference information. I'm even hesitant to do it for online docs. Yeah, I understand the hesitation. Although Can I get the Wiki (whichever wiki) to send things like commit mails? I just e-mailed Andy Oliver about whether we can get the nagoya wiki to e-mail dev@ when the Ant or sub pages change. There is an RSS feed, at least. And certainly having an e-mail sent when a page changes is an easy thing to implement - so hopefully that kind of thing is already a feature of at least some wiki packages. I really do not want to browse dozens of pages (as we have dozens of tasks) every day to monitor them - and I certainly do not want to get mails for pages that do not contribute to the Ant manual, of course. No, I would not advocate either of those. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
xdocs - link to wiki?
What are folks thoughts on this? http://weblogs.java.net/pub/wlg/274 So forget about folding examples into Ant's own documentation - let's just link to the Jakarta wiki for them! Although, what about offline documentation? Good question - perhaps have a process that generates static documentation by folding in what is on the wiki at documentation build time? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using ANT API
The PDF looked great (it was the only document I tried) Having your assistance with generating PDF from the proposal/xdocs stuff would be great! Erik On Thursday, July 17, 2003, at 11:23 AM, Andrew Marlow wrote: Has anyone had a chance to look at the work I've done on the Ant manual yet? See http://www.marlowa.plus.com/ant.html Regards, Andrew Marlow There is an emerald here the size of a plover's egg! - 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: Ant Documentation
On Thursday, July 17, 2003, at 01:31 PM, Andrew Marlow wrote: [EMAIL PROTECTED] writes: Hi Andrew, I must confess I have downloaded your bz2 file but not yet opened it. I am interested by your work, because ant documentation needs to be improved, but my personal inclination would be to perfect the proposal of Erik Hatcher (with xdocs) What proposal is that? Look in Ant's CVS in the proposal/xdocs directory. Basically the HTML docs are legacy and we will generate them from Ant's own source code using XDoclet to generate XML descriptors of Ant tasks that can then get transformed into HTML, or whatever format desired. AFAIK, the only other proposal is to use DocBook which my approach will allow via some scripts I am working on. I'd recommend you start with the XML files generated by proposal/xdocs and work from there. Don't use the static HTML files as a basis of your generation. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with import task
I would *love* to see the code and some samples of its usage! I gave up on the import task that is in CVS earlier today it just didn't scale the way I needed it to - nesting was problematic, and multiple import's in one build file had issues. Others are using it though so I feel maybe I'm missing something? Erik On Tuesday, July 15, 2003, at 01:16 PM, [EMAIL PROTECTED] wrote: I agree. I had implemented an import task for 1.5.3 that processed a build file and ignored the project tag on the imported file. I messed with the 1.6 import and found it difficult at best to maintain supportability in the build files. The import I had implemented basically added the targets, properties and references from the import to the current project in place. My build structure is now pretty common with a thin layer of build files in each project. Nested imports are supported and I have been using this for months now without issues. It worked out well, as now I even have imports that are defining my third party dependencies and they are nested so that when I deploy a project, even though it has no direct knowledge of third party dependencies, ALL necessary jars, tlds, dtds, etc. are deployed. I can post the task and sample build file if you'd like... m. Erik Hatcher [EMAIL PROTECTED]To: ant-dev [EMAIL PROTECTED] tions.com cc: Subject: problems with import task 07/15/2003 11:30 AM Please respond to Ant Developers List I'm finally getting around to trying the latest features of CVS Ant in a production environment. The import task will help tremendously, no question, but I've run into a couple of issues: - I tried doing to import's in the same build file, and the second import failed because it could not find the file, although it appears the relative base directory is being mangled after the first import. Or am I confused and missing something here? - Having the stuff imported *after* all the top-level items really is making things tough. I've had to move some top-level stuff specific to my concrete project into an init target since it relies on properties set from the imported build file. I'm guessing this is hard to fix though? I haven't had time to dig deeper into these issues, but I wanted to toss them out there in case someone else is eager to jump on it. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with import task
+1 :)) On Wednesday, July 16, 2003, at 04:32 AM, peter reilly wrote: On Tue, 2003-07-15 at 17:30, Erik Hatcher wrote: I'm finally getting around to trying the latest features of CVS Ant in a production environment. The import task will help tremendously, no question, but I've run into a couple of issues: - I tried doing to import's in the same build file, and the second import failed because it could not find the file, although it appears the relative base directory is being mangled after the first import. Or am I confused and missing something here? - Having the stuff imported *after* all the top-level items really is making things tough. I've had to move some top-level stuff specific to my concrete project into an init target since it relies on properties set from the imported build file. I'm guessing this is hard to fix though? I have make a bugzilla report/patch: http://issues.apache.org/bugzilla/show_bug.cgi?id=21180 that should fix this particular problem. With the patch I can finally use the import task in my build - it has a lot of top-level definitions in the imported common.xml. Peter - 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: problems with import task
On Wednesday, July 16, 2003, at 10:19 AM, Nicola Ken Barozzi wrote: I'm finally getting around to trying the latest features of CVS Ant in a production environment. The import task will help tremendously, no question, but I've run into a couple of issues: - I tried doing to import's in the same build file, and the second import failed because it could not find the file, although it appears the relative base directory is being mangled after the first import. Or am I confused and missing something here? Sorry, but I don't understand. Can you please post a buildfile with the problem? We can then fix it and add it to the testcases. I did this: import file=../shared.xml/ import file=../shared-db.xml/ The second import failed because (sorry, I don't have the exact message handy) it could not find the file, even though it was there in the parent directory. - Having the stuff imported *after* all the top-level items really is making things tough. I've had to move some top-level stuff specific to my concrete project into an init target since it relies on properties set from the imported build file. I'm guessing this is hard to fix though? At first it worked this way, but then something was changed. It should not be hard. I'll try Peter's recent patch to it out soon and see where things are then. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: From apache-ant-1.5.3-1-src to build ant.jar and optional.jar
On Tuesday, July 15, 2003, at 04:40 PM, Alexey Solofnenko wrote: Is there a list of jars/URLs and where they should be copied? I personally found some and put them into ant/lib/optional. Is it how it should be done? There is no complete list of everything you need, but there is a bit in the manual about optional libraries. I do exactly what you have done, put them into lib/optional. Use ant -diagnostics to see how complete your build is. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get Ant task Id?
You can use the taskName attribute on tasks to set a different name for logging purposes. Use getTaskName() in your listener/logger to access this name. There is no id automatically assigned by Ant, its set via the build file writer if you so choose. Erik On Tuesday, July 1, 2003, at 02:05 PM, Mazzolini, Mike wrote: According to the Ant book, I have, it indicates that Ant generates an Id for each task that it performs. However, I can't seem to get my hands on this Id. I need it to determine what task has actually finished when there is more than one task with the same name. Any ideas? Thanks. Mike Mazzolini [EMAIL PROTECTED] - If you think you can or you think you can't, you're right! - 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: [VOTE] Jan Materne as committer
+1 On Wednesday, June 25, 2003, at 06:06 AM, Conor MacNeill wrote: I'd like to propose Jan Materne as an Ant committer. I think his contribution in recent months has been quite obvious both on the dev and user lists and also the bug reports. I think he would make a great committer. Here's my +1 to start the ball rolling. Conor - 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: ChecksumTest fails
On Tuesday, June 24, 2003, at 11:39 AM, Stefan Bodewig wrote: Better don't touch filenames when using a case-insensitive filesystem, Erik ;-) I'm on Mac OS X. I did not touch any of the files (myself) other than applying Aslak's patch and running a build and run-single-test. Sorry 'bout that all tests worked for me before committing :) Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.6 todo thoughts
On Tuesday, June 24, 2003, at 12:12 PM, Steve Loughran wrote: Personally I think machine-generated is the right approach, but we need to transfer the rules about optional attributes into the xdocs, then sit down and migrate all the current docs into xdocs form. Also, is xdocs currently running? Yup, its running with Gump: http://nagoya.apache.org/gump/javadoc/ant/proposal/xdocs/build/docs/ manual/index.html I'll reply more on the 1.6 thread a bit later (today hopefully). Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.6 todo thoughts
On Tuesday, June 24, 2003, at 08:43 AM, Conor MacNeill wrote: I'd like to kick off a discussion on what needs to be done to get Ant 1.6 to a release. I'm just going to ramble through some random thoughts I have been having in no particular order just to get discussion started. +1 on Conor to get the momentum rolling on this. It's tough to be psyched about working towards new releases when I personally run a CVS copy of Ant :) 1. Code cleanup +1 on getting Checkstyle reports going so we can clean stuff up. I'll certainly chip in after seeing a report and do a bit of cleanup where I can. 4. xdocs proposal manual generation I'm not sure if this is still at the proposal stage or ready for primetime. I think we probably won't progress unless we agree that this is the way to generate the Ant manual and commit to supporting it as part of the standard build process. If it is the way to go, I'd like to hurry it along. There have been a couple of reasons why I have not hurried it along... 1) I'm ultra-busy. 2) I wanted to let others jump in and contribute to it so it was communally owned. I personally feel its the right way to go and there is a lot of infrastructure already in place. There are still lots of gaps to be filled in, as I'm sure we'll see as we work on replacing the existing docs. For one, datatypes are not documented with this process yet. Right now the setproxy doco is generated and looks a bit different from the hand carved manual pages. We probably want a consistent look in the manual and perhaps even a similar look to the rest of the Ant site. Also I want to have some PDF generation going. +1 - I'll try to migrate xdocs upward to the main tree and integrate it into the main build process. It can be a bit tricky because the build process needs to be running the same version of Ant that its processing to really work properly... we'll have to see how it goes. macrodef could be done and would be a good idea. It would provide a way of composing tasks into larger tasks. Peter has mentioned a system to provide task default attribute settings for standard tasks. I've thought about an antschema as a companion to antstructure, potentially supporting the polymorphic stuff. I like the macrodef idea! 7. Bug reduction. I'd like to go through the bugs like a dose of salts. I'd like to see all committers getting stuck into the backlog. The things that aren't going to be done or are unlikely in the forseeable future (e.g. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3807) could go, IMHO. Voting for bugs will help us to prioritise them. No promises, but I'll take a look at what bugs exist in my domains of fancy and see if there are any I can knock out. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit FormatterElement.java JUnitTask.java
On Wednesday, May 28, 2003, at 09:26 AM, Conor MacNeill wrote: On Wed, 28 May 2003 11:12 pm, [EMAIL PROTECTED] wrote: ehatcher2003/05/28 06:12:04 Modified:.WHATSNEW docs/manual/OptionalTasks junit.html src/main/org/apache/tools/ant/taskdefs/optional/junit FormatterElement.java JUnitTask.java Log: Apply patch from #20270 - adds if/unless clause to junit formatters. Submitted by Eli Tucker Do we really want if/unless on every subelement of each task? IMHO, this feels wrong. Well, I only added it to one element of one task :) - but your point is taken. The reason I applied this patch is that I think it really speeds up running JUnit tests if you don't want XML output (running interactively), but want XML output when running continuous integration builds for reporting purposes. If folks feel strongly about it, I'll revert it. There already is precedent in the junit task for this type of thing with the test/batchtest if/unless capability. Erik
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit FormatterElement.java JUnitTask.java
On Wednesday, May 28, 2003, at 09:36 AM, Stefan Bodewig wrote: There already is precedent in the junit task for this type of thing with the test/batchtest if/unless capability. The if/unless in test is more or less a mirror of if/unless in the include/exclude elements - it is meant to exclude tests when the runtime environment is needed by a test is missing (and similar situations). I use the if/unless on batchtest and test elements to set up a mutually exclusive way of running all tests or a single test. To run a single test, I do this: ant -Dtestcase=SomeTest I use it for isolating tests to decrease the time to get test feedback (for tighter development cycles). Erik
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit FormatterElement.java JUnitTask.java
While this can be a slippery slope if applied to all tasks/elements (I agree), it really has a lot of value in the case Peter mentions. XDoclet could also benefit from such a scheme (but it currently doesn't). XDoclet uses DynamicConfigurator, though, so it could be implemented using that mechanism rather than explicit support for if/unless. Erik On Wednesday, May 28, 2003, at 10:31 AM, peter reilly wrote: On Wednesday 28 May 2003 15:04, Conor MacNeill wrote: On Wed, 28 May 2003 11:27 pm, Erik Hatcher wrote: If folks feel strongly about it, I'll revert it. I'm not into strong feelings :-). Let's see what people think. +1 to keep the if attribute I use this all the time with cc: compiler id=compiler.options compilerarg value=-ggdb unless=optimize/ compilerarg value=-pthread if=is.linux/ compilerarg value=-Wall/ compilerarg value=-Wstrict-prototypes/ compilerarg value=-O3 if=optimize/ compilerarg value=-mcpu=pentium4 if=linux/ /compiler Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Peter Reilly as committer
+1 On Thursday, May 22, 2003, at 07:26 AM, Conor MacNeill wrote: Hi, I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PMC VOTE] Adoption of Bylaws
+1 On Tuesday, May 20, 2003, at 03:00 AM, Conor MacNeill wrote: PMC members, I'd like to move towards adoption of the bylaws draft. http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/proposal/ant-site/ anakia/docs/bylaws.html?rev=1.16 Could you please view this and vote indicating your position. If you wish to vote -1 because you don't believe the bylaws include all they should, that's OK, of course, but please give me details on what changes are required. Thanks Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/proposal/xdocs/src/org/apache/tools/ant/xdoclet AntXDocletTask.java DatatypeSubTask.java DatatypeTagsHandler.java IndexGen.java
Stefan,
On Tuesday, April 29, 2003, at 03:42 PM, [EMAIL PROTECTED] wrote:
+ target name=gen depends=jar
taskdef name=antdoclet
- classname=xdoclet.modules.apache.ant.AntDocletTask
- classpathref=xdoclet.classpath/
+ classname=org.apache.ant.xdoclet.AntDocletTask
+ classpath
+path refid=xdoclet.classpath/
+pathelement location=${build.dir}/xdoclet-ant.jar/
+ /classpath
+/taskdef
Will Gump be ok with this change? I get an eerie feeling that it won't
like trying to use a JAR that is built during the build. XDoclet needs
to have a JAR to look at though, as it needs to get at
META-INF/xdoclet.xml
Thanks,
Erik
Re: [Xdoclet-devel] CVS: xjavadoc build.xml,1.49,1.50
Sorry for the delay - was offline for the weekend...
I didn't change the value of those properties, actually. I just
changed 'value' to 'location' (sorry, its my picky Ant build file
syntax checker in me :).
But I see Stefan fixed up Gump.
Thanks!
Erik
On Saturday, April 26, 2003, at 03:14 PM, Jesse Stockall wrote:
On Fri, 2003-04-25 at 15:04, Erik Hatcher wrote:
Update of /cvsroot/xdoclet/xjavadoc
In directory sc8-pr-cvs1:/tmp/cvs-serv27780
Modified Files:
build.xml
Log Message:
Fix for Gump. XJD-21
Index: build.xml
===
RCS file: /cvsroot/xdoclet/xjavadoc/build.xml,v
retrieving revision 1.49
retrieving revision 1.50
diff -C2 -r1.49 -r1.50
*** build.xml 15 Apr 2003 08:57:57 - 1.49
--- build.xml 25 Apr 2003 19:04:12 - 1.50
***
*** 3,9
project name=XJavaDoc default=jar basedir=.
property name=version value=1.0-SNAPSHOT/
!property name=build.dir value=${basedir}/target/
!property name=jardir value=${build.dir}/
!property name=rootdir value=${basedir}/
This has broken the Gump runs for anything that depends on XJavadoc
All the other projects are still looking in xjavadoc/build/lib instead
of xjavadoc/target
--
Jesse Stockall [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
xdoclet-devel mailing list
xdoclet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: cvs commit: ant/proposal/xdocs/lib xjavadoc-1.0-SNAPSHOT.jar xdoclet-1.2b3-dev.jar xdoclet-apache-module-1.2b3-dev.jar xdoclet-ejb-module-1.2b3-dev.jar xdoclet-web-module-1.2b3-dev.jar xdoclet-xdoclet-module-1.2b3-dev.jar xdoclet-xjavadoc-uc-1.2b3-dev.jar
Oops... sorry - I should have done this the other day. I had the JAR's in the right directory, just did not commit them. Erik On Monday, April 28, 2003, at 12:45 PM, [EMAIL PROTECTED] wrote: jesse 2003/04/28 09:45:22 Modified:proposal/xdocs/lib xdoclet-1.2b3-dev.jar xdoclet-apache-module-1.2b3-dev.jar xdoclet-ejb-module-1.2b3-dev.jar xdoclet-web-module-1.2b3-dev.jar xdoclet-xdoclet-module-1.2b3-dev.jar Added: proposal/xdocs/lib xjavadoc-1.0-SNAPSHOT.jar Removed: proposal/xdocs/lib xdoclet-xjavadoc-uc-1.2b3-dev.jar Log: Update the versions of XDoclet and XJavaDoc Revision ChangesPath 1.2 +463 -459 ant/proposal/xdocs/lib/xdoclet-1.2b3-dev.jar Binary file 1.3 +145 -148 ant/proposal/xdocs/lib/xdoclet-apache-module-1.2b3-dev.jar Binary file 1.2 +598 -634 ant/proposal/xdocs/lib/xdoclet-ejb-module-1.2b3-dev.jar Binary file 1.2 +97 -102 ant/proposal/xdocs/lib/xdoclet-web-module-1.2b3-dev.jar Binary file 1.2 +184 -200 ant/proposal/xdocs/lib/xdoclet-xdoclet-module-1.2b3-dev.jar Binary file 1.1 ant/proposal/xdocs/lib/xjavadoc-1.0-SNAPSHOT.jar Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/proposal/xdocs/dvsl task.dvsl
Got patches to the antdoclet stuff you'd like me to commit on the
XDoclet codebase?
Nice work (having not run it yet myself, just browsing the commit
messages)!
Erik
On Friday, April 25, 2003, at 10:09 AM, [EMAIL PROTECTED] wrote:
jesse 2003/04/25 07:09:11
Modified:proposal/xdocs/lib xdoclet-apache-module-1.2b3-dev.jar
proposal/xdocs/dvsl task.dvsl
Log:
Generate attribute requirements
Revision ChangesPath
1.2 +103 -92
ant/proposal/xdocs/lib/xdoclet-apache-module-1.2b3-dev.jar
Binary file
1.5 +40 -7 ant/proposal/xdocs/dvsl/task.dvsl
Index: task.dvsl
===
RCS file: /home/cvs/ant/proposal/xdocs/dvsl/task.dvsl,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- task.dvsl 14 Feb 2003 20:37:23 - 1.4
+++ task.dvsl 25 Apr 2003 14:09:11 - 1.5
@@ -54,7 +54,7 @@
#set( $project =
$node.selectSingleNode(document('xdocs/stylesheets/project.xml')/
project ) )
#if ($node.name().equals(task))
#set( $title = #capitalize($attrib.name) Task )
-#set( $summary = $node.short-description )
+#set( $summary = $node.short-description )
#end
html
@@ -105,7 +105,7 @@
!-- Applying task/long-description --
#**#$context.applyTemplates(long-description)
#* *##end
-#* *#$context.applyTemplates(structure/attributes)
+#* *#$context.applyTemplates(structure/attribute-groups)
#* *#$context.applyTemplates(structure/elements)
#* *#$context.applyTemplates(external/section)
#**##end
@@ -154,6 +154,16 @@
#end
#*
+Macro to format a table body cell that spans multiple rows
+*#
+#macro( tdmr $text $rows )
+td bgcolor=$table-td-bg valign=top align=left
rowspan=$rows
+ font color=#00 size=-1
face=arial,helvetica,sanserif$text/font
+/td
+#end
+
+
+#*
Macro to format a section banner
*#
#macro( section $anchor $name )
@@ -215,19 +225,18 @@
#*
Process top level attributes
*#
-#match( structure/attributes )
+#match( structure/attribute-groups )
!-- Start Attributes --
table border=0 cellspacing=0 cellpadding=2 width=100%
trtdnbsp;/td/tr
-
-#* *##section(attributes Parameters)
-
+#* *##section(attributes Parameters)
trtdblockquote
table
tr
#* *##th(Attribute)
#* *##th(Description)
#* *##th(Type)
+#* *##th(Requirement)
/tr
#**#$context.applyTemplates(*)
/table
@@ -238,14 +247,29 @@
#end
#*
+Process attribute group
+*#
+#match( structure/attribute-groups/attribute-group )
+!-- Attribute Group --
+#set ($attributeGroup = $attrib.description)
+#set ($numGroups = $node.selectNodes(attribute).size())
+#set ($inGroup = true)
+#**#$context.applyTemplates(*)
+#end
+
+#*
Process a single attribute
*#
-#match( attribute )
+#match( structure/attribute-groups/attribute-group/attribute )
!-- Attribute --
tr
#**##td($attrib.name)
#**##td($node.description)
#**##td($attrib.briefType)
+#if ($inGroup)
+#**##tdmr($attributeGroup $numGroups)
+#set ($inGroup = false)
+#end
/tr
#end
@@ -383,6 +407,15 @@
$context.applyTemplates(*)
/td/tr
/table
+#end
+
+#*
+ * process a the requirement groups
+ *#
+#match( requirement-group )
+#if ($regGroup == $attrib.name)
+#* *#$attrib.description
+#end
#end
#match( source )
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib
On Friday, April 25, 2003, at 01:25 PM, Costin Manolache wrote: All I ask is to do the changes in the core separately. +1 I'm in agreement with you on the order of events, Costin, 100%. antlib with tasks/datatypes is fair game to migrate into HEAD, then core changes to make the other components work as pluggable pieces, then refactoring antlib to support it. I also agree with the use of interfaces (not just marker ones, per se) for distinguishing what components are used for. Again, its cool that Ant supports making lightweight tasks, but I think it should be more rigid in the future and mandating components implement a particular interface. Most of us at least extend Task when writing tasks, I suspect, too. :) Erik
Re: cvs commit: ant/proposal/xdocs/dvsl task.dvsl
On Friday, April 25, 2003, at 10:41 AM, Jesse Stockall wrote: On Fri, 2003-04-25 at 10:29, Erik Hatcher wrote: Got patches to the antdoclet stuff you'd like me to commit on the XDoclet codebase? Yes. I've committed the patches to XDoclet's CVS that you sent to me. Let me know if there are any issues or I missed anything. I will work on migrating the antdoclet stuff to Ant's CVS next, and removing it from XDoclet's codebase. Erik
Re: antlib
On Friday, April 25, 2003, at 01:39 PM, peter reilly wrote: I'm in agreement with you on the order of events, Costin, 100%. antlib with tasks/datatypes is fair game to migrate into HEAD, then with xml or with properties? I don't care. :)) So take that as a +0 on either - for the time being. I think XML is the right choice, personally, but its of little concern to me. Erik
Re: Antlib descriptor
On Friday, April 25, 2003, at 01:39 PM, Costin Manolache wrote: New thread. +1 :) However I'm more convinced than ever that the XML should use a subset of ant, and reuse the same processing infrastructure. I.e. not another parser or rules. I'll defer commenting on this until I ponder it more and see what others say about it. Erik and few others seem to believe that the XML vocabulary doesn't matter, and anything can be generated by xdoclet and processed. If this is the case - then using ant syntax in the antlib descriptor would be as good as another syntax. Well, again, don't stretch my thoughts on this too far. I meant it didn't matter *now*, in terms of getting it migrated to HEAD and having it in a place handy for all of us to work with and evolve it. It does matter though. - maybe we want antlibs to have some initialization. This can be easily done by allowing more ant elements in the descriptor - maybe we'll want to allow antlib to declare targets - that could be used in depends or antcall ( target name=foo depends=myAntLib:antlibTarget/ ). Wow ok, still pondering Again - those are just examples, there are a lot of things that could be done easily. Even if you don't need any of this - it would be nice to not have to repeat the long and painfull evolution of the main xml processor. It'll take some thinking and convincing for me to see why antlib needs descriptors that get processed like Ant build files. Something as simple as Digester would seem to do the trick (bootstrap craziness?!) but as I said, I want to see what others think and let myself consider your idea a bit more. Erik
Re: antlib
On Thursday, April 24, 2003, at 02:23 PM, Costin Manolache wrote: Erik Hatcher wrote: We don't really need to get hung up on the syntax of a descriptor at this stage. Let's get something working in HEAD and work with it. XDoclet can be used to generate these descriptors anyway, and it likely be considered the best practice way to do it anyway. I think the syntax of the descriptor is pretty important. Obviously I disagree, but not terribly strongly. This is where I differ. I like what I've heard so far, but I really don't like the total looseness of Ant build files, and I don't think we should propagate that same scheme. I understand how it evolved and that ease of use was one of the primary factors for Ant's looseness, not to mention that it was around before namespaces were really solidified. The looseness is pretty fundamental in ant, and at least IMO is one of the reasons it works so well. My take is that since we are using XML for build file syntax that we should embrace all of the features of XML like namespaces and schemas. Currently we are playing fast and loose with it and tools are not typically happy with build.xml files. I know in my build file IDEA hilites tons of errors (that are not really errors). You are proposing that we use Java's standard MANIFEST features, but why not stick to standard XML features like a schema? Don't get me wrong though - I think its quite cool that Ant is as extensible as it is and I've learned a lot of cool things with reflection and how it plays with the build file format thanks to working with Ant. I'm the one that added the DyanmicConfigurator - so I can be blamed for making schema compliance even more impossible to obtain. Again, lets not get hung up on the descriptor syntax. Working implementation first - then we can debate the details. We can make it the defining goal for an Ant 1.6 release when all the fiddly details have been ironed out! :) We have had working implementation(s) for quite a while. But the current one does not support adding other components like conditions, mappers, filters, and selectors. Erik
Re: antlib
On Thursday, April 24, 2003, at 03:06 PM, Costin Manolache wrote: Erik Hatcher wrote: I think the syntax of the descriptor is pretty important. Obviously I disagree, but ngot terribly strongly. So you believe that anything can go in the XML tags, no design or thinking is needed - because you could translate it with XSL or some tools will process it ? This is getting a bit exaggerated but I don't feel the syntax of an XML descriptor is that relevant right now given the other issues on the table. That's the main point I'm making with this. But the current one does not support adding other components like conditions, mappers, filters, and selectors. Does ant support this ? No, not currently in a pluggable manner. Isn't that the goal for antlib? Erik
Fwd: Xindice: a final suggestion
FYI. Begin forwarded message: From: Gianugo Rabellino [EMAIL PROTECTED] Date: Tue Apr 22, 2003 1:35:06 PM US/Eastern To: Gump code and data gump@jakarta.apache.org Subject: Xindice: a final suggestion Reply-To: Gump code and data gump@jakarta.apache.org As some of you might have noticed, Xindice is failing again, this time on a wicked part: in order to keep the build clean, a fileset of jars is specified at a project level and reused further on during the build: classpaths are set using this fileset and the fileset itself is used to configure the lib dir on the war task. Now, Gump build is just fine, but packaging fails because the latest Ant *from CVS* expects a zipfileset as the parameter of the war/lib element, while we just have a fileset. Even more: the *current* (stable) release of Ant supports only filesetat a project level, not zipfileset, so I cannot change the build file to accomodate the new ANT expected settings. Now, this is exactly the problem that Gump is supposed to anticipate, but what would be the best solution? 1. tell Gump not to build the war (ugly workaround from a Gump POV); 2. upgrade our Ant version to the CVS one (somehow scary); 3. have a less maintainable build file removing the fileset and duplicating the list (ugly workaround from an Xindice POV); 4. don't use the war task altogether and roll back to the jar one (don't like it); 5. Bug the Ant developers so that they rollback the change to the War task, accepting also plain filesets as it was in the past: this sounds like the best solution to me since it was them to introduce a backward incompatible change (but I'm sure it was for a reason). I'm kinda stuck. Suggestions? TIA, -- Gianugo Rabellino Pro-netics s.r.l. http://www.pro-netics.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] propertycopy
On Monday, April 21, 2003, at 10:38 AM, Conor MacNeill wrote: On Mon, 21 Apr 2003 07:19 pm, Erik Hatcher wrote: I use propertycopy from ant-contrib a lot. I propose that it be migrated to Ant's HEAD. Objections? +1 Who is the copyright owner? I think it is up to them to donate the code - we cannot just absorb it. Oh, ok I was under the impression that the code in ant-contrib was being primed for contribution to Ant itself. There is an @author tag on the source code, but its using the Apache Software License. I could re-implement it (clean-room, even, as I didn't even see the code, just the license), or could someone on the ant-contrib group inquire to see if its fair game to migrate? Thanks, Erik
Re: [Patch] cvstagdiff.html
Chris,
Thanks for these patches. It would be best if you filed these as
attachments to Bugzilla issues. Its especially difficult to apply
patches sent via e-mail because of formatting issues with e-mail
readers - and its best for our tracking purposes to put them in
Bugzilla.
Erik
On Sunday, April 20, 2003, at 02:47 PM, Chris Reeves wrote:
Added cvs requirement (from cvs.html).
Index: cvstagdiff.html
===
RCS file: /home/cvspublic/ant/docs/manual/CoreTasks/cvstagdiff.html,v
retrieving revision 1.5
diff -u -r1.5 cvstagdiff.html
--- cvstagdiff.html 19 Feb 2003 09:23:19 - 1.5
+++ cvstagdiff.html 20 Apr 2003 18:46:13 -
@@ -8,6 +8,9 @@
h3Description/h3
pGenerates an XML-formatted report file of the changes between two
tags
or dates recorded in a
a href=http://www.cvshome.org/; target=_topCVS/a repository.
/p
+pbImportant:/b This task needs cvs on the path. If it isn't,
you
will get
+an error (such as error 2 on windows). If lt;cvsgt; doesn't work,
try to
execute cvs.exe
+from the command line in the target directory in which you are
working.
h3Parameters/h3
table border=1 cellpadding=2 cellspacing=0
tr
@@ -141,13 +144,13 @@
It writes these changes into the file codetagdiff.xml/code./p
h4Generate Report/h4
-pAnt includes a basic XSLT stylesheet that you can use to generate
+pAnt includes a basic XSLT stylesheet that you can use to generate
a HTML report based on the xml output. The following example
illustrates
how to generate a HTML report from the XML report./p
pre
-lt;style in=tagdiff.xml
- out=tagdiff.html
+lt;style in=tagdiff.xml
+ out=tagdiff.html
style=${ant.home}/etc/tagdiff.xslgt;
lt;param name=title expression=Ant Diff/gt;
lt;param name=module expression=ant/gt;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/OptionalTasks image-classdiagram.gif image.html
Jan - thank you for contributing the documentation for image. Just the other day I was refreshing my memory on image and noticed no documentation existed yet. I was lazy and was going to keep pushing proposal/xdocs so that it would take care of it for us! :) Thanks for beating me to it. Erik On Wednesday, April 16, 2003, at 08:44 AM, [EMAIL PROTECTED] wrote: bodewig 2003/04/16 05:44:44 Modified:docs/manual install.html optionaltasklist.html Added: docs/manual/OptionalTasks image-classdiagram.gif image.html Log: Documentation for the image task. PR: 19055 Submitted by: Jan Matèrne jan at materne dot de Revision ChangesPath 1.50 +6 -0 ant/docs/manual/install.html Index: install.html === RCS file: /home/cvs/ant/docs/manual/install.html,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- install.html 10 Apr 2003 06:11:02 - 1.49 +++ install.html 16 Apr 2003 12:44:44 - 1.50 @@ -424,6 +424,12 @@ tda href=http://www.jcraft.com/jsch/index.html; target=_tophttp://www.jcraft.com/jsch/index.html/a/td /tr + tr +tdJAI - Java Advanded Imaging/td +tdimage task/td +tda href=http://java.sun.com/products/java-media/jai/; + target=_tophttp://java.sun.com/products/java-media/jai//a/td + /tr /table br hr 1.37 +1 -0 ant/docs/manual/optionaltasklist.html Index: optionaltasklist.html === RCS file: /home/cvs/ant/docs/manual/optionaltasklist.html,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- optionaltasklist.html 13 Mar 2003 09:01:54 - 1.36 +++ optionaltasklist.html 16 Apr 2003 12:44:44 - 1.37 @@ -28,6 +28,7 @@ a href=OptionalTasks/echoproperties.htmlEchoproperties/abr a href=OptionalTasks/ftp.htmlFTP/abr a href=OptionalTasks/icontract.htmlIContract/abr +a href=OptionalTasks/image.htmlImage/abr a href=OptionalTasks/jarlib-available.htmlJarlib-available/abr a href=OptionalTasks/jarlib-display.htmlJarlib-display/abr a href=OptionalTasks/jarlib-manifest.htmlJarlib-manifest/abr 1.1 ant/docs/manual/OptionalTasks/image-classdiagram.gif Binary file 1.1 ant/docs/manual/OptionalTasks/image.html Index: image.html === html head meta http-equiv=Content-Language content=en-us titleImage Task/title /head body h2a name=imageImage/a/h2 h3Description/h3 pApplies a chain of image operations on a set of files./p pRequires Java Advanced Image API from Sun./p h5Overview of used datatypes/h5 img src=image-classdiagram.gif border=0 alt=Class-Diagram h3Parameters/h3 table border=1 cellpadding=2 cellspacing=0 tr td valign=topbAttribute/b/td td valign=topbDescription/b/td td align=center valign=topbRequired/b/td /tr tr td valign=top failonerror /td td valign=top Boolean value. If false, note errors to the output but keep going. /td td align=center no (defaults to itrue/i) /td /tr tr td valign=top srcdir /td td valign=top Directory containing the images. /td td align=center yes, unless nested fileset is used /td /tr tr td valign=top encoding /td td valign=top Image encoding type. br Valid (caseinsensitive) are: jpg, jpeg, tif, tiff /td td align=center no (defaults to iJPEG/i) /td /tr tr td valign=top overwrite /td td valign=top Boolean value. Sets whether or not to overwrite a file if there is naming conflict. /td td align=center no (defaults to ifalse/i) /td /tr tr td valign=top gc /td td valign=top Boolean value. Enables garbage collection after each image processed. /td td align=center no (defaults to ifalse/i) /td /tr tr td valign=top destdir /td td valign=top Directory where the result images are stored. /td td align=center no (defaults to value of isrcdir/i) /td /tr !-- attributes inherited from MatchingTask -- tr td valign=topincludes/td td valign=topcomma- or space-separated list of patterns of files that must be included. All files are included when omitted./td td valign=top align=centerNo/td /tr tr td valign=topincludesfile/td td valign=topthe name of a file. Each line of this file is taken to be an include pattern/td td valign=top align=centerNo/td /tr tr td valign=top excludes/td td valign=topcomma- or space-separated list of patterns of files that must be excluded. No files (except default excludes) are excluded when omitted./td td valign=top align=centerNo/td /tr tr
