You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlbeans-dev@xml.apache.org by Steven Noels <st...@outerthought.org> on 2004/02/12 11:19:45 UTC
Re: jaxen in xmlbeans cvs (was RE: distributing scripting code)
[moving from the licensing list to xmlbeans-dev, cc my dear friends of
the Cocoon PMC]
On 12 Feb 2004, at 09:45, Cliff Schmidt asked whether and how to
include Jaxen into XMLBeans:
> Since we don't need to modify the source, but we'd like it to
> be available in the xmlbeans distribution, only the binary is
> required. However, I'd think that we'd always want to include
> the source of anything distributed through Apache.
>
> So, I guess my answer is both (or just the source and we can
> include jaxen in the build process if that makes a difference.)
This is getting slightly off-topic, since Jaxen has an ASL-like license
so you can do either way.
Still, I think, even though the Cocoon community has been receiving
similar requests from our users community lately, to embed source
copies of the libraries we depend on (and there's a lot of them), that
dependencies shouldn't be added in source code form to the embedding
project's CVS and distribution, since it might create an additional
risk of "forkage", stale source code copies, and license
misinterpretation from XMLBeans users and developers.
I would add a released version of the Jaxen distribution jar to
XMLBeans, make sure you include a copy of the Jaxen license in
XMLBeans' CVS, and make ample reference to Jaxen's homebase on
codehaus.
The broader issue is that Cocoon is sometimes forced to include CVS
snapshot builds of libraries rather than real releases, because of bug
fixes, or the embedded project being even slower on releasing stuff
than we are ourselves. ;-)
Cocoon users complain about this since including our own binary builds
of libararies makes it difficult for them to obtain the source code of
these libraries without "cvs -D date" hackery. Oftentimes, they don't
have CVS access because of company firewall settings.
We have been "friendly ignoring" these complaints so far - although we
are aware of the troubles this can cause - because we don't know how we
should handle this otherwise. We try to stick to point releases of
libraries as much as possible of course, and the naming convention of
our handrolled library dependencies indicate that the date of
compilation needs to be included in the filename (i.e.
rhino1.5r4-continuations-20030906.jar, or
excalibur-store-20031211.jar).
HTH,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: jaxen in xmlbeans cvs (was RE: distributing scripting code)
Posted by Brian McCallister <mc...@forthillcompany.com>.
I would argue for going ahead and distributing a source tarball (or
jar) of non-release third party libs. If it is a released version
politely ignoring is appropriate =)
-Brian
On Feb 12, 2004, at 5:19 AM, Steven Noels wrote:
> [moving from the licensing list to xmlbeans-dev, cc my dear friends of
> the Cocoon PMC]
>
> On 12 Feb 2004, at 09:45, Cliff Schmidt asked whether and how to
> include Jaxen into XMLBeans:
>
>> Since we don't need to modify the source, but we'd like it to
>> be available in the xmlbeans distribution, only the binary is
>> required. However, I'd think that we'd always want to include
>> the source of anything distributed through Apache.
>>
>> So, I guess my answer is both (or just the source and we can
>> include jaxen in the build process if that makes a difference.)
>
> This is getting slightly off-topic, since Jaxen has an ASL-like
> license so you can do either way.
>
> Still, I think, even though the Cocoon community has been receiving
> similar requests from our users community lately, to embed source
> copies of the libraries we depend on (and there's a lot of them), that
> dependencies shouldn't be added in source code form to the embedding
> project's CVS and distribution, since it might create an additional
> risk of "forkage", stale source code copies, and license
> misinterpretation from XMLBeans users and developers.
>
> I would add a released version of the Jaxen distribution jar to
> XMLBeans, make sure you include a copy of the Jaxen license in
> XMLBeans' CVS, and make ample reference to Jaxen's homebase on
> codehaus.
>
> The broader issue is that Cocoon is sometimes forced to include CVS
> snapshot builds of libraries rather than real releases, because of bug
> fixes, or the embedded project being even slower on releasing stuff
> than we are ourselves. ;-)
>
> Cocoon users complain about this since including our own binary builds
> of libararies makes it difficult for them to obtain the source code of
> these libraries without "cvs -D date" hackery. Oftentimes, they don't
> have CVS access because of company firewall settings.
>
> We have been "friendly ignoring" these complaints so far - although we
> are aware of the troubles this can cause - because we don't know how
> we should handle this otherwise. We try to stick to point releases of
> libraries as much as possible of course, and the naming convention of
> our handrolled library dependencies indicate that the date of
> compilation needs to be included in the filename (i.e.
> rhino1.5r4-continuations-20030906.jar, or
> excalibur-store-20031211.jar).
>
> HTH,
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source Java & XML An Orixo Member
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: jaxen in xmlbeans cvs (was RE: distributing scripting code)
Posted by Brian McCallister <mc...@forthillcompany.com>.
I would argue for going ahead and distributing a source tarball (or
jar) of non-release third party libs. If it is a released version
politely ignoring is appropriate =)
-Brian
On Feb 12, 2004, at 5:19 AM, Steven Noels wrote:
> [moving from the licensing list to xmlbeans-dev, cc my dear friends of
> the Cocoon PMC]
>
> On 12 Feb 2004, at 09:45, Cliff Schmidt asked whether and how to
> include Jaxen into XMLBeans:
>
>> Since we don't need to modify the source, but we'd like it to
>> be available in the xmlbeans distribution, only the binary is
>> required. However, I'd think that we'd always want to include
>> the source of anything distributed through Apache.
>>
>> So, I guess my answer is both (or just the source and we can
>> include jaxen in the build process if that makes a difference.)
>
> This is getting slightly off-topic, since Jaxen has an ASL-like
> license so you can do either way.
>
> Still, I think, even though the Cocoon community has been receiving
> similar requests from our users community lately, to embed source
> copies of the libraries we depend on (and there's a lot of them), that
> dependencies shouldn't be added in source code form to the embedding
> project's CVS and distribution, since it might create an additional
> risk of "forkage", stale source code copies, and license
> misinterpretation from XMLBeans users and developers.
>
> I would add a released version of the Jaxen distribution jar to
> XMLBeans, make sure you include a copy of the Jaxen license in
> XMLBeans' CVS, and make ample reference to Jaxen's homebase on
> codehaus.
>
> The broader issue is that Cocoon is sometimes forced to include CVS
> snapshot builds of libraries rather than real releases, because of bug
> fixes, or the embedded project being even slower on releasing stuff
> than we are ourselves. ;-)
>
> Cocoon users complain about this since including our own binary builds
> of libararies makes it difficult for them to obtain the source code of
> these libraries without "cvs -D date" hackery. Oftentimes, they don't
> have CVS access because of company firewall settings.
>
> We have been "friendly ignoring" these complaints so far - although we
> are aware of the troubles this can cause - because we don't know how
> we should handle this otherwise. We try to stick to point releases of
> libraries as much as possible of course, and the naming convention of
> our handrolled library dependencies indicate that the date of
> compilation needs to be included in the filename (i.e.
> rhino1.5r4-continuations-20030906.jar, or
> excalibur-store-20031211.jar).
>
> HTH,
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source Java & XML An Orixo Member
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/