Re: issue---regardsbug 113(fixed)
Vikas, please repost with the [vfs] prefix in the subject so that people can receive your mail easily. thanks paul Le 4 juil. 07 à 13:14, Vikas Kumar a écrit : Hi I am getting this problem as per issue 113(fixed bug). Please help me to solve this problem. Thanks regards Vikas Kumar Print Exception** org.apache.commons.vfs.FileSystemException: Could not read file sftp://maan:[EMAIL PROTECTED]/transport/source/students1.txt. at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream (AbstractFileObject.java:1163) at org.apache.commons.vfs.provider.DefaultFileContent.getInputStream (DefaultFileContent.java:360) at com.adeptia.indigo.services.transport.ftp.SecuredFtp.download (SecuredFtp.java:161) at com.adeptia.indigo.services.transport.ftp.FtpSource.createInputStream( FtpSource.java:179) at com.adeptia.indigo.services.transport.support.AbstractStreamSource.ini tialize(AbstractStreamSource.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.modeler.BaseModelMBean.invoke (BaseModelMBean.java:483) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke (Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at com.adeptia.indigo.utils.RemoteMBeanProxy $LocalHandler.invokeOperation(RemoteMBeanProxy.java:441) at com.adeptia.indigo.utils.RemoteMBeanProxy$Handler.invoke (RemoteMBeanProxy.java:294) at $Proxy2.initialize(Unknown Source) at com.adeptia.indigo.jelly.ActivityTag.runSync(ActivityTag.java:313) at com.adeptia.indigo.jelly.ActivityTag.doTag(ActivityTag.java:250) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:278) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:133) at com.werken.blissed.jelly.JellyActivity.perform (JellyActivity.java:120) at com.werken.blissed.ProcessEngine.enterState(ProcessEngine.java:391) at com.werken.blissed.ProcessEngine.followTransition (ProcessEngine.java:509) at com.werken.blissed.ProcessEngine.checkTransitions (ProcessEngine.java:458) at com.werken.blissed.ProcessEngine.startProcess(ProcessEngine.java: 366) at com.werken.blissed.ProcessEngine.spawn(ProcessEngine.java:299) at com.adeptia.indigo.processflow.BlissedProcessFlow.execute (BlissedProcessFlow.java:159) at com.adeptia.indigo.transaction.IndigoTransaction.execute (IndigoTransaction.java:423) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.modeler.BaseModelMBean.invoke (BaseModelMBean.java:483) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke (Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl $PrivilegedOperation.run(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.commons.vfs.FileSystemException: Could not connect to SFTP server at sftp://maan:[EMAIL PROTECTED]/. at org.apache.commons.vfs.provider.sftp.SftpFileSystem.getChannel (SftpFileSystem.java:144) at org.apache.commons.vfs.provider.sftp.SftpFileObject.doGetInputStream (SftpFileObject.java:380) at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream (AbstractFileObject.java:1159) ... 53 more Caused by: com.jcraft.jsch.JSchException: java.io.IOException: inputstream is closed
Re: infrastructure work for TLP move
Hello Torsten, indeed... I just wanted to avoid making noise there... but in any case... I might be out of the two years window but I would wish to keep jelly committership, my ASF user-name is polx. I would also favour splitting the lists so that commits and jira mails come separately but we need to care that they are properly advertised and that it is indicated on dev and users that such mails are elsewhere. Also be sure that announces of such (mail-list splitting, committership overtake, ...) is announced as a separate mail... such long threads as this one needs more hand-pealing. thanks paul Le 1 juil. 07 à 02:32, Torsten Curdt a écrit : I think it's clear that old committers can get back access at any time. That's for sure. But could you bring this up on commons-dev? We probably should send around an announcement for that. cheers -- Torsten On 28.06.2007, at 00:31, Paul Libbrecht wrote: if I dare request, I would prefer to keep committership even though my activities haven't been greatly active in jelly. Similarly, I think, for Peter Royal. paul Le 27 juin 07 à 17:52, Torsten Curdt a écrit : I've prepared the TODO for the infrastructure work. Please cross- check and give feedback. I am not sure how we want to handle the wiki migration. cheers -- The board has agreed to create the Commons project. (Please note that there has been a previous commons TLP) To aid in the process, would the Infrastructure team please do the following: #=== [1] Root Tasks Create unix group commons. If it already exists remove previous members. Add following usernames to group commons: bayard jochen imario scolebourne dennisl niallp mvdb ozeigermann joehni oheger mbenson martinc psteitz tcurdt dfs rwinston luc pietsch dion brentworden skitching rahul Verify that domain commons.apache.org is correctly setup. #=== [1] Mailing List (i) addresses I. [EMAIL PROTECTED] * Henri Yandell[EMAIL PROTECTED] * Jochen Wiedmann [EMAIL PROTECTED] * Mario Ivankovits [EMAIL PROTECTED] * Stephen Colebourne [EMAIL PROTECTED] * Dennis Lundberg [EMAIL PROTECTED] * Niall Pemberton [EMAIL PROTECTED] * Martin van den Bemt [EMAIL PROTECTED] * Oliver Zeigermann[EMAIL PROTECTED] * Jörg Schaible[EMAIL PROTECTED] * Oliver Heger [EMAIL PROTECTED] * Matt Benson [EMAIL PROTECTED] * Martin Cooper[EMAIL PROTECTED] * Phil Steitz [EMAIL PROTECTED] * Torsten Curdt[EMAIL PROTECTED] * Daniel Savarese [EMAIL PROTECTED] * Rory Winston [EMAIL PROTECTED] * Luc Maisonobe[EMAIL PROTECTED] * Joerg Pietschmann[EMAIL PROTECTED] * Dion Gillard [EMAIL PROTECTED] * Brent Worden [EMAIL PROTECTED] * Simon Kitching [EMAIL PROTECTED] * Rahul Akolkar[EMAIL PROTECTED] II. [EMAIL PROTECTED] migrate subscribers from commons- [EMAIL PROTECTED] III. [EMAIL PROTECTED] migrate subscribers from commons- [EMAIL PROTECTED] NOTE: if possible forward [EMAIL PROTECTED] to [EMAIL PROTECTED] (ii) remote moderators ... As this is a migration of the mailing list the current moderators will take over on the different domain. (iii) archives I. http://commons.apache.org/mail/commons/user/MM.gz II. http://commons.apache.org/mail/commons/dev/MM.gz III. [EMAIL PROTECTED] to be archived in the private area. (iv) options I. Reply-To: Header [X] yes [ ] no II. Message Trailer [X] yes [ ] no #=== [2] Source Control (i) Subversion Move the existing jakarta/commons tree to TLP #=== [3] Initial Committer list bayard jochen imario scolebourne dennisl niallp mvdb ozeigermann joehni oheger mbenson martinc psteitz tcurdt dfs rwinston luc pietsch dion brentworden skitching rahul #=== [4] Wiki (i) Wiki pages need to be migrated http://wiki.apache.org/jakarta-commons/FrontPage This can be done by the community itself. #=== [5] Bug tracking (i) Project URLs need to be migrated This can be done by the community itself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (JELLY-275) j:new casts objects to java.lang.String
[
https://issues.apache.org/jira/browse/JELLY-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486524
]
Paul Libbrecht commented on JELLY-275:
--
Andre,
this really looks like a bug.
I believe that on should rather accept any object but maybe there's something
hidden somewhere that requires this one to be a string.
The following would be a workaround:
j:new var=foo className=java.io.File
j:arg value=./
/j:new
j:set var=isFile value=${foo.isFile()}/
paul
j:new casts objects to java.lang.String
---
Key: JELLY-275
URL: https://issues.apache.org/jira/browse/JELLY-275
Project: Commons Jelly
Issue Type: Bug
Components: core / taglib.core
Affects Versions: 1.1.1
Reporter: Andre Huertas
I execute the following Jelly script:
j:new var=foo className=java.io.File
j:arg value=./
/j:new
j:invoke method=isFile var=isFile on=${foo} /
and get the following Exception when I do:
java.lang.NoSuchMethodException: No such accessible method: isFile() on
object: java.lang.String.
The same happens if I use the util:file tag.
When I take a look at my log4j file I see the following debug statement:
DEBUG main org.apache.commons.beanutils.ConvertUtils - Convert string
'java.io.File' to class 'java.lang.String'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] webstartable generic jelly
is something I just managed and it is real easy, to my surprise it even works with ant. Now that there's java web start 1.5 (and JNLP 1.5), it might be useful to make: - a command-line generic jelly that starts in the current directory and runs run.jelly or another one given as parameter (note: this outputs nothing in the console, it could output to a current-dir log-file) - a file-extension association so that double-clicked jelly file (unless otherwise instructed) could be run by this application Worth comitting into the jelly tree ? paul smime.p7s Description: S/MIME Cryptographic Signature
Re: [jelly] Broken links in tag reference
Now... I'm still missing to understand how this tag-reference is produced! I have finally found source xdocs for the handwritten ones but how are the very many others produced which are empty ? At least, one should correct these to the jelly doc output for the moment, or ? thanks for enlightening me. paul Dion Gillard wrote: On 7/25/06, Paul Libbrecht [EMAIL PROTECTED] wrote: Dion Gillard wrote: The idea with the tag reference was to have a one stop place for all the documentation. I thought this was what libs/index.html does. It's generated before xdoc:transform Not very well. It lists the tag libs, but doesn't provide anything like ant's manual: http://ant.apache.org/manual/index.html , especially the tasks frameset. If we can do that with links and by improving the individual taglib documentation, I'm all for it. So the correct way for working would be to enrich libs/index.html with a link to examples... right? Anything else than unit-tests ?? If libs/index.html included an easy to navigate list of the tags within the taglib, it'd be a lot better. The problem with the current taglib documentation is that a) it's autogenerated off inadequate source markup What's that wrong ?? If the javadoc comments are inadequate, we need to make them correct, I think the jellydoc takes precedence of javadoc... or ? Lack of detail. Check out http://jakarta.apache.org/commons/jelly/tag-reference/ant_fileScanner.html and compare it to http://jakarta.apache.org/commons/jelly/libs/ant/tags.html#ant:fileScanner b) It doesn't provide examples and usage info. how would you document examples except with unit-tests ?? Snippets for the examples, and better usage info for badly documented stuff like fileScanner as an example. If we can merge this stuff into better done JellyDoc, I'd be happy with that too. paul On 7/25/06, Paul Libbrecht [EMAIL PROTECTED] wrote: It isn't easy as that, building the site does take a huge time because of the very many tag-libs depending on the maven version this may even turn out to impossible. This tag-reference page makes double usage with: http://jakarta.apache.org/commons/jelly/libs/index.html whose links are all correct... why keep it ? Rebuilding the site would probably fix it if replacing tag-reference/x.html with libs/x/tags.html but do we really need that ?? paul Dennis Lundberg wrote: That might be so, but the links on the All tags page work. So it's just a matter of fixing some links. If I go ahead and do that would it be OK to redeploy the site? Dion Gillard wrote: I don't think the tag reference is complete. On 7/25/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi The links under Tag Reference are all broken. That is all except All tags. http://jakarta.apache.org/commons/jelly/tag-reference/index.html smime.p7s Description: S/MIME Cryptographic Signature
[fileupload] [Fwd: REX and File Upload published]
I just wanted to make sure that Commons-FileUpload's project's members are aware of this ongoing specification. paul Original Message Subject:REX and File Upload published Resent-Date:Sun, 22 Oct 2006 17:03:41 + Resent-From:public-webapi@w3.org Date: Sun, 22 Oct 2006 19:03:31 +0200 From: Charles McCathieNevile [EMAIL PROTECTED] Organization: Opera Software To: Web API public public-webapi@w3.org References: [EMAIL PROTECTED] Hi folks, there is a new working draft of REX [1], and a first public working draft of file upload, for your delectation. We are hoping to take REX in this version to last call very shortly, and may then start on a version 2. So if you want to comment, please do so sooner rather than later (File Upload is not on such an aggressive schedule, but comments are also welcome of course). [1] http://www.w3.org/TR/rex [2] http://www.w3.org/TR/file-upload Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com smime.p7s Description: S/MIME Cryptographic Signature
[jelly] stream of XML fragments ?
Hello,
since a while I'm considering the implementation of a reader for
log-like file formats, that is, for files that are xml up to a header
and footer. We use these in our ActiveMath system, typically, as log
files, where each new log entry is output as a new element.
loglike:parse url=a.xml var=iterator
loglike:header![CDATA[!DOCTYPE root SYSTEM ../dtd/xx.dtd
root]]/loglike:header
loglike:footer![CDATA[/root]]/loglike:footer
/loglike:parse
j:forEach items=${iterator} var=elt
!-- do someting with ${elt} which would be a dom4j.Element probably --
/j:forEach
Would anyone else take advantage of such parsing tags ?
It has the strong advantage of being streamed (these log files are
easily enormous) and still let jelly's ease of xml manipulations and
filtering.
paul
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [VOTE] Release Commons JEXL 1.1
Just my 2p: if I remember well, there's a way checkstyle errors can produce a text-like report with filename:line-number:message which is exactly what most compilers would output to make errors clickable in, say, jEdit and Emacs to name a few... That helped me every time i was haunted by the checkstyle reports... paul Dion Gillard wrote: Rahul, I'll start looking at the checkstyle config and issues if you're happy with that? On 9/4/06, Phil Steitz [EMAIL PROTECTED] wrote: Looks good to me. +1 assuming build has been tested on 1.2, which is what the jar manifest specifies. One small nit, which you could do without another RC, IMO, or ignore: The checkstyle report is not clean. One real javadoc error is flagged, some missing javadoc, missing package javadoc for a couple of packages, and some bogus complaints. I would recommend either fixing all of the errors, modifying checkstyle.xml, or dropping the report from the doc included in the distribution. Phil On 8/31/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Ran the usual gamut of checks, looks good to me. snip/ --- [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... snap/ -Rahul - 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] smime.p7s Description: S/MIME Cryptographic Signature
Re: [jelly] Broken links in tag reference
It isn't easy as that, building the site does take a huge time because of the very many tag-libs depending on the maven version this may even turn out to impossible. This tag-reference page makes double usage with: http://jakarta.apache.org/commons/jelly/libs/index.html whose links are all correct... why keep it ? Rebuilding the site would probably fix it if replacing tag-reference/x.html with libs/x/tags.html but do we really need that ?? paul Dennis Lundberg wrote: That might be so, but the links on the All tags page work. So it's just a matter of fixing some links. If I go ahead and do that would it be OK to redeploy the site? Dion Gillard wrote: I don't think the tag reference is complete. On 7/25/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi The links under Tag Reference are all broken. That is all except All tags. http://jakarta.apache.org/commons/jelly/tag-reference/index.html smime.p7s Description: S/MIME Cryptographic Signature
Re: [jelly] Broken links in tag reference
Dion Gillard wrote: The idea with the tag reference was to have a one stop place for all the documentation. I thought this was what libs/index.html does. It's generated before xdoc:transform If we can do that with links and by improving the individual taglib documentation, I'm all for it. So the correct way for working would be to enrich libs/index.html with a link to examples... right? Anything else than unit-tests ?? The problem with the current taglib documentation is that a) it's autogenerated off inadequate source markup What's that wrong ?? If the javadoc comments are inadequate, we need to make them correct, I think the jellydoc takes precedence of javadoc... or ? b) It doesn't provide examples and usage info. how would you document examples except with unit-tests ?? paul On 7/25/06, Paul Libbrecht [EMAIL PROTECTED] wrote: It isn't easy as that, building the site does take a huge time because of the very many tag-libs depending on the maven version this may even turn out to impossible. This tag-reference page makes double usage with: http://jakarta.apache.org/commons/jelly/libs/index.html whose links are all correct... why keep it ? Rebuilding the site would probably fix it if replacing tag-reference/x.html with libs/x/tags.html but do we really need that ?? paul Dennis Lundberg wrote: That might be so, but the links on the All tags page work. So it's just a matter of fixing some links. If I go ahead and do that would it be OK to redeploy the site? Dion Gillard wrote: I don't think the tag reference is complete. On 7/25/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi The links under Tag Reference are all broken. That is all except All tags. http://jakarta.apache.org/commons/jelly/tag-reference/index.html smime.p7s Description: S/MIME Cryptographic Signature
[jelly] migrate faq to the faq plugin ?
hello jellyers, the jelly faq would love to be enriched by the many questions asked on the list(s) but it is still a manually authored xdoc. Anything against me moving it to using the maven-1.1 faq plugin ? thanks paul smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (JELLY-232) Some ant objects throw NPE at toString
Some ant objects throw NPE at toString -- Key: JELLY-232 URL: http://issues.apache.org/jira/browse/JELLY-232 Project: Commons Jelly Type: Bug Components: taglib.ant Versions: 1.1 Environment: (MacOSX 10.3.9) Reporter: Paul Libbrecht Assigned to: Paul Libbrecht When setting the debug mode, a lot of the creation of the ant tags are reported about and this invokes the toString method of the tags. This fails for some objects such as the fileset tag... a method to call toString safely is needed in, at least, AntTag! paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-228) AntTag.createDataType() throws ClassCastException
[ http://issues.apache.org/jira/browse/JELLY-228?page=all ]
Paul Libbrecht resolved JELLY-228:
--
Resolution: Fixed
Have applied the patch.
Please check and reopen if need be.
paul
AntTag.createDataType() throws ClassCastException
-
Key: JELLY-228
URL: http://issues.apache.org/jira/browse/JELLY-228
Project: Commons Jelly
Type: Bug
Components: taglib.ant
Environment: jdk1.5.0_02
Reporter: Hang Sun
Priority: Minor
Attachments: JELLY-228.patch
In my Maven 1.0.2 beta 2 env., I wrote following line:
ant:typedef
file=${agitar.eclipse.site.dir}/plugins/com.agitar.agitator_${agitar.build}/types.properties
classpath=${agitar.eclipse.site.dir}/plugins/com.agitar.agitator_${agitar.build}/ant-task/agitator-tasks.jar
loaderRef=agitarjar/
where types.properties includes 1 line:
dashboard-config=com.agitar.ant.SharedAntConfig
SharedAntConfig is a POJO and this seems to cause problem with the AntTag
class, whose createDataType() method expects the data type be subclass of
org.apache.tools.ant.types.DataType.
It seems to me that AntTag class should not make this assumption.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-232) Some ant objects throw NPE at toString
[ http://issues.apache.org/jira/browse/JELLY-232?page=all ] Paul Libbrecht closed JELLY-232: Resolution: Fixed Fixed with AntTag and AntJellyContext. paul Some ant objects throw NPE at toString -- Key: JELLY-232 URL: http://issues.apache.org/jira/browse/JELLY-232 Project: Commons Jelly Type: Bug Components: taglib.ant Versions: 1.1 Environment: (MacOSX 10.3.9) Reporter: Paul Libbrecht Assignee: Paul Libbrecht When setting the debug mode, a lot of the creation of the ant tags are reported about and this invokes the toString method of the tags. This fails for some objects such as the fileset tag... a method to call toString safely is needed in, at least, AntTag! paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release commons-jelly-tags-interaction 1.1
Maybe... I'll work on this tonight local time (in about 14 hours). The problem is that maven dist calls the maven dist of jelly which is quite wrong, I think... and I did not want to touch this yet. If it sounds appropriate and someone can check my candidate sources I could try this tonight before tagging it would only affect, probably, the maven.xml in jelly/jelly-tags. paul Dion Gillard wrote: Paul can we post the source/binary distribution release after getting the jar out? On 6/20/06, Paul Libbrecht [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Regardless of what Jelly has been doing in the past, IMO its a good idea to have source distributions for any release, given which one would be able to (atleast after meeting certain pre-requisites) effectively reproduce the release binaries. Why don't Jelly taglibs have accompanying source distros? As a general wish, I only agree. In this case both limit in time and the fact that this tag-library is exactly made of one class tend me to not do so. Note we had a similar situation in Jakarta Taglibs which AFAICT has since been remedied. Also, a gentle reminder to please tag SVN (as previous Jelly releases have done). Of course tagging was planned. Do you mean I should tag RC1 as well ? Since I've not participated in the discussion so far, and wasn't around to bring this up earlier for the last three days when the plan (below) was posted, I will vote 0. I will also encourage you to leave votes open for atleast 72 hours (instead of 36). The fact that I sent this wish already long ago, with less clarity indeed, pushes me here. And also, the fact that maven plugin release is waiting. paul Thank you for your time towards this release. -Rahul thank you in advance. paul Paul Libbrecht wrote: Here's the plan: - all issues with this tag-libs are cleared - no further changes are needed for the release... and almost no risk of concurrent change exist (hence no branch is needed). - the release shall, as with most jelly-tag-libraries, only produce jar files to be consumed from the maven repo at ibiblio and the repo at apache. No source or binary distribution will be made. - once the vote passed, I will simply update changes.xml and project.xml, tag the files, upload the jar to the Apache, submit a jar upload to iblio's repo. I have assembled the following release candidates... - a site with RC1 version tag: http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/ - a jar which is the sole outcome of this subproject: http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar smime.p7s Description: S/MIME Cryptographic Signature
Re: [vote] Release commons-jelly-tags-interaction 1.1
The vote result is as follows: +1 Paul +0 Rahul +1 Dion +1 Stephen Result: +1 I tried to follow the procedure in order to see the impact of a binary and source releases and have to say that I feat it'll move lots of stuffs around. In particular, how would the mirrorred download look like with several flavours of dists (both binary and sources) ? I have given it up for now. I find it ok to have a single binary and source distribution of the whole jelly project (yes, I know, it should be released more often!). We may consider the maven sources plugin at some point... I am now setting things up for a proper signing and hashing then will achieve the jar-oriented tasks of the release guide. And send an announcement here and on commons-users. paul Paul Libbrecht wrote: I hereby request to vote about the release of the jelly subproject interaction tag library. The details of the release plan are below. I would like to please request a vote for 36 hours, ie. till Wednesday 14:00 GMT. +1 [ ] yes, let's do it 0 [ ] let it happen... but I can't really check -1 [ ] don't do it because... thank you in advance. paul Paul Libbrecht wrote: Here's the plan: - all issues with this tag-libs are cleared - no further changes are needed for the release... and almost no risk of concurrent change exist (hence no branch is needed). - the release shall, as with most jelly-tag-libraries, only produce jar files to be consumed from the maven repo at ibiblio and the repo at apache. No source or binary distribution will be made. - once the vote passed, I will simply update changes.xml and project.xml, tag the files, upload the jar to the Apache, submit a jar upload to iblio's repo. I have assembled the following release candidates... - a site with RC1 version tag: http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/ - a jar which is the sole outcome of this subproject: http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r416153 - /jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/
Dion Gillard wrote: Don't we have tags at the taglib level for Jelly? Nope... but that's quite ok or ? That seems a whole lot of stuff for a single taglib. What do you mean ? svn cp is the only way to tag so I cp the whole project. It only consumes my (temp) directory space, not even the server which stores as deltas anyways. paul On 6/22/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: polx Date: Wed Jun 21 15:59:04 2006 New Revision: 416153 URL: http://svn.apache.org/viewvc?rev=416153view=rev Log: Tag for the release 1.1 of Jelly-Tags-Interaction. paul Added: jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/ - copied from r416152, jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r416153 - /jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/
thanks, fixed! paul Lukas Theussl wrote: Another remark: is the SNAPSHOT dependency on commons-jexl necessary? -Lukas Paul Libbrecht wrote: Dion Gillard wrote: Don't we have tags at the taglib level for Jelly? Nope... but that's quite ok or ? That seems a whole lot of stuff for a single taglib. What do you mean ? svn cp is the only way to tag so I cp the whole project. It only consumes my (temp) directory space, not even the server which stores as deltas anyways. paul On 6/22/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: polx Date: Wed Jun 21 15:59:04 2006 New Revision: 416153 URL: http://svn.apache.org/viewvc?rev=416153view=rev Log: Tag for the release 1.1 of Jelly-Tags-Interaction. paul Added: jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/ - copied from r416152, jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/ smime.p7s Description: S/MIME Cryptographic Signature
[ANNOUNCE] release of commons-jelly-tags-interaction version 1.1
The jakarta commons jelly developers are happy to announce the release 1.1 of the interaction tag-library. This tag-library allows jelly scripts to interact with the user through the console. The version 1.1 comes with the usage of the jline library which provides a comfortable command-line interface with auto-completion and history. Get the jar from a maven repository near you or from: http://www.apache.org/dist/java-repository/commons-jelly/jars/ Get the source from the subversion repository: http://svn.apache.org/repos/asf/jakarta/commons/proper/jelly/tags/COMMONS-JELLY-INTERACTION-1_1/ Enjoy! paul libbrecht smime.p7s Description: S/MIME Cryptographic Signature
[vote] Release commons-jelly-tags-interaction 1.1
I hereby request to vote about the release of the jelly subproject interaction tag library. The details of the release plan are below. I would like to please request a vote for 36 hours, ie. till Wednesday 14:00 GMT. +1 [ ] yes, let's do it 0 [ ] let it happen... but I can't really check -1 [ ] don't do it because... thank you in advance. paul Paul Libbrecht wrote: Here's the plan: - all issues with this tag-libs are cleared - no further changes are needed for the release... and almost no risk of concurrent change exist (hence no branch is needed). - the release shall, as with most jelly-tag-libraries, only produce jar files to be consumed from the maven repo at ibiblio and the repo at apache. No source or binary distribution will be made. - once the vote passed, I will simply update changes.xml and project.xml, tag the files, upload the jar to the Apache, submit a jar upload to iblio's repo. I have assembled the following release candidates... - a site with RC1 version tag: http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/ - a jar which is the sole outcome of this subproject: http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar smime.p7s Description: S/MIME Cryptographic Signature
Re: [vote] Release commons-jelly-tags-interaction 1.1
Rahul Akolkar wrote: Regardless of what Jelly has been doing in the past, IMO its a good idea to have source distributions for any release, given which one would be able to (atleast after meeting certain pre-requisites) effectively reproduce the release binaries. Why don't Jelly taglibs have accompanying source distros? As a general wish, I only agree. In this case both limit in time and the fact that this tag-library is exactly made of one class tend me to not do so. Note we had a similar situation in Jakarta Taglibs which AFAICT has since been remedied. Also, a gentle reminder to please tag SVN (as previous Jelly releases have done). Of course tagging was planned. Do you mean I should tag RC1 as well ? Since I've not participated in the discussion so far, and wasn't around to bring this up earlier for the last three days when the plan (below) was posted, I will vote 0. I will also encourage you to leave votes open for atleast 72 hours (instead of 36). The fact that I sent this wish already long ago, with less clarity indeed, pushes me here. And also, the fact that maven plugin release is waiting. paul Thank you for your time towards this release. -Rahul thank you in advance. paul Paul Libbrecht wrote: Here's the plan: - all issues with this tag-libs are cleared - no further changes are needed for the release... and almost no risk of concurrent change exist (hence no branch is needed). - the release shall, as with most jelly-tag-libraries, only produce jar files to be consumed from the maven repo at ibiblio and the repo at apache. No source or binary distribution will be made. - once the vote passed, I will simply update changes.xml and project.xml, tag the files, upload the jar to the Apache, submit a jar upload to iblio's repo. I have assembled the following release candidates... - a site with RC1 version tag: http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/ - a jar which is the sole outcome of this subproject: http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar smime.p7s Description: S/MIME Cryptographic Signature
Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1
Dion Gillard wrote: I have assembled the following release candidates... - a site with RC1 version tag: http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/ - a jar which is the sole outcome of this subproject: http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar I think we need to include a NOTICE file into the jar, right? The license by itself isn't enough, from memory. Thanks to remind this. Indeed, this is needed according to: http://www.apache.org/dev/apply-license.html and is now fixed int he linked jar above. Without more comments, I'll request a vote tomorrow morning. paul smime.p7s Description: S/MIME Cryptographic Signature
Re: [all] jar signing with jarsigner
This thread is somewhat old but I have a new information... I have just been pointed to the following FAQ by a friend: http://www.dallaway.com/acad/webstart/ Several good things in there... but one that is particularly worth it is about the usage of *different certificates* for different jars. The bit is called A note on third party JAR files and indicates that it is possible to use different certificates for different jars as long as you use the extension mechanism. This means that signed Apache jars could make sense, even copied in another location. It would be distributed with an extension JNLP aside. Only issue: the user may have to say agree on several certificates! How safe would it be to consider creating a certificate and store it centrally on people.apache.org ? And request only, say, PMC members, to actually have the password of the keystore and sign the jars? thanks paul Sandy McArthur wrote: On 3/3/06, Paul Libbrecht [EMAIL PROTECTED] wrote: As far as I could see such a thing... jar signing would need to happen on Apache server... using some Apache private key... right ? Maybe this is a first issue ? How would you go to ensure that such a private key is not hacked or copied ? Let infrastructure team do the signing ? There is the problem of getting the cert (or root cert) into the JVM's keystore. Unless Apache was able to persuade a well known SSL cert issuer to donate code signing certs (which tend to be more expensive than common ssl certs), Apache would probably just have to create it's own root cert which would be used to issue certs to Apache members needing to sign releases. Then, as I see it, trusting these issued certs would be no different than trusting the PGP keys release managers are expected to keep protected. For end users the root Apache cert would need to be added to the JVM's keystore to be able to verify signed jars. I suppose that, with Java Web Start, the jar-signing mechanism may request at least one authorization for each signing key... I don't know how that would work. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1
robert burrell donkin wrote: On Tue, 2006-05-09 at 23:07 +0200, Paul Libbrecht wrote: The story seems quite simple so I thought I'd just ask for a vote sorry if too stressed. The interaction jelly tag-library is now ready for release 1.1. It has been recently boosted with a finer control on auto-completion, and maven console plugin is using it successfully. Thanks to give it a try* and provide a vote. is this a vote on the idea of releasing (in other words, a release plan) or on actually cutting a release? if it's an actual release vote then i'd like to be able to check a release candidate before casting a vote... I'm trying to return to this... but am getting drowned in time. I would like to request votes to release jelly-tags-interaction. I have followed Preparations to release and can judge the following steps: - I'm nominated as release manager for this (because of last votes at least) - I am proposing a release plan (below) Here's the plan: - all issues with this tag-libs are cleared - no further changes are needed for the release... and almost no risk of concurrent change exist (hence no branch is needed). - the release shall, as with most jelly-tag-libraries, only produce jar files to be consumed from the maven repo at ibiblio and the repo at apache. No source or binary distribution will be made. - once the vote passed, I will simply update changes.xml and project.xml, tag the files, upload the jar to the Apache, submit a jar upload to iblio's repo. I have assembled the following release candidates... - a site with RC1 version tag: http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/ - a jar which is the sole outcome of this subproject: http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar Please tell me if that's enough to request a vote. thanks paul smime.p7s Description: S/MIME Cryptographic Signature
[jira] Commented: (JELLY-230) Problem with default namespace in imported scripts
[
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12416139 ]
Paul Libbrecht commented on JELLY-230:
--
Lukas... replacenamespace is working fine for me.
The following:
?xml version=1.0 encoding=UTF-8?
j:jelly xmlns:j=jelly:core
xmlns:x=jelly:xmlx:replaceNamespace xmlns:x=jelly:xml toURI=
fromURI=dummy
project xmlns=dummy default=jar basedir=. name=test-maven-ant-plugin
glup/
/project
/x:replaceNamespace/j:jelly
creates me:
project default=jar name=test-maven-ant-plugin
basedir=.glup/glup/project
as I expect.
If you get this re-output verbatim, your xml taglib version is wrong... the
replaceNamespace tag is missing.
Tell us if it helps... I am a bit reluctant to insert back the implicit
replaceNamespace as it is a normal purist approach to consider it a bug (and
there's no way to get rid of it).
Would it be too many changes on the maven side ??
paul
Problem with default namespace in imported scripts
--
Key: JELLY-230
URL: http://issues.apache.org/jira/browse/JELLY-230
Project: Commons Jelly
Type: Bug
Components: core / taglib.core
Versions: 1.1
Environment: jelly-1.1-SNAPSHOT
Reporter: Lukas Theussl
Assignee: james strachan
Priority: Critical
I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it
contains a fix for a regression that has blocked us for a long time, see
http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn
archives earlier!).
However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads
to a whole bunch of test failures in several of our plugins.
After some investigation I found that they all turn out to be due to the same
cause, an apparent backwards incompatibility introduced in the fix for
JELLY-213.
I am not sure actually if this is a bug or the intended behavior, but it
certainly breaks backwards compatibility.
To illustrate the problem: in the ant plugin we use the following snippet to
generate an ant build.xml file from a template:
j:file name=build.xml prettyPrint=true
j:import file=templates/build.jelly inherit=true/
/j:file
where the template file build.jelly looks like this (simplified):
j:jelly
xmlns:ant=jelly:ant
xmlns:j=jelly:core
xmlns=dummy
project name=${pom.artifactId} default=jar basedir=.
target name=clean description=Clean up
delete dir=$${defaulttargetdir}/
delete dir=$${distdir}/
/target
/project
/j:jelly
Note the xmlns=dummy namespace declaration which is necessary to
distinguish the default namespace of the template script from Maven's default
namespace. Now with jelly-1.0, this works as expected, but with the current
jelly-1.1-SNAPSHOT, I get:
project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
target description=Clean up name=clean
delete dir=${defaulttargetdir}
/delete
delete dir=${distdir}
/delete
/target
project
ie the dummy namespace declaration makes it into the top-level element of the
generated file. This makes ant very unhappy when invoked on this build file...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-226) Upgrade dom4j and jaxen
[ http://issues.apache.org/jira/browse/JELLY-226?page=comments#action_12415443 ] Paul Libbrecht commented on JELLY-226: -- Is now committed... looks like i need to wait to see gump take it up. Upgrade dom4j and jaxen --- Key: JELLY-226 URL: http://issues.apache.org/jira/browse/JELLY-226 Project: Commons Jelly Type: Wish Components: core / taglib.core, taglib.jsl, taglib.xml Reporter: Lukas Theussl I am struggling with upgrading dom4j and jaxen for our upcoming maven-1.1 release (see http://jira.codehaus.org/browse/MAVEN-1345 and http://jira.codehaus.org/browse/JAXEN-67 for some chunks of discussion). Part of the problem seems to be some kind of binary incompatibility in project dependencies of jelly. I tried to rebuild jelly with the latest dom4j-1.6.1 and jaxen-1.1-beta-8 but failed due to several broken test cases, in particular in the jsl tag library. It would be nice if we had a jelly release with unified dependencies, even though I am not sure it will solve our problem of dropped CDATA sections that I described in JAXEN-67. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-231) x:foreach's sort option breaks if empty result
x:foreach's sort option breaks if empty result -- Key: JELLY-231 URL: http://issues.apache.org/jira/browse/JELLY-231 Project: Commons Jelly Type: Bug Components: taglib.xml Versions: 1.1 Reporter: Paul Libbrecht as it says... if you invoke x:foreach with a sort attribute. An ArrayIndexOutOfBounds is thrown is the result-set is empty. This should not be. paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed
Gump experts, Failures in these three tests are due, I think, to old jaxen, indeed jaxen 1.1-beta-4 is referenced in many places in http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html and the other failing gump reports. Explanation for this is the gump metadata to be found at: http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-commons-jelly.xml which indeed states explicitly jaxen 1.1-beta-8. Is this gump descriptor automatically generated ? Using a manually triggered process or every nights ? (it appears the first must be true since jaxen 1.1-beta-8 is in the project.xml since yesterday). I've tried: maven generate-gump -Dmaven.gump.svn.dir=commons/proper/jelly/trunk should I upload the result somewhere ? thanks paul development wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-html has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-html-07062006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-0706200 6.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at
Re: vmbuild.apache.org now available
Would that run visual unit tests ?? paul Brett Porter wrote: Hi, Berin has setup a VMWare machine for general build stuff. I have setup httpd, java, continuum and maven 2 on there. Who was interested on working on nightly builds/CI for commons-*? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1
Well, Lukas who requested this indicated that anyways he wanted some other releases (including the core). There was one request to get a packed version to chew at before voting... which I did not have the time to do. Votes were, otherwise, positive. So, it's not done yet and I'll need till middle of next week at least for this. How does it sound ? paul PS: I would prefer, if possible, to update the dom4j dependency (see other question). Arnaud HERITIER wrote: Hi guys, Will you release it ? Arnaud On 5/17/06, peter royal [EMAIL PROTECTED] wrote: The story seems quite simple so I thought I'd just ask for a vote sorry if too stressed. The interaction jelly tag-library is now ready for release 1.1. It has been recently boosted with a finer control on auto-completion, and maven console plugin is using it successfully. Thanks to give it a try* and provide a vote. This vote will last till Friday 12:00 GMT. [ ] +1 yes let's release it [X] +0 maybe [ ] -0 seems not ready [ ] -1 no, don't! I support the release, but don't have time to actually test it. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Upgrade to dom4j 1.6.1 ?
I please beg another round of review... or I'll interprete the silence as no bother and will do... paul Hans Gilde wrote: +0 If the unit tests pass, I'm inclined to say that the latest version should be used. But I have not tried it. -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Saturday, May 13, 2006 5:06 PM To: Jakarta Commons Developers List Subject: [jelly] Upgrade to dom4j 1.6.1 ? Hello Jellyers, After my two test fixes, which had almost nothing to do with dom4j... I seem to be happily running everything with dom4j 1.6.1. Can anyone confirm me this ? It's quite radical but it'd help in many other places. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DONE] Re: Bugzilla-Jira migration
Henri Yandell wrote: Migration is complete; Commons has successfully invaded issues.apache.org/jira. Next up - reflect the change on the website. Just for your information, it is possible to have readable URLs to Jira even though Jira itself doesn't give them. Among others, a project page is: http://issues.apache.org/jira/browse/projectKey (e.g. http://issues.apache.org/jira/browse/JELLY or http://issues.apache.org/jira/browse/IO) Better use this than the number based things. Probably there's more such URLs which I think are important if they exchanged and presented. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Jira projects
Sorry Henry, I suppose this was later than your deletion which I didn't notice... Note that Jelly doesn't use Bugzilla since ages so the only advantage of such an import would be to merge these lost contributions, several of which are actually duplicated, all of which are resolved. The best thing would be to keep it for archive purposes in Bugzilla, I think. paul Paul Libbrecht wrote: Henri Yandell wrote: There are now two projects in Jira, Jelly and Commons JellyImported. If someone has a moment, it'd be a real help if they could take a look at the two of these and let me know if JellyImported can be deleted or if it should have its issues moved into Jelly. I just didn't find JellyImported. It's not findable in: http://issues.apache.org/jira/secure/BrowseProject.jspa and both: http://issues.apache.org/jira/browse/JELLYIMPORTED http://issues.apache.org/jira/browse/JellyImported are not found... can you maybe give a URL ? I'll be renaming Jelly to Commons Jelly in a bit. Project names in Jira are in capital... so renaming to COMMONS-JELLY or so would be pretty ugly... and would break all current URLs... but if you have to... Also jakarta only appears once in the project list... why? paul - 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]
[jira] Commented: (JELLY-230) Problem with default namespace in imported scripts
[
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12402290 ]
Paul Libbrecht commented on JELLY-230:
--
I fear that the problem is considered to be backwards compatibility even
though a normal perspective would be call to it a bug-fix.
Lukas, does the solution replaceNamespace sound doable for you ?
Alternatively, what about having a flag at XMLOutput (which is probably
instantiated by Maven anyways) to do this?
(it seems pretty equivalent, actually)
As far as I know this has nothing to do with import... or I'd need an extra
explanation
paul
Problem with default namespace in imported scripts
--
Key: JELLY-230
URL: http://issues.apache.org/jira/browse/JELLY-230
Project: Jelly
Type: Bug
Components: core / taglib.core
Versions: 1.1
Environment: jelly-1.1-SNAPSHOT
Reporter: Lukas Theussl
Assignee: james strachan
Priority: Critical
I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it
contains a fix for a regression that has blocked us for a long time, see
http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn
archives earlier!).
However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads
to a whole bunch of test failures in several of our plugins.
After some investigation I found that they all turn out to be due to the same
cause, an apparent backwards incompatibility introduced in the fix for
JELLY-213.
I am not sure actually if this is a bug or the intended behavior, but it
certainly breaks backwards compatibility.
To illustrate the problem: in the ant plugin we use the following snippet to
generate an ant build.xml file from a template:
j:file name=build.xml prettyPrint=true
j:import file=templates/build.jelly inherit=true/
/j:file
where the template file build.jelly looks like this (simplified):
j:jelly
xmlns:ant=jelly:ant
xmlns:j=jelly:core
xmlns=dummy
project name=${pom.artifactId} default=jar basedir=.
target name=clean description=Clean up
delete dir=$${defaulttargetdir}/
delete dir=$${distdir}/
/target
/project
/j:jelly
Note the xmlns=dummy namespace declaration which is necessary to
distinguish the default namespace of the template script from Maven's default
namespace. Now with jelly-1.0, this works as expected, but with the current
jelly-1.1-SNAPSHOT, I get:
project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
target description=Clean up name=clean
delete dir=${defaulttargetdir}
/delete
delete dir=${distdir}
/delete
/target
project
ie the dummy namespace declaration makes it into the top-level element of the
generated file. This makes ant very unhappy when invoked on this build file...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r406083 - /jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly
It's a nice question, I don't think it really is and it may be we need a
layer between Jaxen expressions in jelly and other objects in the context.
Jexl's new version now does more integer types (right?) which happened
to break a jexl comparison which could not happen against an integer.
Adding the toString() was the trick...
Maybe we should have jaxen convert more to strings now... or we just let
people be surprised and add the toString() (as need be,
integer.toString() is known to be locale dependent so it's a good thing
for it not to be automatic).
paul
Dion Gillard wrote:
Paul,
if this really is a problem with Jexl, let me know what the issue is and
we'll try to get it fixed.
On 5/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: polx
Date: Sat May 13 05:19:38 2006
New Revision: 406083
URL: http://svn.apache.org/viewcvs?rev=406083view=rev
Log:
Fixed the evil error which had nothing to do with jaxen
but with jexl... the i variable was an integer which
jaxen cannot compare to an attribute value... fixed
by using i = i.toString().
paul
Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly
Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly?rev=406083r1=406082r2=406083view=diff
==
---
jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly
(original)
+++
jakarta/commons/proper/jelly/trunk/jelly-tags/jsl/src/test/org/apache/commons/jelly/jsl/suite.jelly
Sat May 13 05:19:38 2006
@@ -129,7 +129,8 @@
test:assert xpath=[EMAIL PROTECTED] = '1']/
-test:assert xpath=@id = $i/
+
j:set var=i value=${i.toString()}/
+
test:assert xpath=@id = $i/
jsl:applyTemplates/
/jsl:template
-
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: [jelly] Jira projects
Henri Yandell wrote: There are now two projects in Jira, Jelly and Commons JellyImported. If someone has a moment, it'd be a real help if they could take a look at the two of these and let me know if JellyImported can be deleted or if it should have its issues moved into Jelly. I just didn't find JellyImported. It's not findable in: http://issues.apache.org/jira/secure/BrowseProject.jspa and both: http://issues.apache.org/jira/browse/JELLYIMPORTED http://issues.apache.org/jira/browse/JellyImported are not found... can you maybe give a URL ? I'll be renaming Jelly to Commons Jelly in a bit. Project names in Jira are in capital... so renaming to COMMONS-JELLY or so would be pretty ugly... and would break all current URLs... but if you have to... Also jakarta only appears once in the project list... why? paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-230) Problem with default namespace in imported scripts
[
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12402265 ]
Paul Libbrecht commented on JELLY-230:
--
Gee!! I certainly hope that Jelly acts like this as this is normal XML!
What I realize is that this dummy namespace has had a special treatment for
maven or within maven and that special treatment means... be renamed to the
no-namespace, correct ?
I cannot see this without an environment observation of seeing maven around
in order to decide that such a renaming should happen... or do you ?
paul
Problem with default namespace in imported scripts
--
Key: JELLY-230
URL: http://issues.apache.org/jira/browse/JELLY-230
Project: Jelly
Type: Bug
Components: core / taglib.core
Versions: 1.1
Environment: jelly-1.1-SNAPSHOT
Reporter: Lukas Theussl
Assignee: james strachan
Priority: Critical
I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it
contains a fix for a regression that has blocked us for a long time, see
http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn
archives earlier!).
However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads
to a whole bunch of test failures in several of our plugins.
After some investigation I found that they all turn out to be due to the same
cause, an apparent backwards incompatibility introduced in the fix for
JELLY-213.
I am not sure actually if this is a bug or the intended behavior, but it
certainly breaks backwards compatibility.
To illustrate the problem: in the ant plugin we use the following snippet to
generate an ant build.xml file from a template:
j:file name=build.xml prettyPrint=true
j:import file=templates/build.jelly inherit=true/
/j:file
where the template file build.jelly looks like this (simplified):
j:jelly
xmlns:ant=jelly:ant
xmlns:j=jelly:core
xmlns=dummy
project name=${pom.artifactId} default=jar basedir=.
target name=clean description=Clean up
delete dir=$${defaulttargetdir}/
delete dir=$${distdir}/
/target
/project
/j:jelly
Note the xmlns=dummy namespace declaration which is necessary to
distinguish the default namespace of the template script from Maven's default
namespace. Now with jelly-1.0, this works as expected, but with the current
jelly-1.1-SNAPSHOT, I get:
project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
target description=Clean up name=clean
delete dir=${defaulttargetdir}
/delete
delete dir=${distdir}
/delete
/target
project
ie the dummy namespace declaration makes it into the top-level element of the
generated file. This makes ant very unhappy when invoked on this build file...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] Upgrade to dom4j 1.6.1 ?
Hello Jellyers, After my two test fixes, which had almost nothing to do with dom4j... I seem to be happily running everything with dom4j 1.6.1. Can anyone confirm me this ? It's quite radical but it'd help in many other places. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-187) Wrong composite expression evaluation
[
http://issues.apache.org/jira/browse/JELLY-187?page=comments#action_12383406 ]
Paul Libbrecht commented on JELLY-187:
--
I have an issue with this patch... Namely the undocumented following usage:
$${a.b.c} does output ${a.b.c}
at least I use this to generate ant files and I just saw this is used by the
ant maven plugin, so presumably by others as well.
I''ve added such a test in TestExpressions.
Any better solution here ?
paul
Wrong composite expression evaluation
-
Key: JELLY-187
URL: http://issues.apache.org/jira/browse/JELLY-187
Project: Jelly
Type: Bug
Components: core / taglib.core
Versions: 1.0-RC1, 1.0, 1.0-RC2
Reporter: dion gillard
Fix For: 1.0.1
Attachments: JELLY-187.patch
I have tried to add the following test consdtion in method testExpresssions()
from org.apache.commons.jelly.expression.TestExpressions.java:
assertExpression($type${topping}, $typecheese);
but it fails saying that it should be:
assertExpression($type${topping}, typecheese);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-218) Output is lost when using text attribute of core:parse tag
[ http://issues.apache.org/jira/browse/JELLY-218?page=all ] Paul Libbrecht resolved JELLY-218: -- Fix Version: 1.1 Resolution: Fixed Assign To: Paul Libbrecht Fixed in subversion, please test. If you have some time for a contribution, please submit a unit-test with this, at least, as test-case. thanks paul Output is lost when using text attribute of core:parse tag -- Key: JELLY-218 URL: http://issues.apache.org/jira/browse/JELLY-218 Project: Jelly Type: Bug Components: core / taglib.core Versions: 1.0-beta-4, 1.1-beta-1, 1.0-beta-5 Environment: Windows XP, JDK1.5, Ant 1.6.5 Reporter: Tony Robertson Assignee: Paul Libbrecht Fix For: 1.1 When using the text attribute of the core:parse tag, the text is parsed but then the result is lost. If a var attribute is also used, it gets a null value. Otherwise a null pointer exception is thrown when the doTag method trys to invoke the script. (note, the equivalent problem when using the tag body as the XML source was fixed by polx at revision 135985, but not using the text attribute). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] Trying to understand TestJSL.testExample1
Hi, in the efforts of upgrading to dom4j-1.6, I've bumped into the following weird behaviour which may be my too small knowledge of JSL: TestJSL.testExample1 tests the output of the jelly file: src/test/org/apache/commons/jelly/jsl/example.jelly and then tries to assert that the first resulting small element should start with James Elson which is only contained in an attribute in the source document whereas small elements, in this jsl stylesheet are output with the template: jsl:template match=* smalljsl:applyTemplates//small /jsl:template i.e. only matching elements, not any node... Can someone tell me whether this test is reasonable ? The test is running with dom4j 1.5.2 (that tastes like a bug!) This assert is the only breakage I have in jsl with dom4j 1.6.1. thanks for hints paul PS: I managed already with dom4j-1.5.2... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] taglibs lead distribution ?
Hans, I think the idea of a lead is to put a name on components in jira. It's not about doing a release soon or anything such. Having a (living person) name on components makes it a bit easier to distribute responsibility. Currently, there are many unassigned issues, or issues assigned to James, which is the same, it would be easier that a single person, per component, living on the list, would feel concerned by received such a bug and indicate when, whether he/she could fix it, or whether it should be delegated. paul Hans Gilde wrote: I can do bug fixes and such and I'm definitely in favor of cleaning up the Jira assignments. If you'd like to assign me some stuff, I'll fix it. But I'm not in a position to really lead anything at the moment. -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 10, 2006 4:17 AM To: Jakarta Commons Developers List Subject: [jelly] taglibs lead distribution ? Hi, I was fiddling with Jira jelly project administration because interaction didn't have a component and realized that some components have been assigned to dion... which is good. I'd like it if we could distribute the lead of all components, also so that James Strachan is not anymore the default assignee!! I'd be willing to take over xml and swing tag-libs... maybe some others. Would anyone wish those ? Would anyone be ready to take over others ? Some taglibs are not in urgent need but some really have a need and this way we could react better to requests which keep coming as jelly, even though it tastes unfinished, still has a good attraction, I feel. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-226) Upgrade dom4j and jaxen
[ http://issues.apache.org/jira/browse/JELLY-226?page=comments#action_12379153 ] Paul Libbrecht commented on JELLY-226: -- Well... I have now made a few tests and, up to two lines of fixes in jelly-tags-jsl, I seem to be running fine all tag-libs with dom4j-1.6.1... I would be ready to consider upgrade to dom4j 1.6.1. paul Upgrade dom4j and jaxen --- Key: JELLY-226 URL: http://issues.apache.org/jira/browse/JELLY-226 Project: Jelly Type: Wish Components: core / taglib.core, taglib.jsl, taglib.xml Reporter: Lukas Theussl I am struggling with upgrading dom4j and jaxen for our upcoming maven-1.1 release (see http://jira.codehaus.org/browse/MAVEN-1345 and http://jira.codehaus.org/browse/JAXEN-67 for some chunks of discussion). Part of the problem seems to be some kind of binary incompatibility in project dependencies of jelly. I tried to rebuild jelly with the latest dom4j-1.6.1 and jaxen-1.1-beta-8 but failed due to several broken test cases, in particular in the jsl tag library. It would be nice if we had a jelly release with unified dependencies, even though I am not sure it will solve our problem of dropped CDATA sections that I described in JAXEN-67. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-175) patch for jelly-tags-interaction
[ http://issues.apache.org/jira/browse/JELLY-175?page=all ] Paul Libbrecht updated JELLY-175: - Component: taglib.interaction Fix Version: 1.1 Version: 1.0 Assign To: Paul Libbrecht Fixed versions component. patch for jelly-tags-interaction Key: JELLY-175 URL: http://issues.apache.org/jira/browse/JELLY-175 Project: Jelly Type: Improvement Components: taglib.interaction Versions: 1.0 Environment: I've tested this in windows with and without cygwin. Reporter: Ryan Christanson Assignee: Paul Libbrecht Priority: Minor Fix For: 1.1 Attachments: interaction.patch, patch.txt I've attached a patch to the commons-jelly-tags-interaction jar. This patch makes it so the interaction task will try to use jline: http://jline.sourceforge.net/ Jline makes it so a java console will have tab completion, and history, and other goodies. This is great, because the maven-console plugin uses the commons-jelly-tags-interaction jar. So if you update the commons-jelly-tags-interaction jar, and then tell the maven console plugin to use the new jar, then your maven console will have history, and tab completion. I've set it up to remember all of the commands typed in any console, further it uses that history as the tab completion source - so you can tab complete past commands. I've tested this in windows and it works great, but in windows with cygwin, it doesn't do the fancy completion, but still works. By the way, in windows, jline's lib doesn't support arrows for history, so use CONTROL+P and CONTROL+N. Its possible that there might be a better way to integrate jline into this lib, i've just done what looked like the quickest way to get it working so my maven console would have history and tab completion. Maybe this feature could be enabled with a tag attribute? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-229) Add list of possible completions to jelly-tags-interaction
[ http://issues.apache.org/jira/browse/JELLY-229?page=all ]
Paul Libbrecht updated JELLY-229:
-
Component: taglib.interaction
Fix Version: 1.1
(was: 1.1-beta-1)
Version: 1.0
Fixed components and versions.
Add list of possible completions to jelly-tags-interaction
--
Key: JELLY-229
URL: http://issues.apache.org/jira/browse/JELLY-229
Project: Jelly
Type: New Feature
Components: taglib.interaction
Versions: 1.0
Environment: Linux FC3, jdk-14.2_10, Maven-1.1-beta-3-SNAPSHOT
Reporter: Lukas Theussl
Assignee: Paul Libbrecht
Fix For: 1.1
Attachments: JELLY-229.patch
This is a follow-up of JELLY-175. I added a method setCompletor(list)
allowing to set a list of strings that is used by jline for tab completion.
Use it like: i:ask completor=${list} answer=a/. The list of
tab-completion strings is added to the history list, ie new goals typed in
console mode will always be tab-completed afterwards.
Please note that I have bumped the jline dependency to the latest 0.9.5. This
is not on ibiblio yet, I have created an upload request (
http://jira.codehaus.org/browse/MAVENUPLOAD-883 ), if it is not found, you
will have to put the jline-0.9.5.jar into your local repo by hand.
To test it: I have deployed a snapshot of the maven 1 console plugin:
maven plugin:download
-Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
-DgroupId=maven -DartifactId=maven-console-plugin -Dversion=1.2-SNAPSHOT
The default value for the completor list is
clean,java:compile,jar,test,xdoc,site,quit,help, but you can define your
own custom list using the maven.console.completor.goals property.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-175) patch for jelly-tags-interaction
[ http://issues.apache.org/jira/browse/JELLY-175?page=all ] Paul Libbrecht resolved JELLY-175: -- Resolution: Fixed This in the current version about to be released (I think). paul patch for jelly-tags-interaction Key: JELLY-175 URL: http://issues.apache.org/jira/browse/JELLY-175 Project: Jelly Type: Improvement Components: taglib.interaction Versions: 1.0 Environment: I've tested this in windows with and without cygwin. Reporter: Ryan Christanson Assignee: Paul Libbrecht Priority: Minor Fix For: 1.1 Attachments: interaction.patch, patch.txt I've attached a patch to the commons-jelly-tags-interaction jar. This patch makes it so the interaction task will try to use jline: http://jline.sourceforge.net/ Jline makes it so a java console will have tab completion, and history, and other goodies. This is great, because the maven-console plugin uses the commons-jelly-tags-interaction jar. So if you update the commons-jelly-tags-interaction jar, and then tell the maven console plugin to use the new jar, then your maven console will have history, and tab completion. I've set it up to remember all of the commands typed in any console, further it uses that history as the tab completion source - so you can tab complete past commands. I've tested this in windows and it works great, but in windows with cygwin, it doesn't do the fancy completion, but still works. By the way, in windows, jline's lib doesn't support arrows for history, so use CONTROL+P and CONTROL+N. Its possible that there might be a better way to integrate jline into this lib, i've just done what looked like the quickest way to get it working so my maven console would have history and tab completion. Maybe this feature could be enabled with a tag attribute? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-229) Add list of possible completions to jelly-tags-interaction
[
http://issues.apache.org/jira/browse/JELLY-229?page=comments#action_12378850 ]
Paul Libbrecht commented on JELLY-229:
--
I changed the question to born before the 20th century ;-).
For release to happen is just to get a vote on commons-dev which I opened
yesterday and expect to close on Friday 12:00 GMT.
Is that ok for you ?
paul
Add list of possible completions to jelly-tags-interaction
--
Key: JELLY-229
URL: http://issues.apache.org/jira/browse/JELLY-229
Project: Jelly
Type: New Feature
Components: taglib.interaction
Versions: 1.0
Environment: Linux FC3, jdk-14.2_10, Maven-1.1-beta-3-SNAPSHOT
Reporter: Lukas Theussl
Assignee: Paul Libbrecht
Fix For: 1.1
Attachments: JELLY-229.patch
This is a follow-up of JELLY-175. I added a method setCompletor(list)
allowing to set a list of strings that is used by jline for tab completion.
Use it like: i:ask completor=${list} answer=a/. The list of
tab-completion strings is added to the history list, ie new goals typed in
console mode will always be tab-completed afterwards.
Please note that I have bumped the jline dependency to the latest 0.9.5. This
is not on ibiblio yet, I have created an upload request (
http://jira.codehaus.org/browse/MAVENUPLOAD-883 ), if it is not found, you
will have to put the jline-0.9.5.jar into your local repo by hand.
To test it: I have deployed a snapshot of the maven 1 console plugin:
maven plugin:download
-Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
-DgroupId=maven -DartifactId=maven-console-plugin -Dversion=1.2-SNAPSHOT
The default value for the completor list is
clean,java:compile,jar,test,xdoc,site,quit,help, but you can define your
own custom list using the maven.console.completor.goals property.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-226) Upgrade dom4j and jaxen
[ http://issues.apache.org/jira/browse/JELLY-226?page=comments#action_12378851 ] Paul Libbrecht commented on JELLY-226: -- The current dependency is jaxen 1.1-beta8 and dom4j 1.5. Is that sufficient for you ? Do you need 1.5.2 or 1.6 ? paul Upgrade dom4j and jaxen --- Key: JELLY-226 URL: http://issues.apache.org/jira/browse/JELLY-226 Project: Jelly Type: Wish Components: core / taglib.core, taglib.jsl, taglib.xml Reporter: Lukas Theussl I am struggling with upgrading dom4j and jaxen for our upcoming maven-1.1 release (see http://jira.codehaus.org/browse/MAVEN-1345 and http://jira.codehaus.org/browse/JAXEN-67 for some chunks of discussion). Part of the problem seems to be some kind of binary incompatibility in project dependencies of jelly. I tried to rebuild jelly with the latest dom4j-1.6.1 and jaxen-1.1-beta-8 but failed due to several broken test cases, in particular in the jsl tag library. It would be nice if we had a jelly release with unified dependencies, even though I am not sure it will solve our problem of dropped CDATA sections that I described in JAXEN-67. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] taglibs lead distribution ?
Hi, I was fiddling with Jira jelly project administration because interaction didn't have a component and realized that some components have been assigned to dion... which is good. I'd like it if we could distribute the lead of all components, also so that James Strachan is not anymore the default assignee!! I'd be willing to take over xml and swing tag-libs... maybe some others. Would anyone wish those ? Would anyone be ready to take over others ? Some taglibs are not in urgent need but some really have a need and this way we could react better to requests which keep coming as jelly, even though it tastes unfinished, still has a good attraction, I feel. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-229) Add list of possible completions to jelly-tags-interaction
[ http://issues.apache.org/jira/browse/JELLY-229?page=all ]
Paul Libbrecht resolved JELLY-229:
--
Fix Version: 1.1-beta-1
Resolution: Fixed
Assign To: Paul Libbrecht (was: james strachan)
Applying patch and successfully run the described test and the included sample.
I'd wish for automated tests but this seems impossible for now. So we'll...
just... accept by seeing that the sample works.
paul
Add list of possible completions to jelly-tags-interaction
--
Key: JELLY-229
URL: http://issues.apache.org/jira/browse/JELLY-229
Project: Jelly
Type: New Feature
Environment: Linux FC3, jdk-14.2_10, Maven-1.1-beta-3-SNAPSHOT
Reporter: Lukas Theussl
Assignee: Paul Libbrecht
Fix For: 1.1-beta-1
Attachments: JELLY-229.patch
This is a follow-up of JELLY-175. I added a method setCompletor(list)
allowing to set a list of strings that is used by jline for tab completion.
Use it like: i:ask completor=${list} answer=a/. The list of
tab-completion strings is added to the history list, ie new goals typed in
console mode will always be tab-completed afterwards.
Please note that I have bumped the jline dependency to the latest 0.9.5. This
is not on ibiblio yet, I have created an upload request (
http://jira.codehaus.org/browse/MAVENUPLOAD-883 ), if it is not found, you
will have to put the jline-0.9.5.jar into your local repo by hand.
To test it: I have deployed a snapshot of the maven 1 console plugin:
maven plugin:download
-Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
-DgroupId=maven -DartifactId=maven-console-plugin -Dversion=1.2-SNAPSHOT
The default value for the completor list is
clean,java:compile,jar,test,xdoc,site,quit,help, but you can define your
own custom list using the maven.console.completor.goals property.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] [vote] Release commons-jelly-tags-interaction 1.1
The story seems quite simple so I thought I'd just ask for a vote sorry if too stressed. The interaction jelly tag-library is now ready for release 1.1. It has been recently boosted with a finer control on auto-completion, and maven console plugin is using it successfully. Thanks to give it a try* and provide a vote. This vote will last till Friday 12:00 GMT. [ ] +1 yes let's release it [ ] +0 maybe [ ] -0 seems not ready [ ] -1 no, don't! thank you paul * test instruction. Since Jelly-tags-interaction is mostly for embedding, playing with it can be a challenge. Here's an avenue: - download it, invoke maven jar:install-snapshot then modify the console plugin's project.xml to depend on 1.1-SNAPSHOT, run maven console where you want - run the sample script inside the interaction's test directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-175) patch for jelly-tags-interaction
[
http://issues.apache.org/jira/browse/JELLY-175?page=comments#action_12378439 ]
Paul Libbrecht commented on JELLY-175:
--
I suppose I was too tired...
I did it again... indeed saw that the patch was not needed... and that I got it
working on my Mac.
This ability to change the dependency of an installed plugin is quite amazing,
I have to say.
By working, I could only test inputting goals, going left and right, and
bringing last input goals in... that's already nice.
It'd be nicer that the list of goals is added as possible completions... any
reason not to try to add a method such as setCompletor(list) allowing a i:ask
completor=${list} answer=a/ ?
paul
patch for jelly-tags-interaction
Key: JELLY-175
URL: http://issues.apache.org/jira/browse/JELLY-175
Project: Jelly
Type: Improvement
Environment: I've tested this in windows with and without cygwin.
Reporter: Ryan Christanson
Priority: Minor
Attachments: interaction.patch, patch.txt
I've attached a patch to the commons-jelly-tags-interaction jar. This
patch makes it so the interaction task will try to use jline:
http://jline.sourceforge.net/
Jline makes it so a java console will have tab completion, and
history, and other goodies.
This is great, because the maven-console plugin uses the
commons-jelly-tags-interaction jar. So if you update the
commons-jelly-tags-interaction jar, and then tell the maven console
plugin to use the new jar, then your maven console will have history,
and tab completion.
I've set it up to remember all of the commands typed in any console,
further it uses that history as the tab completion source - so you can
tab complete past commands.
I've tested this in windows and it works great, but in windows with
cygwin, it doesn't do the fancy completion, but still works.
By the way, in windows, jline's lib doesn't support arrows for
history, so use CONTROL+P and CONTROL+N.
Its possible that there might be a better way to integrate jline into
this lib, i've just done what looked like the quickest way to get it
working so my maven console would have history and tab completion.
Maybe this feature could be enabled with a tag attribute?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-175) patch for jelly-tags-interaction
[ http://issues.apache.org/jira/browse/JELLY-175?page=comments#action_12378292 ] Paul Libbrecht commented on JELLY-175: -- Please be more precise as to how this works great for you (platform, how built-in, example code, etc...). Last I tried, precisely the maven embedding did not work. thanks paul patch for jelly-tags-interaction Key: JELLY-175 URL: http://issues.apache.org/jira/browse/JELLY-175 Project: Jelly Type: Improvement Environment: I've tested this in windows with and without cygwin. Reporter: Ryan Christanson Priority: Minor Attachments: interaction.patch, patch.txt I've attached a patch to the commons-jelly-tags-interaction jar. This patch makes it so the interaction task will try to use jline: http://jline.sourceforge.net/ Jline makes it so a java console will have tab completion, and history, and other goodies. This is great, because the maven-console plugin uses the commons-jelly-tags-interaction jar. So if you update the commons-jelly-tags-interaction jar, and then tell the maven console plugin to use the new jar, then your maven console will have history, and tab completion. I've set it up to remember all of the commands typed in any console, further it uses that history as the tab completion source - so you can tab complete past commands. I've tested this in windows and it works great, but in windows with cygwin, it doesn't do the fancy completion, but still works. By the way, in windows, jline's lib doesn't support arrows for history, so use CONTROL+P and CONTROL+N. Its possible that there might be a better way to integrate jline into this lib, i've just done what looked like the quickest way to get it working so my maven console would have history and tab completion. Maybe this feature could be enabled with a tag attribute? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-175) patch for jelly-tags-interaction
[ http://issues.apache.org/jira/browse/JELLY-175?page=comments#action_12378339 ] Paul Libbrecht commented on JELLY-175: -- Very weird, I did the same (you should have also indicated you applied the patch). And... well... I get a very bad result, namely... that maven console just forgets to ask... ie. as if if was EOF... Platform: MacOSX 10.3.9 paul patch for jelly-tags-interaction Key: JELLY-175 URL: http://issues.apache.org/jira/browse/JELLY-175 Project: Jelly Type: Improvement Environment: I've tested this in windows with and without cygwin. Reporter: Ryan Christanson Priority: Minor Attachments: interaction.patch, patch.txt I've attached a patch to the commons-jelly-tags-interaction jar. This patch makes it so the interaction task will try to use jline: http://jline.sourceforge.net/ Jline makes it so a java console will have tab completion, and history, and other goodies. This is great, because the maven-console plugin uses the commons-jelly-tags-interaction jar. So if you update the commons-jelly-tags-interaction jar, and then tell the maven console plugin to use the new jar, then your maven console will have history, and tab completion. I've set it up to remember all of the commands typed in any console, further it uses that history as the tab completion source - so you can tab complete past commands. I've tested this in windows and it works great, but in windows with cygwin, it doesn't do the fancy completion, but still works. By the way, in windows, jline's lib doesn't support arrows for history, so use CONTROL+P and CONTROL+N. Its possible that there might be a better way to integrate jline into this lib, i've just done what looked like the quickest way to get it working so my maven console would have history and tab completion. Maybe this feature could be enabled with a tag attribute? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-203) [Util] [PATCH] Test cases for jelly-tags-util has wrong package
[ http://issues.apache.org/jira/browse/JELLY-203?page=all ] Paul Libbrecht closed JELLY-203: Resolution: Fixed Tastes fixed. paul [Util] [PATCH] Test cases for jelly-tags-util has wrong package --- Key: JELLY-203 URL: http://issues.apache.org/jira/browse/JELLY-203 Project: jelly Type: Bug Components: taglib.util Reporter: Felipe Leme Priority: Minor Attachments: JELLY-203 Some of the test cases uses the class org.apache.commons.jelly.util.Customer, but that class is located at org/apache/commons/jelly/tags/util. I'm attaching a patch that fixes this issue. . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-205) util:loadText adds a new line to files that does not ends with one
[ http://issues.apache.org/jira/browse/JELLY-205?page=comments#action_12373358 ] Paul Libbrecht commented on JELLY-205: -- Do I understand that you consider it fixed but have not unit-test for it ? paul util:loadText adds a new line to files that does not ends with one Key: JELLY-205 URL: http://issues.apache.org/jira/browse/JELLY-205 Project: jelly Type: Bug Components: taglib.util Reporter: Felipe Leme Attachments: JELLY-205.patch, JELLY-205.zip See attached test case (I will try to fix it and provide a full patch). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-205) util:loadText adds a new line to files that does not ends with one
[ http://issues.apache.org/jira/browse/JELLY-205?page=all ] Paul Libbrecht closed JELLY-205: Resolution: Fixed Sorry, dumb of me... sure... clearly fixed... I don't think a unit-test is necessary. paul util:loadText adds a new line to files that does not ends with one Key: JELLY-205 URL: http://issues.apache.org/jira/browse/JELLY-205 Project: jelly Type: Bug Components: taglib.util Reporter: Felipe Leme Attachments: JELLY-205.patch, JELLY-205.zip See attached test case (I will try to fix it and provide a full patch). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-173) Support for XML Schema
[ http://issues.apache.org/jira/browse/JELLY-173?page=comments#action_12373368 ] Paul Libbrecht commented on JELLY-173: -- Felipe, Jelly is not dead but several committers are a bit... busy or tired... I am currently giving a few cycles to polish things out (web-site is broken, gump-tests fail,...) and would like to go further but this is all pretty limited I fear. Most other committers are such, I fear. Wishing more involvement ?? Come over... patches will be welcome! Checking this issue for resolvedness would be nice for example... Going through other bug-lists to mark doable things for both a 1.1-b1 would also be nice. Support for XML Schema -- Key: JELLY-173 URL: http://issues.apache.org/jira/browse/JELLY-173 Project: jelly Type: New Feature Components: taglib.xml Reporter: Felipe Leme There is a bug on the maven-ear-plugin regarding support to genera In order to fix a maven-ear-plugin bug (http://jira.codehaus.org/browse/MPEAR-30), I need to generate a XML-Schema based XML document, but looks like the taglib doesn't allow it. I can see 2 possible solutions: 1.Add more attributes to the x:element tag. Example: x:element name=application xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd; version=1.4 2.Create a new tag specifically for this purpose. Example: x:schemaRoot name=application xmlns=http://java.sun.com/xml/ns/j2ee; xsi=http://www.w3.org/2001/XMLSchema-instance; schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd; version=1.4 If there is another alternative, please let me know. -- Felipe -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] website remake
Dion Gillard wrote:
good stuff!
Does this include the 'new' commons nav/styling changes?
Well... it caused me a few issues especially since the maven 1.1 reactor
causes lng hogs (this is probably the leaks that Brett has been
hunting for in Jelly)
Yes, it does include now (upload since about 20 minutes). The issue
seems to be some way down how java.io.File objects are passed to the
parser, or in the parser itself, in any case, deriving a file to a URL
works, I patched the maven-xdoc-plugin-1.9.2/plugin.jelly by adding at
line 471:
j:new className=java.io.File var=fj:arg
value=x//j:new
j:if
test=${f.getClass().isAssignableFrom(navFile.getClass())}
j:set var=navFile value=${navFile.toURL()}/
/j:if
would love anyone else to test it...
thanks
paul
p.s. You could use your http://people.apache.org/ site to upload it btw.
Just don't need to bloat it for now, having this server at hand... so I
thought that a temporary space as such is better
On 4/4/06, *Paul Libbrecht* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hello,
Since ages, the jelly-site is output wrong where, in particular, the
project info, project reports, and downloads are missing from the
navigation.
Can folks please check
http://klein.activemath.org/~paul/JellyDoc/
http://klein.activemath.org/%7Epaul/JellyDoc/
before I can upload it ?
thanks
paul
PS: this was built with empty target dirs using maven-site...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is
afraid of the dark, but because the dark is afraid of Chuck Norris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed
Now... this area piques me as it's getting so old and it looks like the site not being updated is half a consequence of the failing tests. So I tried it a bit more and got surprised to not reproduce this error with jaxen b8 or b7 but to be able to reproduce this with b4. I tried it with both maven 1.1 and maven 1.0.2 Is there a way to change the jaxen used ? Would anyone else be affected ? And maybe one day we need to throw at select-attribute-parsing! thanks paul commons-jelly-tags-xml development wrote: [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:355:58: x:copyOf You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:355:58: x:copyOf You must define an attribute called 'select' for this tag. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] website remake
Hello, Since ages, the jelly-site is output wrong where, in particular, the project info, project reports, and downloads are missing from the navigation. Can folks please check http://klein.activemath.org/~paul/JellyDoc/ before I can upload it ? thanks paul PS: this was built with empty target dirs using maven-site... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Prime Numbers Library.
Phil Steitz wrote: On 3/11/06, Paul Libbrecht [EMAIL PROTECTED] wrote: I would fear of a library providing such functionality be enormous... any modularity in commons-math planned ? Good question, which comes up over and over again in [math]. That's why I suggested that we focus on primality testing, which is something with practical applications and that could define a more narrow scope. I don't see any harm in experimenting a little in this area. I think indeed this would be good as first stab. [...] When you say modularity do you mean splitting up the jar artifacts produced? I thnk we have talked about that before and could be it will make sense eventually to do this. Do you think the 1.1 jar is too big? Right, it was about it... It could also be about dependencies and/or scopes of each projects. For example for Jelly it was *needed* because, for example, some taglibs have picky dependencies. I don't think it's the case here. The current commons-math is quite small thus far... indeed... So it'd be just a long term suggestion. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jar signing with jarsigner
To me this just means that the signature is, for JNLP deployers, a job of the deployer, or the end-developer and that a signature of Apache Foundation would not help. Correct with that ? Can you tell a bit more ? E.g. is there a comparison between the fields of the JNLP and the fields of the certificate? thanks paul Martin van den Bemt wrote: Yep I used it on a regular base, although it's been a year or so, since I last did this.. I just took the short path : (re) sign all the jars that go into a webstarted application. All signatures in a/each jnlp file should be the same. So eg if all external dependencies are signed by the creator, you need to create a seperate jnlp (include like) file per unique cert, which can kind of suck from a release manager perspective. So my preferred way is to just (re) sign everything with the same cert.. Mvgr, Martin Paul Libbrecht wrote: Paul Libbrecht wrote: I suppose that, with Java Web Start, the jar-signing mechanism may request at least one authorization for each signing key... Has anyone tested a java-web-start application where jars are from different originators? If, indeed as I fear, there are several requests for trust presented to the user, I think ASF jar-signing would help nothing for JNLP deployments... paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Prime Numbers Library.
I would fear of a library providing such functionality be enormous... any modularity in commons-math planned ? paul Sharon Lourduraj wrote: Prime Number Theory is a huge subject. To start of with we can focus on implementing prime finding methods, such as divide by odd numbers up to the square root of a number, divide by primes up to the square root of a number and Sieve of Eratosthenes. As we move along, we can implement prime finding of specific types, Mersenne Prime, Twin Primes, Palindromic Primes etc. And as we move along with those implementations, we can introduce Primality Proving algorithms. Some sites: Basic Prime Number finding - http://www.troubleshooters.com/codecorn/primenumbers/primenumbers.htm Prime Numbers - http://mathworld.wolfram.com/PrimeNumber.html (good site to learn the ins/outs of prime numbers) Primality Proving - http://primes.utm.edu/ Also, we can work on implementing optimized algorithms...I think that would be fun. The practical purpose of Prime Numbers can be extended into encryption/decryption algorithms, but implementing those algorithms might be beyond the scope of this project. Thanks, -Sharon Phil Steitz wrote: This sounds interesting. Can you describe a little more what algorithms you are thinking about implementing? Online references to point us to a common set of definitions for discussion purposes would be great. Also, if you have not aldeady read this, have a look at http://jakarta.apache.org/commons/math/developers.html for info on how to get set up, etc. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jar signing with jarsigner
As far as I could see such a thing... jar signing would need to happen on Apache server... using some Apache private key... right ? Maybe this is a first issue ? How would you go to ensure that such a private key is not hacked or copied ? Let infrastructure team do the signing ? I suppose that, with Java Web Start, the jar-signing mechanism may request at least one authorization for each signing key... paul Sandy McArthur wrote: The discussion on signing releases with PGP led me to wonder why jar's aren't signed with the jarsigner tool? As Java centric as Jakarta is, now that I think about it, it seems kind of strange that the java way of signing code isn't used. I'm not suggesting replacing the PGP sigs on releases, jarsigner doesn't do much with tarballs. Eg: having HttpClient signed would let an admin express with the Java security model that a web app cannot open sockets unless it's being made by an official version of HttpClient. Or that a webapp cannot create temp files except by a signed FileUpload lib. http://java.sun.com/docs/books/tutorial/security1.2/toolsign/ http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/jarsigner.html -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - 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: [all] jar signing with jarsigner
Paul Libbrecht wrote: I suppose that, with Java Web Start, the jar-signing mechanism may request at least one authorization for each signing key... Has anyone tested a java-web-start application where jars are from different originators? If, indeed as I fear, there are several requests for trust presented to the user, I think ASF jar-signing would help nothing for JNLP deployments... paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] building the site?
Yes, if the parser knows the URL of the parsed bit, it can resolve relative entities... paul Phil Steitz wrote: IIRC, the problem results from the fact that the entity is referenced via a relative path. Moving to a URL or File reference would require either an absolute path or that the resource be loaded from a remote URL, which would make offline builds fail. Could be there is a simple trick to make this work? Phil On 2/28/06, Paul Libbrecht [EMAIL PROTECTED] wrote: You wouldn't need to read Xerces in any line... you just need to use an org.xml.sax.InputSource which has a properly set system-id. new InputSource(URL) or new InputSource(File) does make it for you. Generally such resolution error happen to be when an InputSource(InputStream) is used for which the parser has no way to resolve a relative file. Maybe that helps ? paul Arnaud HERITIER wrote: Hi Phil, Yes, I'll try to find a solution to use maven 1.1 to build the commons. I'll certainly need to readd xerces to the core :-( to allow you to use XML entities. cheers arnaud - 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: [all] building the site?
You wouldn't need to read Xerces in any line... you just need to use an org.xml.sax.InputSource which has a properly set system-id. new InputSource(URL) or new InputSource(File) does make it for you. Generally such resolution error happen to be when an InputSource(InputStream) is used for which the parser has no way to resolve a relative file. Maybe that helps ? paul Arnaud HERITIER wrote: Hi Phil, Yes, I'll try to find a solution to use maven 1.1 to build the commons. I'll certainly need to readd xerces to the core :-( to allow you to use XML entities. cheers arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Re: [EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed
At least I can confirm this on my local machine...
paul
Dion Gillard wrote:
Looks like my recent changes to JEXL have fixed this one. The others
appear to be jaxen related.
On 2/14/06, commons-jelly development commons-dev@jakarta.apache.org wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 57 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-WARNING- Overriding Maven properties:
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 56 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14022006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14022006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14022006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-14022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-14022006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-14022006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
test:assertEquals expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by:
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError: expected:[22]
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
Re: [jelly] Gump failures
But remember this is only part of the problem.
The jelly-test failure is related to expression-equality in jexl where:
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
fails because, I think so said Dion, of primitive-types incorrect
comparison in jexl or jelly's packing of jexl.
DIdn't have the time to dive for it yet...
paul
Brett Porter wrote:
I think this could be solved by setting it to use jaxen-1.1-beta-4
instead. I'll try that now. If I can't get it fixed by the end of the
week, I'll turn them off.
I still believe that someone with spare time needs to get Jelly working
with newer versions of Jaxen. Being stuck on beta-4 is not very
desirable, and it appears they are never going to restore backwards
compatibility as it was a deliberate breakage. I'm not that person (I
have neither the xpath knowledge or spare time or need to use Jelly any
more :)
- Brett
Bill Barker wrote:
Henri Yandell [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
*ping*
Waking this thread up again. While it's bad for us to go Jelly HEAD +
Jaxen HEAD - can't work so turn off the build, it's much worse for
us to let the noise continue as that switches people off of paying
attention to the gump errors. It becomes background noise.
Actually, from the Gump page it's using jaxen-1.1b6 (Jaxen HEAD wasn't
building for a long time, so a lot of projects got switched to a packaged
version).
Of course this might be interpreted as a feature request for gump;
don't irritate us by repeating yourself, instead just send us a
summary every now and then of the ones that are long term issues.
Development on Gump is sort of slow right now. Unless somebody wants to
step up with a patch, it may not happen anytime soon ;-).
Still, +1 to any idea that gets rid of the background noise.
The Jelly projects that are failing are basically the unit tests (this is
also true for tags-html, the error for tags-swing is just wierd :). If
nobody care about the tests, you could just get rid of those project /s
in the jakarta-commons-jelly.xml file.
Hen
-
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: [site] problem maven site'ing
My +171717 to bundle Xerces back! (if I dare) paul Brett Porter wrote: Maven 1.1 uses your built in XML parser. Problem is, the two JDKs behave completely differently. I think we need to go back to bundling xerces. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly][vote] APT tag library
Dear Ryan, I am sorry nothing more has happened. At this point, as of me, i am stuck into the fact that I develop on places where Java 1.5 is not available and have very little experience of it. If some other jelly committers do not show an interest to it, I am afraid I will have to suggest another home as you were hinting earlier. paul PS: other help on jelly development is also welcome ! Ryan Heaton wrote: This issue and proposal has been in JIRA now for about a month. Activity (perhaps interest) has been minimal. At this point, I'm not sure what to do. Those who have shown interest have been positive about the proposal. Can (should) we reinitiate the vote? Are the votes that have been offered adequate to continue? -Ryan -Original Message- From: Ryan Heaton [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 11:44 AM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: RE: [jelly][vote] APT tag library I have created a JIRA issue with a comprehensive description, and I've included some examples on what this new tag library can do. http://issues.apache.org/jira/browse/JELLY-225 Comments would be appreciated. -Ryan -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Monday, December 19, 2005 2:10 PM To: Jakarta Commons Developers List Subject: Re: [jelly][vote] APT tag library Ryan, The idea of making it a jira issue is that it's a place you can post to... and that people can see and comment on. I'd put there a tag-library similarly packaged to others in jelly/jelly-tags/. How does it sound ? paul Ryan Heaton wrote: I have not posted a jira issue. I was not aware that was needed. You'll have to be patient with me, I really have no idea how the process to add a component works. I would be happy to proceed through whatever formal process has been established. If someone could explain to me what needs to happen, I'd be happy to drive it. I don't even mind if the component isn't wanted in the commons, I'll put it in sourceforge otherwise. From where I stand, I've got something cool, I believe it will be very useful to many people, and if you want it as part of jelly, I'm willing to submit it and even to maintain it. Please advise. -Ryan -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Monday, December 19, 2005 2:17 AM To: Jakarta Commons Developers List Subject: Re: [jelly][vote] APT tag library I'm slowly catching up on this. Maybe we need to have life with Ryan a bit longer before becoming a committer. In order to send a fully fledged component proposal, Ryan, dare I ask whether you've posted a jira issue already ? This is really needed for all to look at. thanks paul robert burrell donkin wrote: On Thu, 2005-12-15 at 09:48 -0700, Ryan Heaton wrote: I'm adjusting the thread subject to reflect the fact that there is a vote going on for two things: 1. Acceptance of the new APT tag library (described below) 2. Acceptance of me as a committer to support the new apt tag library, if it gets accepted. So far, I have recorded three people voting positive for both proposals: Dion Gillard Hans Gilde Paul Libbrecht hi ryan (sorry to have to start being a little legalistic...) i know that this can be a little confusing but there are votes and VOTEs... both of these need to be official ASF votes. these need more formality that just vague +1's against your proposal. the subject should be [VOTE] (jelly isn't necessary since VOTEs are commons-wide and may result in some filters not recognising your post as a vote thread). we're really only getting up to speed with the new processes for accepting code which is not original so you might need a little patience. so, apologies in advance... i'm not sure there's any consensus about the best way to approach software grants but i'd expect to understand the provinence of the donated code before i'd be willing to +1. i'd also expect a jelly committer to start the VOTE thread. it's not really possible to have conditional approval for a committer and it's poor netiquette to nominate yourself as a committer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Releases of jelly and jelly-tags-xml ?
There's at least a major issue to be solved before a release of jelly and jelly-xml: Gump testing, including the usage of the latest jexl as well as hope for a release of jaxen. The problems is that many unit-tests currently fail because jexl now handles correctly primitive types but then may be wrong add doing equality of expressions using primitive number types. As for jaxen, the problem is just that we wish to be using... a release. Finally, for jelly-1.1, there's this large wish for a more understandable tag-caching which we just haven't done yet... but that could be, maybe, unfortunately, delayed to or 2.0... paul Diogo Quintela (EF) wrote: I back you up Greg. Indeed, we are only using those because of core/xml related changes (xml pipeline / xml namespace) introduced to support those xsd declarations (but are by far more than that) Paul Libbrecht has worked on those http://issues.apache.org/jira/browse/JELLY-214 http://issues.apache.org/jira/browse/JELLY-213 Regarding releasing as RC, I am +1 on this, but after-all, that's only my silent vote :-) Regards Diogo Hi list, As recently and quickly discussed on irc with Dion, I was wondering if there would be any possible plans for releasing jelly and jelly-tags-xml. I'm writing as one of the xdoclet2 developers: we currently depend on post-1.0 snapshots of both of -core and -tags-xml, and, as you might guess, we'd very much like to switch back to stable releases. As far as I can tell, the only reason we use these versions is because they added support for xsd declarations in generated xml documents. (And xdoclet2 has plugins to generate j2ee descriptors which require an xsd declaration) Of course we'd be very keen on testing any RC, and our test codebase might help in that respect. Does this sound feasible / would anyone be interested in pushing this out ? Thanks, greg ps: the snapshots we currently use are actually timestamped versions: commons-jelly-20050813.225330 commons-jelly-tags-xml-20050823.222913 - 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: [jelly] Releases of jelly and jelly-tags-xml ?
Grégory Joseph wrote: Thanks for the status. Sounds like a long chain of release-waiting... do you guys have any idea on the release plans of jexl and jaxen ? Unfortunately not since the cycles are missing. Help on the jexl issue by attempts and suggestions for patches would be more than welcome. Just change the project.xml to take jexl as snapshot! As for Jaxen, maybe we can delay that one... not sure. All this is out of my head... Have you looked into jira to confirm this ( https://issues.apache.org/jira/browse/JELLY ) ? thanks paul Finally, for jelly-1.1, there's this large wish for a more understandable tag-caching which we just haven't done yet... but that could be, maybe, unfortunately, delayed to or 2.0... I'd be in favor of delaying that indeed ;-) Cheers, greg Diogo Quintela (EF) wrote: I back you up Greg. Indeed, we are only using those because of core/xml related changes (xml pipeline / xml namespace) introduced to support those xsd declarations (but are by far more than that) Paul Libbrecht has worked on those http://issues.apache.org/jira/browse/JELLY-214 http://issues.apache.org/jira/browse/JELLY-213 Regarding releasing as RC, I am +1 on this, but after-all, that's only my silent vote :-) Regards Diogo Hi list, As recently and quickly discussed on irc with Dion, I was wondering if there would be any possible plans for releasing jelly and jelly-tags-xml. I'm writing as one of the xdoclet2 developers: we currently depend on post-1.0 snapshots of both of -core and -tags-xml, and, as you might guess, we'd very much like to switch back to stable releases. As far as I can tell, the only reason we use these versions is because they added support for xsd declarations in generated xml documents. (And xdoclet2 has plugins to generate j2ee descriptors which require an xsd declaration) Of course we'd be very keen on testing any RC, and our test codebase might help in that respect. Does this sound feasible / would anyone be interested in pushing this out ? Thanks, greg ps: the snapshots we currently use are actually timestamped versions: commons-jelly-20050813.225330 commons-jelly-tags-xml-20050823.222913 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: media tools
Damian Hamill wrote: I await your advice on the issue of patents (Martin van den Bemt) however should the possibility of patent issues stop us ? I mean there is a patent for MP3 but the folks at javazoom have released an MP3 decoder. Isn't it OK to release in source form ? If you read a bit about it, you'll find quite diverging voices including some that say that, in order to implement MP3, you basically need to either call your project LAME or pay the license... would that be not true anymore ? paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] The ASF as a W3C member (WAS: [scxml] compliance with SCXML Working Draft)
You definitely need to send such a wish to the general xml list at least. Note also much w3c interaction can be done without membership... paul Rahul Akolkar wrote: On 1/16/06, Tim OBrien [EMAIL PROTECTED] wrote: snip/ ...this brings up another issue, I think it would be beneficial for the ASF to join the W3C, but we're currently not a Member organization. snap/ FWIW, I'd like to see this happen as well. I believe Commons SCXML is an example where we're beginning to see useful interactions between the ASF and the W3C, and IMO, the ASF can only gain by being a W3C member. If we stare at the W3C member list ... http://www.w3.org/Consortium/Member/List ... we see members such as: * OASIS * Mozilla and it is probably time to float this thought at the ASF. So, a couple of questions: * Anyone else has any views on this? * What would be the appropriate ASF forum to begin this conversation? -Rahul - 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][Jelly] new features : properties VFS integration
That seems annoying to insert yet another dependence, or ?
Services for the test ? Would that run with gump ?
paul
Benoit Callebaut wrote:
Hello James,
Thanks for highlighting some mistakes.
project.xml has a new dependency on vfs.
I am actually rewritting the whole stuff to make the commons-vfs
integration patch independant of the property modification.
I am also writing a lot of test.
Some of them will add extra dependencies mainly on the commons-net
project.
I have also to setup my linux-box at home to support all the services requested
for the test.
On that point, I have a remark more for the VFS guys. In the VFS
properties file, there are hard-coded things like IP address and test
account. It is not portable across systems.
Le dim 18/12/2005 à 23:40, [EMAIL PROTECTED] a écrit :
Hi Benoit,
I'm new to the commons-dev list, forgive me if my comments are not
posted to the right place.
-Original Message-
From: Benoit Callebaut [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 December 2005 10:18 PM
To: commons-dev@jakarta.apache.org
Subject: [PATCH][Jelly] new features : properties VFS integration
Hello,
This patch add 2 features :
Index: src/java/org/apache/commons/jelly/tags/core/FileTag.java
[ ... snip ... ]
@@ -55,8 +72,42 @@
public void doTag(final XMLOutput output) throws JellyTagException {
try {
if ( name != null ) {
+OutputStream out = null;
String encoding = (this.encoding != null) ? this.encoding :
UTF-8;
-Writer writer = new OutputStreamWriter( new
FileOutputStream( name, doAppend ), encoding );
+Object obj = null;
+obj = getContext().getProperty(VFSManager);
+if ((obj == null) (obj instanceof FileSystemManager)){
^^^
Shouldn't this be obj != null ?
+manager = (FileSystemManager)obj;
+}
+if (manager == null){
+log.error(Manager not initialized. Falling back on
old functionality);
+if ( name != null ) {
+out = new FileOutputStream( name, doAppend );
+}
+}else{
Index: project.xml
Are there actually any changes to project.xml in your patch, or is it all
formatting? It would be a lot easier
if superfluous changes were removed from the patch.
Index: parent-project.xml
Same again...
Index: src/java/org/apache/commons/jelly/JellyContext.java
@@ -262,6 +267,22 @@
return null;
}
+public Hashtable getProperties(){
+return properties;
+}
+
+public Object setProperty(String name, Object value){
+return properties.put(name,value);
+}
+
+public Object getProperty(String name){
+try{
+return properties.get(name);
+}catch (Exception e){
+return null;
+}
+}
+
I think
public Object getProperty(String name) {
if (name == null)
return null;
return properties.get(name);
}
is nicer than catching this exception.
Benoit
Thanks!
Regards,
James
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly][vote] APT tag library
robert burrell donkin wrote: not sure whether additional karma is required to add a component Oh well, you need to be a committer if you want to maintain such in svn. I think I'd summarize the things as follows: - Ryan indicated he had this tag-library and would like to propose it - Dion indicated he'd rather have help at committership to maintain such a tag-library as we (jelly committers tend to loose responsiveness a bit too often nowadays) - a kind of informal vote was requested - some votes, some comments on the informallity - you (Robert) came to say that committership seemed a bit heavy to request for such a new contribution which I tend to understand (basically, all the committerships I've known, except for the sandbox fresh-components, have started with a live participation to commons-dev, commons-users, and jira, with advise to existing committers). - thus I suggested Ryan to make one in jira and we start looking at it, horribly realizing that jira is not clickable from the jelly web-pages and that the life as an active community member contribution starts So the suggestion is for Ryan to get a jira account (as Robert said, just click register), then post, there, an archive with a candidate library, receive comments, repost, see it arrive inside svn, and evolve etc... hoping it'll have clarified things paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] APT tag library
Gee... a website rebuild has broken Jelly's website where all project-info and project-reports links are actually hidden... that needs to be touched in not too long! In any case, the jira page for Jelly is: http://jakarta.apache.org/commons/jelly/ I think anyone can create an account. paul Ryan Heaton wrote: That sounds great. How do I get a jira account so I can add a component? -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Monday, December 19, 2005 2:10 PM To: Jakarta Commons Developers List Subject: Re: [jelly][vote] APT tag library Ryan, The idea of making it a jira issue is that it's a place you can post to... and that people can see and comment on. I'd put there a tag-library similarly packaged to others in jelly/jelly-tags/. How does it sound ? paul Ryan Heaton wrote: I have not posted a jira issue. I was not aware that was needed. You'll have to be patient with me, I really have no idea how the process to add a component works. I would be happy to proceed through whatever formal process has been established. If someone could explain to me what needs to happen, I'd be happy to drive it. I don't even mind if the component isn't wanted in the commons, I'll put it in sourceforge otherwise. From where I stand, I've got something cool, I believe it will be very useful to many people, and if you want it as part of jelly, I'm willing to submit it and even to maintain it. Please advise. -Ryan -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Monday, December 19, 2005 2:17 AM To: Jakarta Commons Developers List Subject: Re: [jelly][vote] APT tag library I'm slowly catching up on this. Maybe we need to have life with Ryan a bit longer before becoming a committer. In order to send a fully fledged component proposal, Ryan, dare I ask whether you've posted a jira issue already ? This is really needed for all to look at. thanks paul robert burrell donkin wrote: On Thu, 2005-12-15 at 09:48 -0700, Ryan Heaton wrote: I'm adjusting the thread subject to reflect the fact that there is a vote going on for two things: 1. Acceptance of the new APT tag library (described below) 2. Acceptance of me as a committer to support the new apt tag library, if it gets accepted. So far, I have recorded three people voting positive for both proposals: Dion Gillard Hans Gilde Paul Libbrecht hi ryan (sorry to have to start being a little legalistic...) i know that this can be a little confusing but there are votes and VOTEs... both of these need to be official ASF votes. these need more formality that just vague +1's against your proposal. the subject should be [VOTE] (jelly isn't necessary since VOTEs are commons-wide and may result in some filters not recognising your post as a vote thread). we're really only getting up to speed with the new processes for accepting code which is not original so you might need a little patience. so, apologies in advance... i'm not sure there's any consensus about the best way to approach software grants but i'd expect to understand the provinence of the donated code before i'd be willing to +1. i'd also expect a jelly committer to start the VOTE thread. it's not really possible to have conditional approval for a committer and it's poor netiquette to nominate yourself as a committer. - 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: [PATCH][Jelly] new features : properties VFS integration
Dear Benoit,
I second James comments posted earlier.
I'd also like to request the following:
- the VFS embedding sounds relatively smooth to me, I'd easily consider
including it into Jelly... it's a hard one though since it's about
jelly-core.
- the properties enrichment is quite a radical change... and it's also
about the core... so please bare with us to give us time to ponder that
For both I would suggest the following:
- you split the patches and make sure they are minimal
- both features need to be thoroughly unit-tested... (with several
protocols for VFS?)
- you post each of the patches as separate jira issues.
(and maybe you need to sign CLA, not sure).
paul
Benoit Callebaut wrote:
Hello,
This patch add 2 features :
* Properties : Properties are something like variables but are
intended to be used internally to modify the behavior of some tags.
Functionality of properties can be managed by variables but properties
avoid the problem of defining variables recognized internally by tags.
I use the properties to add custom extra pre and post processing for
tags. If a special property called pre-content is defined as a object
implementing the new TagProcessor interface, the classes TagScript
and TextScript will call the methods of the object before and after
processing the tag/text.
This is very handy to implements a Jelly debugger of a formatter on the
Jelly output.
I added a new tag to set them. It is called attribute
* support for VFS for the FileTag. I integrated the VFS library in the
FileTag. This means that it is possible to use VFS supported file
systems as output targets. Per default, it will behave as the old
FileTag if no VFS file systems are configured.
This patch doesn't break any existing test. I wrote a test case for the
first modification.
I need those modifications for my library.
This library generates formatted source code and does rely on a file
system neutral approach.
Moreover, I don't want to modify existing jelly scripts and I don't want
to pipe the output of one jelly script to the input of another jelly
script for something like formatting
I will be able to give more test-case and feedback of the usefulness of
those modifications when my output library is developed.
Benoit
Index: src/test/org/apache/commons/jelly/TestCoreTags.java
===
--- src/test/org/apache/commons/jelly/TestCoreTags.java (revision 356995)
+++ src/test/org/apache/commons/jelly/TestCoreTags.java (working copy)
@@ -32,7 +32,7 @@
/** Tests the core tags
*
* @author a href=mailto:[EMAIL PROTECTED]James Strachan/a
- * @version $Revision$
+ * @version $Revision: 219726 $
*/
public class TestCoreTags extends TestCase {
@@ -125,4 +125,28 @@
blip xmlns:blop=\blop\ blop:x=\blip\/blip,
text);
}
+
+public void testProcessor() throws Exception{
+InputStream in = new
FileInputStream(src/test/org/apache/commons/jelly/test_processor.jelly);
+XMLParser parser = new XMLParser();
+ProcessorTest proc = new ProcessorTest(this,log);
+Script script = parser.parse(in);
+script = script.compile();
+log.debug(Found: + script);
+assertTrue(Parsed a Script, script instanceof Script);
+String[] args = { one, two, three };
+JellyContext context = new JellyContext();
+context.setVariable(proc,proc);
+context.setVariable(args, args);
+StringWriter buffer = new StringWriter();
+script.run(context, XMLOutput.createXMLOutput(buffer));
+String text = buffer.toString().trim();
+if (log.isDebugEnabled()) {
+log.debug(Evaluated script as...);
+log.debug(text);
+
+}
+log.info(text);
+assertEquals(Produces the correct output, {{{one}{ }}{{two}{ }}{{three}{
}}}, text);
+}
}
Index: src/java/org/apache/commons/jelly/tags/core/FileTag.java
===
--- src/java/org/apache/commons/jelly/tags/core/FileTag.java(revision
356995)
+++ src/java/org/apache/commons/jelly/tags/core/FileTag.java(working copy)
@@ -16,6 +16,7 @@
package org.apache.commons.jelly.tags.core;
import java.io.FileNotFoundException;
+import java.io.OutputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStreamWriter;
@@ -23,6 +24,9 @@
import java.io.UnsupportedEncodingException;
import java.io.Writer;
+
+import org.apache.commons.logging.*;
+import org.apache.commons.vfs.*;
import org.apache.commons.jelly.JellyTagException;
import org.apache.commons.jelly.TagSupport;
import org.apache.commons.jelly.XMLOutput;
@@ -35,8 +39,12 @@
/**
* A tag that pipes its body to a file denoted by the name attribute or to an
in memory String
* which is
Re: [jelly][vote] APT tag library
I'm slowly catching up on this. Maybe we need to have life with Ryan a bit longer before becoming a committer. In order to send a fully fledged component proposal, Ryan, dare I ask whether you've posted a jira issue already ? This is really needed for all to look at. thanks paul robert burrell donkin wrote: On Thu, 2005-12-15 at 09:48 -0700, Ryan Heaton wrote: I'm adjusting the thread subject to reflect the fact that there is a vote going on for two things: 1. Acceptance of the new APT tag library (described below) 2. Acceptance of me as a committer to support the new apt tag library, if it gets accepted. So far, I have recorded three people voting positive for both proposals: Dion Gillard Hans Gilde Paul Libbrecht hi ryan (sorry to have to start being a little legalistic...) i know that this can be a little confusing but there are votes and VOTEs... both of these need to be official ASF votes. these need more formality that just vague +1's against your proposal. the subject should be [VOTE] (jelly isn't necessary since VOTEs are commons-wide and may result in some filters not recognising your post as a vote thread). we're really only getting up to speed with the new processes for accepting code which is not original so you might need a little patience. so, apologies in advance... i'm not sure there's any consensus about the best way to approach software grants but i'd expect to understand the provinence of the donated code before i'd be willing to +1. i'd also expect a jelly committer to start the VOTE thread. it's not really possible to have conditional approval for a committer and it's poor netiquette to nominate yourself as a committer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly][vote] APT tag library
Ryan, The idea of making it a jira issue is that it's a place you can post to... and that people can see and comment on. I'd put there a tag-library similarly packaged to others in jelly/jelly-tags/. How does it sound ? paul Ryan Heaton wrote: I have not posted a jira issue. I was not aware that was needed. You'll have to be patient with me, I really have no idea how the process to add a component works. I would be happy to proceed through whatever formal process has been established. If someone could explain to me what needs to happen, I'd be happy to drive it. I don't even mind if the component isn't wanted in the commons, I'll put it in sourceforge otherwise. From where I stand, I've got something cool, I believe it will be very useful to many people, and if you want it as part of jelly, I'm willing to submit it and even to maintain it. Please advise. -Ryan -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Monday, December 19, 2005 2:17 AM To: Jakarta Commons Developers List Subject: Re: [jelly][vote] APT tag library I'm slowly catching up on this. Maybe we need to have life with Ryan a bit longer before becoming a committer. In order to send a fully fledged component proposal, Ryan, dare I ask whether you've posted a jira issue already ? This is really needed for all to look at. thanks paul robert burrell donkin wrote: On Thu, 2005-12-15 at 09:48 -0700, Ryan Heaton wrote: I'm adjusting the thread subject to reflect the fact that there is a vote going on for two things: 1. Acceptance of the new APT tag library (described below) 2. Acceptance of me as a committer to support the new apt tag library, if it gets accepted. So far, I have recorded three people voting positive for both proposals: Dion Gillard Hans Gilde Paul Libbrecht hi ryan (sorry to have to start being a little legalistic...) i know that this can be a little confusing but there are votes and VOTEs... both of these need to be official ASF votes. these need more formality that just vague +1's against your proposal. the subject should be [VOTE] (jelly isn't necessary since VOTEs are commons-wide and may result in some filters not recognising your post as a vote thread). we're really only getting up to speed with the new processes for accepting code which is not original so you might need a little patience. so, apologies in advance... i'm not sure there's any consensus about the best way to approach software grants but i'd expect to understand the provinence of the donated code before i'd be willing to +1. i'd also expect a jelly committer to start the VOTE thread. it's not really possible to have conditional approval for a committer and it's poor netiquette to nominate yourself as a committer. - 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: [jelly] Gump failures: Jexl !
well, that was correct... it was just a matter of trying and guessing
which was the faulty one...
Change the current parent-project.xml at Jexl from 1.0 to SNAPSHOT...
and you get a very similar error report as gump does.
Change the current parent-project.xml at everything latest (except
Xerces) but keep jexl 1.0... and you get a successful build.
Can someone jexl aware investigate issues there ? Maybe I'll give it
some cycles next week but not earlier.
That should be pretty easy.
thanks
paul
Brett Porter wrote:
It doesn't matter what Maven installation you use, I don't think, though
IIRC Gump still uses 1.0.2 if that helps.
I believe the failure is commons-jelly-tags-xml, not commons-jelly.
Remember, gump uses the latest of everything, so you need to build the
latests Jelly library snapshot and update the dependency of the tags to
use that too.
maven -X will reveal what libraries are actually in use.
- Brett
Paul Libbrecht wrote:
I'm trying hard to fail and fail to fail...
As I understand it would be enough to change
${JELLY_HOME}/parent-project.xml to refer jaxen 1.1-beta-6, 1.1-beta-8
or 1.1-beta-5... but maven clean jar still succeeds with me.
Can it be this is related to the maven classpath ??
Am I understanding something wrong of Gump or this should not be set and
maven should proceeding using its own classpath ?? (in my
maven-1.1-beta-2, this is only forehead.jar which itself builds other
classloaders based on maven-home).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] apt tag library
I am sorry to answer only now... I'd put my vote as well... paul Ryan Heaton wrote: It has been awhile now since I've seen any activity on this thread. I've only seen one person vote. So how does this work? Is one vote adequate for approval? Do we need to encourage more votes? -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 12:50 PM To: Jakarta Commons Developers List Subject: Re: [jelly] apt tag library Ryan, we need to vote on accepting the new code, get a code grant done and possibly work closely with you for support in the early stages, although I'd prefer to see you come on board as a committer to support it. Any one else? On 11/29/05, Ryan Heaton [EMAIL PROTECTED] wrote: I'm (still) looking for help on submitting a new tag library for jelly that contains tags for traversing the apt environment. Dion Gillard was the only one who responded, expressing interest. So, I have the new library code-complete with a solid set of tests that exercise the API. I've got everything documented and I have it locally integrated into the current jelly maven build. What now? Please advise. -Ryan Heaton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - 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: [jelly] Gump failures
I'm trying hard to fail and fail to fail...
As I understand it would be enough to change
${JELLY_HOME}/parent-project.xml to refer jaxen 1.1-beta-6, 1.1-beta-8
or 1.1-beta-5... but maven clean jar still succeeds with me.
Can it be this is related to the maven classpath ??
Am I understanding something wrong of Gump or this should not be set and
maven should proceeding using its own classpath ?? (in my
maven-1.1-beta-2, this is only forehead.jar which itself builds other
classloaders based on maven-home).
paul
Brett Porter wrote:
Stefan Bodewig wrote:
Will Jelly work against Jaxen 1.1? What are you going to tell your users who
want to combine Jelly and Jaxen and want to use the latest released version of
Jaxen?
Oh, its far worse than that. IIRC, Jelly works with Jaxen 1.1 beta 4. Jaxen 1.0
will not work, because it is incompatible with dom4j 1.5/6
which is in use. Jaxen 1.1 beta-5+ is where the build failures came about.
Next to (1) turn off nagging, (2) make Gump use a packaged version of
Jaxen and (3) adapt to the changes in Jaxen there always is (4) make
the Jaxen developers fix the breaking change.
It was intentionally breaking, I think. I was told that it tightening up
conformance. Others are welcome to pursue it further, this isn't really
my realm of expertise.
Note that I'm just stating the alternatives and to me (2) would be the
worst option, since it meant closing the eyes and ignoring future
problems. But whatever you deem appropriate, go ahead and modify
Jelly's Gump descriptors.
I agree. It should be fixed at either the Jelly or Jaxen end, but if
nobody is stepping up to do so (and I certainly can't), then turn off
the nags and put it in jira would be my vote.
- Brett
-
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: [jelly] Gump failures
Brett Porter wrote: It was intentionally breaking, I think. I was told that it tightening up conformance. Others are welcome to pursue it further, this isn't really my realm of expertise. Brett, would you have a copy of the mails ? Such a strengthening would be related to a reported non-conformance issue, or? I agree. It should be fixed at either the Jelly or Jaxen end, but if nobody is stepping up to do so (and I certainly can't), then turn off the nags and put it in jira would be my vote. Maybe I find time to hit this... paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Gump failures
Do i not understand Gump or the fact that we stick Jaxen head is something that could be changed ? Indeed, no-one really wishes to work with the latest jaxen currently. thanks paul Dion Gillard wrote: It's a break in how Jaxen works. Unless we upgrade all of Jelly to work with the code changes in Jaxen, the failures will continue. Personally, I'd rather stick where we are with jaxen in Jelly and stop Gump from nagging us. On 12/2/05, Henri Yandell [EMAIL PROTECTED] wrote: These seem to have been going on for months. Any chance they can be fixed and stop spamming us? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-224) The parser always try to load the DTD even if validate = false
[ http://issues.apache.org/jira/browse/JELLY-224?page=all ] Paul Libbrecht resolved JELLY-224: -- Resolution: Invalid This has nothing to do with Jelly... All XML parsers have to load the DTD when it's referenced since a DTD can indicate default values to attributes (which can also mean namespaces). hope it helps. paul The parser always try to load the DTD even if validate = false -- Key: JELLY-224 URL: http://issues.apache.org/jira/browse/JELLY-224 Project: jelly Type: Bug Components: taglib.xml Environment: Working of line or behind a proxy Reporter: Philippe Kernevez The tag ixml:parse/i always try to load the DTD even if the attribut ivalidate=false/i is used. This cause an error when we use this tag without connection. See: the linked issue http://jira.codehaus.org/browse/MPDASHBOARD-34 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-224) The parser always try to load the DTD even if validate = false
[ http://issues.apache.org/jira/browse/JELLY-224?page=comments#action_12359148 ] Paul Libbrecht commented on JELLY-224: -- You mean like a catalog based on public-identifiers, right ? That could be considered, indeed, within the core tags... but we need to rephrase such a wish! Does anyone have pointer to Xerces support for something like catalogs ? Sorry to have been a bit rude... paul The parser always try to load the DTD even if validate = false -- Key: JELLY-224 URL: http://issues.apache.org/jira/browse/JELLY-224 Project: jelly Type: Bug Components: taglib.xml Environment: Working of line or behind a proxy Reporter: Philippe Kernevez The tag ixml:parse/i always try to load the DTD even if the attribut ivalidate=false/i is used. This cause an error when we use this tag without connection. See: the linked issue http://jira.codehaus.org/browse/MPDASHBOARD-34 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] paul, your changes to ComponentTag
Hans, I've seen your bug-report about keeping this reference. At least if one wished something like reload my parent component with this jelly such a reference would have been needed and I was preparing for such. Hence these changes. Now that, for one, I did not find time to finalize this, and, for two, the refillComponent seems to fit better the picture, I'll live fine with that: do undo my changes for this. thanks paul Le 6 nov. 05, à 19:27, Hans Gilde a écrit : Paul, I see you made some changes to the Swing ComponentTag in January. Is this a line of development that you're still following? If not, I'd like to take some of your changes out, because they cause the tag to keep a reference to its components when it doesn't need one. Hans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Schaible
[X] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] how to donate my JavaScript and Include tag libraries?
Le 8 sept. 05, à 14:19, peter royal a écrit : Since it sounds like this is a larger contribution, it might be necessary for a CLA or a Software Grant to be filled out, http://apache.org/licenses/#clas, but someone with more knowledge can clarify that.. I would also find it good and I believe the CLA is needed in such a case. Maybe even in smaller cases... it is needed as soon as an author tag is there. In order to facilitate the integration as a taglib into the jelly tree please try to imitate what other taglibs do. Among others, making sure the code-conventions are respected is very important as well as the amount of tests. In any case, we look forward to receive this I think! paul PS: thanks peter... I didn't dare answer not remembering the URL of CLAs... ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] 1.0-final problem wrt tag caching
Just for me to be sure to understand... this is definitely a change compared to pre-1.0, or ? Can you maybe update the javadoc of setCacheTags/getCacheTags or should we work on a page lifecycle of a tag ? paul Le 16 août 05, à 03:56, peter royal a écrit : On Aug 15, 2005, at 3:22 AM, Paul Libbrecht wrote: At least a quick summary of caching would be that: if caching is disabled, the tag object is renewed at the beginning of every new run. (where I understood disabled caching would imply the tag would disappear much earlier). Maybe that's a simple formulation... That's exactly correct. On a per-thread basis, TagScript.run() results in a new Tag instance if caching is not enabled. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: SNAPSHOTs in java-repository
Goodness... this didn't reach commons-dev. It must! paul Début du message réexpédié : De: Paul Libbrecht [EMAIL PROTECTED] Date: 15 août 2005 23:01:31 GMT+02:00 À: Henk P. Penning [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], repository@apache.org Objet: Rép : SNAPSHOTs in java-repository Le 14 août 05, à 11:19, Henk P. Penning a écrit : Yesterday these (identical files) were added to the repository: -rw-r--r-- 1 polx Aug 13 15:41 commons-jelly-SNAPHSOT.jar -rw-rw-r-- 1 dion Aug 13 15:41 commons-jelly-SNAPSHOT.jar Paul, Dion, -- SNAPSHOTs (and SNAPHSOTs :-) should not be published in 'www.apache.org/dist/java-repository' ; they should go to the (non mirrored) 'cvs.apache.org', as per http://wiki.apache.org/asfrepository/BrettPorter Thanks Henk for the warning, I was looking for info on how to do this and only found: http://jakarta.apache.org/commons/releases/release.html which mentions http://wiki.apache.org/asfrepository But does not mention http://wiki.apache.org/asfrepository/BrettPorter -- software in 'www.apache.org/dist/' should be versioned, and not be rewritten ; commons-jelly-SNAPHSOT.jar was already in the repository since Wed Aug 10 2005. Much earlier, I think. I'm fine to remove any (non-dated) *-SNAPSHOT.jar of jelly at least (and probably most others). See http://people.apache.org/~henkp/md5/ and click java-repository/commons-jelly/jars/commons-jelly-SNAPSHOT.jar Please cleanup typos (SNAPHSOT) and move SNAPSHOTs over to 'cvs.apache.org'. repository@apache.org, So I'd suggest we adapt Jelly's project.properties which contains it all (at least). But... these wiki pages need some clean-up. Henk, can you be correcting http://wiki.apache.org/asfrepository/ ? thanks paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] snapshots removed from ibiblio
Brett, Le 16 août 05, à 09:16, Brett Porter a écrit : The SNAPSHOT releases of Jelly have been removed from ibiblio. They were way out of date and confusing. If you need to track a development version, they are published to http://cvs.apache.org/repository. The default Maven settings used for jar:deploy publish there already. The one in jelly's project.properties publishes to both cvs.apache.org and www.apache.org using maven. I have removed these files and the timestamped builds from java-repository. This is a release only repository, so those must not be kept there. The timestamped versions remain on ibiblio and the in archive for historical purposes. If anyone has any objections I have retained a copy I can put back to the same spot. You mean the one at www.apache.org, right ? There was a port of Henk recently on this... now forwarding to commons-dev. I'm happy to adjust the properties of jelly for upload but we NEED to adapt the documentation pointers. I went from: http://jakarta.apache.org/commons/releases/release.html to http://wiki.apache.org/asfrepository but didn't see http://wiki.apache.org/asfrepository/BrettPorter which states that the repository at www.apache.org should be for releases only. thanks paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] snapshots removed from ibiblio
I have just added this little point in the shall not section... have a bit of time in order to merge docs in further. paul Le 16 août 05, à 11:38, Brett Porter a écrit : The important thing to remember is not to put anything in /www/www.apache.org/dist that is not a sanctioned release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] 1.0-final problem wrt tag caching
At least a quick summary of caching would be that: if caching is disabled, the tag object is renewed at the beginning of every new run. (where I understood disabled caching would imply the tag would disappear much earlier). Maybe that's a simple formulation... paul Le 15 août 05, à 02:49, Hans Gilde a écrit : Yes, you're running into a fundamental problem: there's no difference between the cache and the mechanism that tags use to look up their parents. The interface solution will be a partial fix, because tags that are never looked up by their children, never need caching. -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Saturday, August 13, 2005 6:31 PM To: Jakarta Commons Developers List Subject: Re: [jelly] 1.0-final problem wrt tag caching Indeed... it is running by me as well but I am fully puzzled. I had added, after your commit, in my version the following which I believed was innocent... it wasn't: In TagScript.java, replace Tag tag = (Tag) threadLocalTagCache.get(t); with Tag tag = null; if(context.isCacheTags()) tag = (Tag) threadLocalTagCache.get(t); Indeed, otherwise, the tag is only cleared at the start of next run. Well, precisely this change made everything fail by me. I'll have to evaluate further for more tags-that-wish-caching but for now... fine! paul Le 13 août 05, à 18:25, peter royal a écrit : On Aug 10, 2005, at 6:14 PM, Paul Libbrecht wrote: I'm annoyed... I don't obtain the same results as you do. With the default cacheTags value as false, I obtain only your test failing. With the default cacheTags value as true, I obtain many failed tests. Did you not say that with your commit, all jelly-core tests were passing ? If not then we really need to push the NeedCaching and RefusesCaching interfaces. Right ? yes, with the change I made, all the tests in jelly-core were passing. can you give an example or two of a test that's failing for you? -pete -- peter royal - 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: [jelly] 1.0-final problem wrt tag caching
Indeed... it is running by me as well but I am fully puzzled. I had added, after your commit, in my version the following which I believed was innocent... it wasn't: In TagScript.java, replace Tag tag = (Tag) threadLocalTagCache.get(t); with Tag tag = null; if(context.isCacheTags()) tag = (Tag) threadLocalTagCache.get(t); Indeed, otherwise, the tag is only cleared at the start of next run. Well, precisely this change made everything fail by me. I'll have to evaluate further for more tags-that-wish-caching but for now... fine! paul Le 13 août 05, à 18:25, peter royal a écrit : On Aug 10, 2005, at 6:14 PM, Paul Libbrecht wrote: I'm annoyed... I don't obtain the same results as you do. With the default cacheTags value as false, I obtain only your test failing. With the default cacheTags value as true, I obtain many failed tests. Did you not say that with your commit, all jelly-core tests were passing ? If not then we really need to push the NeedCaching and RefusesCaching interfaces. Right ? yes, with the change I made, all the tests in jelly-core were passing. can you give an example or two of a test that's failing for you? -pete -- peter royal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Jelly Builds
Mrrrfs, it was on http://www.apache.org/dist/java-repository/commons-jelly/jars/ as indicated in Cutting a release. If have put it at http://cvs.apache.org/repository as well now. I am not sure we can keep both or ? Also... I was not able (yet?) to make the md5 checksums so I removed them (for commons-jelly-(xml?)-SNAPSHOT.jar). paul Le 11 août 05, à 12:39, Diogo Quintela (EF) a écrit : Paul, You seem to have uploaded the files. I am not seeing them there. A couple of days I've mailed you some comments regarding tag caching. Has seen on the thread on mailing list this is a work in progress. Is this functionality default set for the version you uploaded/uploading ? Regards Diogo --- Diogo Bacelar Quintela EF - Tecnologias de Informação, Lda. Av. António Serpa, 26 - 4º Dto. 1050-027 Lisboa, Portugal Tel: (+351) 217 827 800 Fax: (+351) 217 827 830 Email: [EMAIL PROTECTED] PGP: 0xF51A5AB9 | -Original Message- | From: Paul Libbrecht [mailto:[EMAIL PROTECTED] | Sent: quarta-feira, 10 de Agosto de 2005 23:49 | To: Jakarta Commons Developers List | Subject: Re: [jelly] Jelly Builds | | | Le 4 août 05, à 12:56, Paul Libbrecht a écrit : | | I'll put jelly and jelly-tags-xml current snapshots and | http://cvs.apache.org/repository if I manage | |Now done (with the version right before Peter's commit). Where are these? http://cvs.apache.org/repository/commons-jelly/jars/?C=M;O=D I don't seen any news files there :( | | |I am wondering wether our tags's projects (at least) shouldn't |explicitly declare the property that the remote-repository should be |the one at apache then the one at iBiblio. |Or ? | |paul - 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: [jelly] Jelly Builds
Well... I've just committed this... this might have been a source of
leaks!
Now... before I create another snapshot I'd like to clear first the
things with respect to tag caching.
Currently, if tag-caching defaults to true... all the tests except
TestUnexpectedTagCaching succeed.
If it defaults to false many fail.
I'd like to make a snapshot and commit with default caching activated
and with TestUnexpectedTagCaching commented out.
What do you think ?
paul
Le 11 août 05, à 14:48, Diogo Quintela (EF) a écrit :
Paul
That snapshot still has the issue I mention to you earlier.
Tag caching is not working seamless for StaticTag, attributes list
is
growing between several invocations.
In StaticTag.doTag()
If we add
finally {
attributes.clearAtributes() // should do the trick
}
Diogo
---
Diogo Bacelar Quintela
EF - Tecnologias de Informação, Lda.
Av. António Serpa, 26 - 4º Dto.
1050-027 Lisboa, Portugal
Tel: (+351) 217 827 800
Fax: (+351) 217 827 830
Email: [EMAIL PROTECTED]
PGP: 0xF51A5AB9
-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: quinta-feira, 11 de Agosto de 2005 12:44
To: Jakarta Commons Developers List
Subject: Re: [jelly] Jelly Builds
Mrrrfs, it was on
http://www.apache.org/dist/java-repository/commons-jelly/jars/
as indicated in Cutting a release.
If have put it at http://cvs.apache.org/repository as well now.
I am not sure we can keep both or ?
Also... I was not able (yet?) to make the md5 checksums so I removed
them (for commons-jelly-(xml?)-SNAPSHOT.jar).
paul
Le 11 août 05, à 12:39, Diogo Quintela (EF) a écrit :
Paul,
You seem to have uploaded the files. I am not seeing them there.
A couple of days I've mailed you some comments regarding tag caching.
Has
seen on the thread on mailing list this is a work in progress.
Is this functionality default set for the version you
uploaded/uploading ?
Regards Diogo
---
Diogo Bacelar Quintela
EF - Tecnologias de Informação, Lda.
Av. António Serpa, 26 - 4º Dto.
1050-027 Lisboa, Portugal
Tel: (+351) 217 827 800
Fax: (+351) 217 827 830
Email: [EMAIL PROTECTED]
PGP: 0xF51A5AB9
| -Original Message-
| From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
| Sent: quarta-feira, 10 de Agosto de 2005 23:49
| To: Jakarta Commons Developers List
| Subject: Re: [jelly] Jelly Builds
|
|
| Le 4 août 05, à 12:56, Paul Libbrecht a écrit :
|
| I'll put jelly and jelly-tags-xml current snapshots and
| http://cvs.apache.org/repository if I manage
|
|Now done (with the version right before Peter's commit).
Where are these?
http://cvs.apache.org/repository/commons-jelly/jars/?C=M;O=D
I don't seen any news files there :(
|
|
|I am wondering wether our tags's projects (at least) shouldn't
|explicitly declare the property that the remote-repository should be
|the one at apache then the one at iBiblio.
|Or ?
|
|paul
-
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]
