Re: Resources Introspection
Hello Antoine, --- Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Hello Matt and others, I want to change the xslt task, so that the stylesheet can be either a regular file or a zip entry (or may be even any resource). I finally implemented a working solution of xslt task accepting its stylesheet as a resource. This brings me to point : we do not have yet a syntax to generate resources from attributes, do we ? I didn't checked if this syntax exists. Instead, I did it in the following way: xslt in=somedata.xml out=someresult.html file file=style.xml/ /xslt or xslt in=somedata.xml out=someresult.html url url=style.xml/ /xslt I implemented it by adding addConfigured(Resource) to XSLTProcess. XSLTProcess delegates the xslt transformation work to instances of XSLTLiaison. They accepted the stylesheet as a file, so I hacked them to accept to is as a resource. The attached patch contains the changes for XSTLProcess.java, XSLTLiaison.java, TRAXLiaision.java and some unit tests for these changes. Regards Ivan My dream : xslt in=somedata.xml out=someresult.html styleresource=zip:file:foo/bar/my.zip!alpha/beta/style.xml/ which would mean of course take from foo/bar/my.zip the entry alpha/beta/style.xml and use it to transform somedata.xml into someresult.html. Any ideas ? Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resources Introspection
--- Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Hello Matt and others, I want to change the xslt task, so that the stylesheet can be either a regular file or a zip entry (or may be even any resource). This brings me to point : we do not have yet a syntax to generate resources from attributes, do we ? My dream : xslt in=somedata.xml out=someresult.html styleresource=zip:file:foo/bar/my.zip!alpha/beta/style.xml/ No! It was my dream first and you can't have it! :) I agree wholeheartedly. IIRC myself, Stefan, and probably others took part in a discussion of this nature some time ago... though I'm too frustrated by my slow home internet connection to find the thread ATM. Maybe we can get some momentum behind this. I think the simplest approach would be to default to file; but let the colon-delimited prefix represent a defined type in the project, e.g. file, url... and look it up. At the time I believe I was able to convince Stefan that this belonged in IntrospectionHelper; sounds like you agree. -Matt which would mean of course take from foo/bar/my.zip the entry alpha/beta/style.xml and use it to transform somedata.xml into someresult.html. Any ideas ? Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resources Introspection
Hi,
I don't know if this is of interest, but I have made some custom tasks
and types for XSLT. (I would think these could be used to get a resource
from a jar) - for example:
- SourceType (have implemented a XmlDomType) - create a top-level DOM
(dom4j, JDOM, etc...) Document that can be used in multiple XSLT tasks.
The reason was to avoid reparsing a common XML file for multiple transforms.
- TemplatesType - create a top level Templates object that can be used
in multiple XSLT tasks. This type can also take a UriResolverType for
both the factory (resolves xsl:import/includes) and the transformer
(resolves document function calls)
- UriResolverType - can be assigned to a TemplatesType. I have
implemented a FallbackUriResolver which allows you to set a default
directory to look in first and if a file is not found, it falls back to
an alternate directory.
Additionally I have made a Lucene indexer and search type. The search
type can be assigned to a UriResolver where a can be used in the
document function (document('fieldName: matchValue')) and get search
results back as XML for use in the transform.
Of interest?
best,
-Rob
Matt Benson wrote:
--- Antoine Levy-Lambert [EMAIL PROTECTED] wrote:
Hello Matt and others,
I want to change the xslt task, so that the
stylesheet can be either a
regular file or a zip entry (or may be even any
resource).
This brings me to point : we do not have yet a
syntax to generate
resources from attributes, do we ?
My dream :
xslt in=somedata.xml out=someresult.html
styleresource=zip:file:foo/bar/my.zip!alpha/beta/style.xml/
No! It was my dream first and you can't have it! :) I
agree wholeheartedly. IIRC myself, Stefan, and
probably others took part in a discussion of this
nature some time ago... though I'm too frustrated by
my slow home internet connection to find the thread
ATM. Maybe we can get some momentum behind this. I
think the simplest approach would be to default to
file; but let the colon-delimited prefix represent a
defined type in the project, e.g. file, url... and
look it up. At the time I believe I was able to
convince Stefan that this belonged in
IntrospectionHelper; sounds like you agree.
-Matt
which would mean of course take from foo/bar/my.zip
the entry
alpha/beta/style.xml and use it to transform
somedata.xml into
someresult.html.
Any ideas ?
Regards,
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional SourceSafe (VSS) Tasks - Any Comments?
Standard Ant contains a number of VSS tasks and I'm writing a couple more for my own use (tasks relating to file / project properties, such as shared versions). My questions are: should I submit these tasks for possible inclusion in the standard Ant distribution? And if so, do you have any advice on the best way to do that? I've read the Task Design Guidelines, by the way. Anybody have a problem with splitting VSS off into an antlib so that people with VSS can easily add tasks etc? I recall that there are also a couple of bugs listed (enhancements and patches) for VSS, but without anyone willing to test them, they aren't going to be worked on. I see an antlib being useful here, but would like to know what other people think. Having looked at the Dev mail archive, I've noticed that VSS tasks can be a bit of a problem for committers, since they don't (as a rule) have access to VSS to test the tasks. Any way I can help with that? It would be good for the team if you (or anyone with VSS access) could run the current trunk version (1.7alpha) against VSS so that we know ahead of time about any problems. Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] NioFileUtils, Java6FileUtils, FileUtilsAdapter + factory, build.xml (was Re: AW: Adding a methof to StringUtils)
FileUtils to select (Martijn's approach is ridiculously insane enough to have captured my fancy ;) ), it must also take into account whether the desired classes are available, falling back to the basic impl. otherwise. I'm coming round to think that Martijn's approach would be the least disruptive to the code base - simply as the delegate approach wouldn't mean recoding all tasks to use an interface instead of an implementation. This reduces the effort a lot and would make it less likely that errors would creep in. Definitely my +1 for the delegate approach, +0 for the interfaces and factory approach (ie if for some reason we can't do the delagate approach, the interfaces should be reconsidered) Thanks Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] NioFileUtils, Java6FileUtils, FileUtilsAdapter + factory, build.xml (was Re: AW: Adding a methof to StringUtils)
Kev Jackson wrote: I'm coming round to think that Martijn's approach would be the least disruptive to the code base - simply as the delegate approach wouldn't mean recoding all tasks to use an interface instead of an implementation. This reduces the effort a lot and would make it less likely that errors would creep in. Definitely my +1 for the delegate approach, +0 for the interfaces and factory approach (ie if for some reason we can't do the delagate approach, the interfaces should be reconsidered) Sounds good. When you plugin the nio, it would be good if you test the following : - building under 1.4 or 1.5, running under 1.2 - I am also concerned about users building their own ant distribution under Java 1.2, then running it under 1.4 and 1.5, and then complaining that org.apache.tools.ant.types.jdk14 cannot be found. Similarly, I wonder what happens for a user who would 1) build ant under JDK 1.2, 2) run ant under JDK 1.4, and attempt to use the RegexpFactory, for instance through the replaceregexp/ task ?. The RegexpFactory does not check whether org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp is present, only whether java.util.regex.Matcher is present. Actually, I was wondering whether we are not already forbidding - de facto and silently - this type of use cases. Regards, Antoine Antoine Thanks Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Removal of deprecated methods since ant 1.4.x. or earlier.
Martijn Kruithof wrote:
Hello
Do you agree the methods marked as deprecated in ant 1.4.x or earlier
to be removed?
The following methods have been marked deprecated in ant 1.4.x or
earlier:
Project.addFilter(String token, String value)
Project.getFilters()
Project.resolveFile(String fileName, File rootDir)
Project.copyFile(.*)
Project.setFileLastModified(File file, long time)
ExecuteJava.setOutput(PrintStream out)
FixCRLF.setCr(AddAsisRemove attr)
Please vote:
[ ] Yes
[ ] No
I consider this a code change, requiring lazy approval and then lazy
consensus from the active committers.
Martijn
Hello Martijn,
sounds good.
[x ] Yes
[ ] No
I am sure you have noticed that :
- there is one usage of copyFile (String source, String dest) in
org.apache.tools.ant.taskdefs.optional.NetRexxC
- Project#resolveFile(String fileName, File rootDir) { has one usage in
ProjectHelperImpl.
this should not stop us.
Regards,
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33057] - VSS tasks do not handle CRLF in comments
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33057. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33057 --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 03:08 --- I think this has to do with the changes made to reduce the size of labels. In Ant 1.5, the labels could be of arbitrary length, but in Ant 1.6, a fix was made to reduce the size of the labels to 32 chars. Try with shorter labels with a newline, it should work. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39373] - scp task does not work for some sshd, which does not scp1 protocol.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39373 --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 03:29 --- (In reply to comment #5) After applying the patch and running a basic test against an F-Secure sshd I get the following error: BUILD FAILED H:\build.xml:6: com.jcraft.jsch.JSchException: invalid server's version string I am using the jsch 0.1.27 Does that sshd support ssh2 protocol? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39373] - scp task does not work for some sshd, which does not scp1 protocol.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39373 --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 05:23 --- (In reply to comment #6) (In reply to comment #5) After applying the patch and running a basic test against an F-Secure sshd I get the following error: BUILD FAILED H:\build.xml:6: com.jcraft.jsch.JSchException: invalid server's version string I am using the jsch 0.1.27 Does that sshd support ssh2 protocol? The version of F-Secure sshd we are using supports only ssh2 protocol. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39373] - scp task does not work for some sshd, which does not scp1 protocol.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39373 --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 05:43 --- (In reply to comment #7) The version of F-Secure sshd we are using supports only ssh2 protocol. It is interesting. May I ask you to show me the fist line of outputs from $ telnet address_of_sshd 22 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
