Re: Development Environment suggestions ?
On Thu, 20 Nov 2003, John Austin [EMAIL PROTECTED] wrote: So far I have been playing around like the Neanderthal* that I am. I use Sun Java 1.4.x with xterm, vi, emacs and occasionally Jedit when I feel modern urges. [snip] * Is that term Politically Correct ? Would it be offensive to Europeans ? I (living in Mönchengladbach, less than 40 km from Neandertal) wouldn't mind. But then again I use XEmacs, bash or ksh and Ant (of course) for all my development (and mail reading and TeX writing and coffee making and cooking and ... ;-) Stefan
Re: commons-io [WAS: gump build failed (trunk)]
On Sat, 16 Aug 2003, Jeremias Maerki [EMAIL PROTECTED] wrote: I'll see what I can do about the nightly build, though. http://gump.covalent.net/jars/latest/jakarta-commons-sandbox/ not exactly a nightly build, but the jar that has been created by Gump's last run. If you can put together a target in commons-io that creates a proper distribution, it would be trivial to run it with Gump and possible (while non-trivial) to ask Sam to post the result as a nightly build like he does for several other projects (including Ant for example). The same would be possible for FOP itself, of course. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: move Ant task to Ant project
On Fri, 11 Jul 2003, M. Sean Gilligan [EMAIL PROTECTED] wrote: The advantages to shipping with Ant are that it would become more of a standard and get more exposure and usage. Sure. In the early days Ant used to absorb tasks from each and every problem domain to get more exposure itself. I fully understand that. On the other hand, we are already receiving complaints that there are too many tasks in Ant, so that newbies wouldn't have a chance to learn them all (as if they had to, but that's a different question). One suggestion for Ant libraries - it would be nice to have a task name registry so that the task names can be standardized. That's going to be hard. It's more likely that you can attach an XML namespace to each ant library and that name clashes get resolved by using namespaces. Consider container specific implementations of jspc, it's probably better to have websphere:jspc and tomcat:jspc than forcing each of them to register with some registry and choose some unique name. Also, it might make sense to have a recommended mechanism for having multiple implementations implement the same Ant task. See some support classes in Ant's util.facade package. The mechanism could probably be improved, but at least it is already in use for javac and rmic (and jspc IIRC). and it looks like xslt uses Trax. Historically Ant's xslt task predates TraX - or at least Xalan-J-2. Therefore Ant supports some pluggable mechanism in xslt that needs to be retained for backwards compatibilty (there is a custom implementation for Exolab's AdaptX processor that I'm aware of). If there were a standardized xslfo task it is conceivable that people might want to use a processor other than Fop. The most difficult part is probably going to be to define a common interface for the different processors. Is there a link that I can look at to see the work in progress in this area? For the built-in support for facade tasks, see the util/facade package. This has been more or less untouched since Ant 1.5 IIRC. For a task using it, see javac. The antlib stuff is building up momentum currently. The series of steps leading to is may be best followed by this bugzilla report[1] and the archives of ant-dev, I'd recomment MARC[2] for this, look for antlib as subject. I'm sorry my message really had two *subjects* and I only put one in the subject line. Oh, two is a rather small number for threads that I'm involved in 8-) (I suspected that the Ant committers would feel more comfortable with including a task that had been shipping for some time.) I'd suspect the reaction would be stay where you are, you already have a home. 8-) Stefan Footnotes: [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=19897 [2] http://marc.theaimsgroup.com/?l=ant-devr=1w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: move Ant task to Ant project ( was Contribution - anttask)
On Sat, 12 Jul 2003, Glen Mazza [EMAIL PROTECTED] wrote: Perfectly understandable, as you would not want poorly maintained optional tasks ending up degrading Ant's reputation as a build tool. It's not only a question of reputation. One of Ant's biggest burdens is backwards compatibility, and the more tasks we have, the more difficult it becomes. When we introduce a new task in a release we must be pretty sure that its public interface is a good one - which is pretty hard to do if you don't know the problem domain well enough. And certainly, if less bugs on custom tasks get reported against Ant, we stand a bigger chance to fix those reported against Ant's internals. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: move Ant task to Ant project ( was Contribution - anttask)
On Thu, 10 Jul 2003, M. Sean Gilligan [EMAIL PROTECTED] wrote: Putting the Fop task directly in Ant would be great. I would really like to see that happen. I suppose we could get it in Ant 1.6 if we submit it soon. Does anyone know what the criteria is for inclusion as a Core or Optional task within Ant? What work would be required on our part? Actually, it is not too likely to get accepted at all (I'm an Ant committer and PMC member, but I'm just speaking for myself here - some of it still is speculation). Over the past months (no, years) we've spent a lot of time maintaining optional tasks and fixing bugs in them, more time than we spent on improving Ant itself. As a consequence you'll find a big reluctance with Ant developers to accept any new tasks at all. In particular if the new tasks relies on a third-party tool/library that is an open source project itself. We'd probably send you back to FOP. Not having followed the discussion leading up to this, why would you want to ship it with Ant rather than FOP? Currently we are adding the infrastructure for something we call Ant libraries. Self contained jars that you need to put into ANT_HOME/lib (to be defined) and all tasks/data-types contained within will get discovered by Ant on startup. This will make deploying third party tasks even easier than it is now. First parts of this will be available in 1.6. It's pretty likely that we'll even break up our current set of tasks in the future and ship Ant with only a minimal amount of tasks - the rest will go into separately maintained and separately released Ant libaries. Some more comments. I assume that if we targeted Ant 1.6, we would use the 0.20.x code base. If it wants to be in Ant 1.6, it must not rely on any unreleased code. So if Ant 1.6 was released tomorrow, any FOP task in Ant would have to work with 0.20.5rc3a - any unreleased dependency like CVS HEAD is completely out of question. I don't know how it is done for other Ant tasks with external dependencies, but I suppose the Ant task would check to see if org.apache.fops.apps.Driver is on the classpath before preceding. Currently Ant simply tries to load all task classes (in 1.5.x at startup in 1.6 this will get delayed until you try to use the task). If there a dependency on org.apache.fops.apps.Driver in the task and the class is not available, Ant will catch the NoClassdefFoundError and simply proceed, making the task unavailable. If you then try to run the task, your build will fail - at the point where you try to run the task. taskdef is different than the tasks that ship with Ant in that it will cause the build to fail immediately when the class cannot be loaded. It also means that the Driver interface (or some other interface?) would have to be frozen. Which seems a very good argument to keep the task with FOP, IMHO. You'd adapt the task to the interface as necessary and people will always have a working combination of FOP and the task. Otherwise you'd end up with documentation that says this task requires FOP 0.20.4 or later, but won't work with 1.0. The but won't work with 1.0 part is rather difficult to add after a release of the task. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
One little thing I forgot to mention. On Fri, 14 Dec 2001, Sam Ruby [EMAIL PROTECTED] wrote: [about FOP's xslt task] Finally, there is a depends attribute which can declare other files which are referenced for the uptodate check. This can be done with the uptodate task. This is the only part that is slightly messy as it requires multiple targets to be created in order to achieve the same result. If it can be done with uptodate and multiple targets, dependset will probably work - making for one dependset and one style for each xslt. Adding a way to name additional dependencies in style is a good idea, anyway IMHO. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/org/apache/fop/tools/anttasks Manifest.java
On 14 Dec 2001, [EMAIL PROTECTED] wrote: now uses built in ant manifest task (under jar) Thanks. I've added a testcase for Ant so that Ant's builds will continue to fail until we fix the problem, and you won't be bothered by GUMP mails any longer. To get the hostname, at least for Windows and Unix you can rely on environment variables, see http://marc.theaimsgroup.com/?l=ant-userm=100802855231701w=2 for a solution. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
On Fri, 14 Dec 2001, Keiron Liddle [EMAIL PROTECTED] wrote: Thanks, I have updated the build file to use the manifest under jar, works fine. Great! Looking at the hostname I think that it is better left out, it may cause computers to attempt to connect to the internet when resolving the hostname. As the original task would have done before. I guess my response to your commit message hasn't made it to fop-dev yet. As Diane pointed out, you can get the hostname from the environment (at least on Windows and Unix systems), see http://marc.theaimsgroup.com/?l=ant-userm=100802855231701w=2 for example. I don't know much about xslt apart from - it works. So you know more than me. What sort of things need to be done/added? Will it become a core task or optional? There is a built-in Ant task named style that has been built-in for a long time. It performs XSLT transformations, so it seems to be in the same area as xslt. I haven't looked at the code of FOP's task, but I assume that it must be doing something better than style does and therefore I would love to see style improved. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
On Fri, 14 Dec 2001, Sam Ruby [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: I guess my response to your commit message hasn't made it to fop-dev yet. I've manually approved two more messages. Thanks, shouldn't be necessary any longer, I've subscribed to fop-dev shortly after sending my last post. xslt has a smart attribute which can be used to disable the check to see if the output is already up to date Corresponds to style's force attribute. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
I think I know what's going on, but I don't have all pieces together to test it (yet) - does it work if you move the taskdef for FOP's manifest task out of the target and make it a sibling of target? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
On Thu, 13 Dec 2001, Sam Ruby [EMAIL PROTECTED] wrote: Did something change in Ant yesterday which made the properties file take precidence over taskdefs? No, at least not yesterday. What has changed yesterday is that we've added a new task named manifest, so there simply hasn't been any collision before that. Is there some way that the Ant and FOP teams can work together to produce a combined manifest task which satisifies all requirements? Ant's manifest task can do all things FOP's does, AFAICS. You'd have to replace the attributes with nested attribute elements and explicit names, that's all. On the other hand, this would make FOP's build process depend on an unreleased version of Ant. I'll try to see why Ant's task definition takes precedence, because it shouldn't be that way. Thanks for the heads-up. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
A quick fix, change the package target to
target name=package depends=compile,hyphenation
echo message=Creating the jar file ${build.dir}/${name}.jar/
jar jarfile=${build.dir}/${name}.jar
basedir=${build.dest}
includes=org/**,conf/**,hyph/**
manifest
attribute name=Main-Class value=${main.class} /
attribute name=Class-Path value=${runtime.classpath} /
attribute name=Implementation-Title value=${Name} /
attribute name=Implementation-Version value=${version} /
attribute name=Implementation-Vendor value=Apache Software Foundation
(http://xml.apache.org/fop/)/
/manifest
/jar
/target
this will work with Ant 1.4 and later. Still looking into the other
issues.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
I'm currently not subscribed to fop-dev and responding to a post I've
picked up from the archives, sorry, please keep ant-dev in the CC.
Keiron Liddle [EMAIL PROTECTED] wrote:
We can update the FOP build to use the core ant manifest task and a
new ant. This is no real problem.
I don't see Ant's next release before February, most probably even
later, so I'd rather recommend to use the manifest nested into jar
approach, which is going to work with Ant 1.4 and 1.4.1.
The only thing that our task does that is different is a BUILD-ID
it has Date-Time (user@host [os]).
You should be able to emulate that using property expansion, something
like
tstamp
pattern property=ts format=MMdd-HHmmss-z /
/tstamp
jar ...
manifest
attribute name=Build-Id value=${ts} (${user.name} ...) /
/manifest
/jar
you get the idea. Hostname would be the only tricky part.
How stable are these tasks and any other new tasks.
The manifest task itself is just a wrapper around the nested
manifest element of jar, which has been around for some time (and
even has JUnit testcases).
I think it is quite stable, but still hasn't been tested by that many
people. I'm not aware of any other tasks - but we should talk about
adding the things that make your xslt task the preferred choice over
style to Ant's core task so that people outside the FOP community
can benefit from it as well 8-)
Cheers
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta Projects Communicating
On Fri, 10 Aug 2001, Alex McLintock [EMAIL PROTECTED] wrote: There is no forum for Jakarta discussion. There is no mailing list for discussing all the sub projects as a whole. [EMAIL PROTECTED] Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
On Mon, 30 Jul 2001, Keiron Liddle [EMAIL PROTECTED] wrote: I've tried to work out what the problem with this is without success. The information suggests there is no xalan1 and that xalan2 is present (at least for the first bit). I think it is that JAXP 1.1 is present (and thus the TraX interface) but no Xalan2. Looking at the latest GUMP run http://jakarta.apache.org/builds/gump, the problem seems to be fixed. Hmm, yes, there is a commit by Sam to Alexandria that adds a dependency of xalan2 is needed for FOP that seems to have fixed it. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: userconfig in AIX.
On Thu, 19 Jul 2001, David Ryan [EMAIL PROTECTED] wrote: font metrics-file=gara.xml kerning=yes embed-file=gara.ttf font-triplet name=gara style=normal weight=normal /font Can you see anything wrong with this? You don't close the font-triplet element. Make that font-triplet name=gara style=normal weight=normal / Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
Karen Lease [EMAIL PROTECTED] wrote: I see there are several of these. I guess they are coming from the automatic nightly build. Yes, I think so (not sure whether Sam is reading this list and as I'm at least a little familiar with Gump, I thought I should jump in). This message comes from a system named Gump, which knows a whole bunch of projects and how they depend on each other. Every night Gump will do a CVS update for all projects and build each project with the latest code of all other projects - for the results look around at http://jakarta.apache.org/builds/gump/. The source code for Gump can be found as a proposal in Jakarta's Alexandria project. This is not only going to find problems within a single project, but also helps to track down incompatibilities with older versions that might get into your code. The situation for FOP seems to be of this type. FOP gets built against the CVS version of Xalan-J2 and this one obviously has changed in a way that FOP's current build system cannot deal with. I must admit that I don't know much about how the build process works. Does anyone know what we should do to find and fix the problem? I'm even less familiar with FOP's build and haven't looked at the stylesheets at all. Looking at the error message alone, it seems as if the problem was indeed in the stylesheet and not within Xalan (maybe Xalan has become more strict?). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
