Re: cvs commit: cocoon-2.1/lib jars.xml
[EMAIL PROTECTED] wrote: antonio 2004/03/03 23:01:56 Modified:lib jars.xml Log: Updated POI to 2.5-final-20040302 Is name of the JAR file coming from POI project? It's weird to see poi-2.5-final-20040302 instead of poi-2.5 as for other projects. Vadim
Re: cvs commit: cocoon-2.1/lib jars.xml
Vadim Gritsenko dijo: [EMAIL PROTECTED] wrote: antonio 2004/03/03 23:01:56 Modified:lib jars.xml Log: Updated POI to 2.5-final-20040302 Is name of the JAR file coming from POI project? It's weird to see poi-2.5-final-20040302 instead of poi-2.5 as for other projects. Yep. In this case I just did a copy paste. This weird names is the names they are using since 2.0-final. You can download the binaries and see it. Best Regards, Antonio Gallardo
Re: cvs commit: cocoon-2.1/lib jars.xml
On 03.12.2003 15:38, [EMAIL PROTECTED] wrote: unico 2003/12/03 06:38:47 Modified:lib jars.xml Log: Grrr! typo -libslide/lib/jdom-b10-dev-20031322.jar/lib +libslide/lib/jdom-b10-dev-20030322.jar/lib Unfortunately not only in jars.xml, but also at the JARs name itself. Joerg
Re: cvs commit: cocoon-2.1/lib jars.xml
Geoff Howard wrote: Stefano Mazzocchi wrote: On Wednesday, Oct 15, 2003, at 06:23 Europe/Rome, Stephen McConnell wrote: Geoff Howard wrote: Geoff Howard wrote: But a browse around ibiblio reveals: http://www.ibiblio.org/maven/jms/ http://www.ibiblio.org/maven/jndi/ exist but don't have any jars. ... Nother approach is to rewrite the libraries from the javadocs under an apache license (the Servlet API code that is shipped with tomcat is licensed under the apache license and yet covers javax.servlet... if you pass the test, it's valid) Hmm - this is intruiging. Are you saying I can create an apache version of javax.jms and friends? This is bizarre with interfaces and abstract classes isn't it? http://www.ibiblio.org/maven/geronimo-spec/jars/ :) Occurred to me earlier today that geronimo may be doing this. Any problem with putting that Jar in CVS? (and the jndi, and javamail, etc. which are in their cvs but not up at ibiblio yet...) Geoff
Re: cvs commit: cocoon-2.1/lib jars.xml
On Wednesday, Oct 15, 2003, at 06:23 Europe/Rome, Stephen McConnell wrote: Geoff Howard wrote: Geoff Howard wrote: But a browse around ibiblio reveals: http://www.ibiblio.org/maven/jms/ http://www.ibiblio.org/maven/jndi/ exist but don't have any jars. And looks like Stephen knows why - I had assumed ASF was being conservative (wisely, I assume) and that ibiblio would be able to redistribute. The ibiblio site is no different from Apache with respect to license obligations. When the Maven project started its bid to TLP is basically had to clean up its act bacause the content on ibiblio would by implication be resource managed by an Apache PMC - i.e. due-diligence required. The Maven guys went though a process of cleaning up the content on ibiblio.org/maven and the result of the cleanup is the missing jar files. I guess the best bet would be to grab the openjms package which contains everything needed? Unless it can be automated we'll need some work on the block to make sure it compiles and cocoon can start up without that part. Not sure how to pull that off. One approach you may want to consider is to package the content into a bar file, register the bar in cvs, add an ant task to download and expand the bar, and invoke bar expansion in the build. Providing you access the resources via a local repository, you are respecting the Sun licensing conditions because your accessing the resources relative to a particular application context that has a legal usage engagement. What this means is that whoever packages the jms libraries (or whowever accepts responsibilioty for the packaging) agrees to represent Sun should a problem arise. If the bar contribution to Cocoon is by a committer covered by a CLA, then the responsibility for the application usage rests with Apache. Nother approach is to rewrite the libraries from the javadocs under an apache license (the Servlet API code that is shipped with tomcat is licensed under the apache license and yet covers javax.servlet... if you pass the test, it's valid) but I know this isn't really a sexy approach ;-) -- Stefano.
Re: cvs commit: cocoon-2.1/lib jars.xml
Stefano Mazzocchi wrote: On Wednesday, Oct 15, 2003, at 06:23 Europe/Rome, Stephen McConnell wrote: Geoff Howard wrote: Geoff Howard wrote: But a browse around ibiblio reveals: http://www.ibiblio.org/maven/jms/ http://www.ibiblio.org/maven/jndi/ exist but don't have any jars. The ibiblio site is no different from Apache with respect to license obligations. When the Maven project started its bid to TLP is basically had to clean up its act bacause the content on ibiblio would by implication be resource managed by an Apache PMC - i.e. due-diligence required. The Maven guys went though a process of cleaning up the content on ibiblio.org/maven and the result of the cleanup is the missing jar files. ... Nother approach is to rewrite the libraries from the javadocs under an apache license (the Servlet API code that is shipped with tomcat is licensed under the apache license and yet covers javax.servlet... if you pass the test, it's valid) Hmm - this is intruiging. Are you saying I can create an apache version of javax.jms and friends? This is bizarre with interfaces and abstract classes isn't it? but I know this isn't really a sexy approach ;-) Hey, I've never been sexy before - why start now? ;) Geoff
Re: cvs commit: cocoon-2.1/lib jars.xml
On Tuesday, Oct 14, 2003, at 18:40 Europe/Rome, [EMAIL PROTECTED] wrote: haul2003/10/14 09:40:09 Modified:.blocks.properties gump.xml lib jars.xml Added: src/blocks/jms/samples sitemap.xmap src/blocks/jms/samples/database access-error.xml eventcache.xsp install.xsp invalidated.xml remove.xsp sitemap.xmap src/blocks/jms/java/org/apache/cocoon/samples/jms HTTPTrigger.java JMSTrigger.java src/blocks/jms/java/org/apache/cocoon/components/jms JMSConnection.java JMSConnectionImpl.java JMSEventListener.java JMSPublisherAction.java src/blocks/jms/conf jms.xsamples jmsconnection.xconf jmslistener.xconf Log: Start of an JMS block. Goes together with the eventcache block. Default: excluded Anyone an idea about the licence for JMS JNDI redistribution? we cannot redistribute those. but you could have a build.xml in the block and get them from ibiblio's maven repository. -- Stefano.
Re: cvs commit: cocoon-2.1/lib jars.xml
Stefano Mazzocchi wrote: On Tuesday, Oct 14, 2003, at 18:40 Europe/Rome, [EMAIL PROTECTED] wrote: Anyone an idea about the licence for JMS JNDI redistribution? we cannot redistribute those. but you could have a build.xml in the block and get them from ibiblio's maven repository. Damn. I was afraid you'd say this. It's just that the Sun license for them has some limited redistribution addition and the OpenJMS project does distribute them (even without including a license file for them). Looks like I need to look into this local build file thing :-| Life could be so easy. Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: cvs commit: cocoon-2.1/lib jars.xml
On Tuesday, Oct 14, 2003, at 21:58 Europe/Rome, Christian Haul wrote: Stefano Mazzocchi wrote: On Tuesday, Oct 14, 2003, at 18:40 Europe/Rome, [EMAIL PROTECTED] wrote: Anyone an idea about the licence for JMS JNDI redistribution? we cannot redistribute those. but you could have a build.xml in the block and get them from ibiblio's maven repository. Damn. I was afraid you'd say this. It's just that the Sun license for them has some limited redistribution addition and the OpenJMS project does distribute them (even without including a license file for them). well, if somebody is not careful about legal issues, it doesn't mean that we shouldn't be as well, don't you think? Looks like I need to look into this local build file thing :-| Life could be so easy. yeah, don't tell me! jakarta basically was created to route around those legal limitations for the sun license on the servlet API. but sun is still asking for redistributors to defend them in court in case somebody sues them thru software that you have redistributed. rare and stupid eventuality, I agree, but the ibiblio maven repository was created exactly to round around those issues. -- Stefano.
Re: cvs commit: cocoon-2.1/lib jars.xml
Stefano Mazzocchi wrote: On Tuesday, Oct 14, 2003, at 18:40 Europe/Rome, [EMAIL PROTECTED] wrote: haul2003/10/14 09:40:09 Modified:.blocks.properties gump.xml lib jars.xml Added: src/blocks/jms/samples sitemap.xmap src/blocks/jms/samples/database access-error.xml eventcache.xsp install.xsp invalidated.xml remove.xsp sitemap.xmap src/blocks/jms/java/org/apache/cocoon/samples/jms HTTPTrigger.java JMSTrigger.java src/blocks/jms/java/org/apache/cocoon/components/jms JMSConnection.java JMSConnectionImpl.java JMSEventListener.java JMSPublisherAction.java src/blocks/jms/conf jms.xsamples jmsconnection.xconf jmslistener.xconf Log: Start of an JMS block. Goes together with the eventcache block. Default: excluded Anyone an idea about the licence for JMS JNDI redistribution? we cannot redistribute those. but you could have a build.xml in the block and get them from ibiblio's maven repository. Neither JMS or JNDI are available on ibiblio (because of the Sun license restrictions). However, the license does allow distribution as part of another application. In Merlin there is a bar file (block archive) that represents a deployment unit. For example - the james-server.bar contains deployment descriptors along with Sun's activation.jar and mail-1.3.1.jar. On installation of a bar file these resources are unpacked relative to the a application group (i.e. they are not shared because the license under which thay are provided restricts usage to the application the jar is bundled with. Stephen. -- Stefano. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
Re: cvs commit: cocoon-2.1/lib jars.xml
Geoff Howard wrote:
Christian Haul wrote:
Stefano Mazzocchi wrote:
On Tuesday, Oct 14, 2003, at 18:40 Europe/Rome, [EMAIL PROTECTED] wrote:
Anyone an idea about the licence for JMS JNDI redistribution?
we cannot redistribute those. but you could have a build.xml in the
block and get them from ibiblio's maven repository.
Damn. I was afraid you'd say this. It's just that the Sun license for
them has some limited redistribution addition and the OpenJMS project
does distribute them (even without including a license file for them).
Looks like I need to look into this local build file thing :-| Life
could be so easy.
Will ant's get task work?
google gave me this example:
get dest=${libdir}/picocontainer-1.0-SNAPSHOT.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven//picocontainer/jars/picocontainer-1.0-SNAPSHOT.jar;
/get
But a browse around ibiblio reveals:
http://www.ibiblio.org/maven/jms/
http://www.ibiblio.org/maven/jndi/
exist but don't have any jars.
And looks like Stephen knows why - I had assumed ASF was being
conservative (wisely, I assume) and that ibiblio would be able to
redistribute.
I guess the best bet would be to grab the openjms package which contains
everything needed? Unless it can be automated we'll need some work on
the block to make sure it compiles and cocoon can start up without that
part. Not sure how to pull that off.
Chris, I'm really excited about this new work you've put in - it shows
the potential off beautifully.
Now I've got to go look at the code!
Geoff
Re: cvs commit: cocoon-2.1/lib jars.xml
Geoff Howard wrote: Geoff Howard wrote: But a browse around ibiblio reveals: http://www.ibiblio.org/maven/jms/ http://www.ibiblio.org/maven/jndi/ exist but don't have any jars. And looks like Stephen knows why - I had assumed ASF was being conservative (wisely, I assume) and that ibiblio would be able to redistribute. The ibiblio site is no different from Apache with respect to license obligations. When the Maven project started its bid to TLP is basically had to clean up its act bacause the content on ibiblio would by implication be resource managed by an Apache PMC - i.e. due-diligence required. The Maven guys went though a process of cleaning up the content on ibiblio.org/maven and the result of the cleanup is the missing jar files. I guess the best bet would be to grab the openjms package which contains everything needed? Unless it can be automated we'll need some work on the block to make sure it compiles and cocoon can start up without that part. Not sure how to pull that off. One approach you may want to consider is to package the content into a bar file, register the bar in cvs, add an ant task to download and expand the bar, and invoke bar expansion in the build. Providing you access the resources via a local repository, you are respecting the Sun licensing conditions because your accessing the resources relative to a particular application context that has a legal usage engagement. What this means is that whoever packages the jms libraries (or whowever accepts responsibilioty for the packaging) agrees to represent Sun should a problem arise. If the bar contribution to Cocoon is by a committer covered by a CLA, then the responsibility for the application usage rests with Apache. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
