You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2003/06/01 18:14:56 UTC
[math] maven magic and build.xml -- how to get ant build working again
Our ant build (and hence nightly) is currently broken, since we have
added dependencies on commons-beanutils, bringing along collections and
logging. I personally have moved to maven entirely, but I thought we
had agreed early on that we would maintain the ability to build from
ant. Also, Craig pointed out that if we want nightly builds, we need to
have a working build.xml.
I see two ways to handle this:
1. Run maven ant:generate-build and replace build.xml with the result.
This will add a get-deps target telling ant to grab the jars from
ibiblio.org -- e.g.,
<get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true"
ignoreerrors="true"
src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar">
</get>
This works for me from the command line; but something tells me the
nightly build might not like it and I have no idea whether or not the
whole script has some hidden dependencies on maven.
2. Modify build.xml and build.properties.sample to include
commons-lib.home, commons-beanutils.jar, commons-logging.jar and
commons-collections.jar properties and expect the user (or bot) to fill
these in, grab the jars and put them in the specified directories.
The advantage of 1. is that it guarantees that builds from maven and ant
use the same jars. The advantage of 2 is that build.xml is simpler and
more standard.
What are other maven-based projects doing to handle this?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] maven magic and build.xml -- how to get ant build working
again
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 1 Jun 2003, Phil Steitz wrote:
> Date: Sun, 01 Jun 2003 10:17:41 -0700
> From: Phil Steitz <ph...@steitz.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [math] maven magic and build.xml -- how to get ant build
> working again
>
> Mark R. Diggory wrote:
> > Yes, big +1, Right now the dependencies in the cvs'd project.xml are not
> > fleshed out for beanutils and junit
>
> I think project.xml is OK, between this and jakarta-commons/project.xml
> everything necessary is there. We should probably indicate somewhere in
> our developer notes that you need to grab jakarta-commons/project.xml
> and put it in ../jakarta-commons. Maven will croak with strange errors
> if this file is missing.
>
> > I suspect junit also needs to also
> > be there for the "test" target to work properly in Ant even thought its
> > available in mavens lib dir, people using Ant are not using maven and
> > the generated build.xml needs to get junit.
> >
> It does, but the generated build.xml grabs it as well.
>
Don't forget to check in the generated build.xml file ... CVS still has
version 1.3 from May 18.
> > -Mark
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] maven magic and build.xml -- how to get ant build working again
Posted by Phil Steitz <ph...@steitz.com>.
Mark R. Diggory wrote:
> Yes, big +1, Right now the dependencies in the cvs'd project.xml are not
> fleshed out for beanutils and junit
I think project.xml is OK, between this and jakarta-commons/project.xml
everything necessary is there. We should probably indicate somewhere in
our developer notes that you need to grab jakarta-commons/project.xml
and put it in ../jakarta-commons. Maven will croak with strange errors
if this file is missing.
> I suspect junit also needs to also
> be there for the "test" target to work properly in Ant even thought its
> available in mavens lib dir, people using Ant are not using maven and
> the generated build.xml needs to get junit.
>
It does, but the generated build.xml grabs it as well.
> -Mark
>
> Phil Steitz wrote:
>
>> Our ant build (and hence nightly) is currently broken, since we have
>> added dependencies on commons-beanutils, bringing along collections
>> and logging. I personally have moved to maven entirely, but I thought
>> we had agreed early on that we would maintain the ability to build
>> from ant. Also, Craig pointed out that if we want nightly builds, we
>> need to have a working build.xml.
>>
>> I see two ways to handle this:
>>
>> 1. Run maven ant:generate-build and replace build.xml with the result.
>>
>> This will add a get-deps target telling ant to grab the jars from
>> ibiblio.org -- e.g.,
>>
>> <get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true"
>> ignoreerrors="true"
>> src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar">
>>
>> </get>
>>
>> This works for me from the command line; but something tells me the
>> nightly build might not like it and I have no idea whether or not the
>> whole script has some hidden dependencies on maven.
>>
>> 2. Modify build.xml and build.properties.sample to include
>> commons-lib.home, commons-beanutils.jar, commons-logging.jar and
>> commons-collections.jar properties and expect the user (or bot) to
>> fill these in, grab the jars and put them in the specified directories.
>>
>> The advantage of 1. is that it guarantees that builds from maven and
>> ant use the same jars. The advantage of 2 is that build.xml is
>> simpler and more standard.
>>
>> What are other maven-based projects doing to handle this?
>>
>> Phil
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] maven magic and build.xml -- how to get ant build working
again
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Yes, big +1, Right now the dependencies in the cvs'd project.xml are not
fleshed out for beanutils and junit, I suspect junit also needs to also
be there for the "test" target to work properly in Ant even thought its
available in mavens lib dir, people using Ant are not using maven and
the generated build.xml needs to get junit.
-Mark
Phil Steitz wrote:
> Our ant build (and hence nightly) is currently broken, since we have
> added dependencies on commons-beanutils, bringing along collections and
> logging. I personally have moved to maven entirely, but I thought we
> had agreed early on that we would maintain the ability to build from
> ant. Also, Craig pointed out that if we want nightly builds, we need to
> have a working build.xml.
>
> I see two ways to handle this:
>
> 1. Run maven ant:generate-build and replace build.xml with the result.
>
> This will add a get-deps target telling ant to grab the jars from
> ibiblio.org -- e.g.,
>
> <get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true"
> ignoreerrors="true"
> src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar">
>
> </get>
>
> This works for me from the command line; but something tells me the
> nightly build might not like it and I have no idea whether or not the
> whole script has some hidden dependencies on maven.
>
> 2. Modify build.xml and build.properties.sample to include
> commons-lib.home, commons-beanutils.jar, commons-logging.jar and
> commons-collections.jar properties and expect the user (or bot) to fill
> these in, grab the jars and put them in the specified directories.
>
> The advantage of 1. is that it guarantees that builds from maven and ant
> use the same jars. The advantage of 2 is that build.xml is simpler and
> more standard.
>
> What are other maven-based projects doing to handle this?
>
> Phil
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] maven magic and build.xml -- how to get ant build working
again
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Phil, I just made/tested the same changes on my checkout. I can commit
these for you and save you some time.
-Mark
Phil Steitz wrote:
> Craig R. McClanahan wrote:
>
>>
>> On Sun, 1 Jun 2003, Phil Steitz wrote:
>>
>>
>>> Date: Sun, 01 Jun 2003 09:14:56 -0700
>>> From: Phil Steitz <ph...@steitz.com>
>>> Reply-To: Jakarta Commons Developers List
>>> <co...@jakarta.apache.org>
>>> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>> Subject: [math] maven magic and build.xml -- how to get ant build
>>> working
>>> again
>>>
>>> Our ant build (and hence nightly) is currently broken, since we have
>>> added dependencies on commons-beanutils, bringing along collections and
>>> logging. I personally have moved to maven entirely, but I thought we
>>> had agreed early on that we would maintain the ability to build from
>>> ant. Also, Craig pointed out that if we want nightly builds, we need to
>>> have a working build.xml.
>>>
>>> I see two ways to handle this:
>>>
>>> 1. Run maven ant:generate-build and replace build.xml with the result.
>>>
>>> This will add a get-deps target telling ant to grab the jars from
>>> ibiblio.org -- e.g.,
>>>
>>> <get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true"
>>> ignoreerrors="true"
>>> src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar">
>>>
>>> </get>
>>>
>>> This works for me from the command line; but something tells me the
>>> nightly build might not like it and I have no idea whether or not the
>>> whole script has some hidden dependencies on maven.
>>>
>>
>>
>> Commons-FileUpload (among others) has a build.xml generated by Maven, and
>> it seems to run fine for the nightly builds. As long as the "clean" and
>> "dist" targets can be generated, and the output of the "dist" target goes
>> in to a "dist" subdirectory, Maven-generated build files should be ok.
>>
>>
>>> 2. Modify build.xml and build.properties.sample to include
>>> commons-lib.home, commons-beanutils.jar, commons-logging.jar and
>>> commons-collections.jar properties and expect the user (or bot) to fill
>>> these in, grab the jars and put them in the specified directories.
>>>
>>> The advantage of 1. is that it guarantees that builds from maven and ant
>>> use the same jars. The advantage of 2 is that build.xml is simpler and
>>> more standard.
>>>
>>> What are other maven-based projects doing to handle this?
>>>
>>
>>
>> I'd definitely go with option 1 -- that way, you don't have to manually
>> keep the two in sync. Just regenerate the build.xml when dependencies
>> are
>> changed.
>>
>>
>>
>>> Phil
>>
>>
>>
>> Craig
>>
>
>
> Thanks, Craig.
>
> I will submit a patch.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] maven magic and build.xml -- how to get ant build working again
Posted by Phil Steitz <ph...@steitz.com>.
Craig R. McClanahan wrote:
>
> On Sun, 1 Jun 2003, Phil Steitz wrote:
>
>
>>Date: Sun, 01 Jun 2003 09:14:56 -0700
>>From: Phil Steitz <ph...@steitz.com>
>>Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>Subject: [math] maven magic and build.xml -- how to get ant build working
>> again
>>
>>Our ant build (and hence nightly) is currently broken, since we have
>>added dependencies on commons-beanutils, bringing along collections and
>>logging. I personally have moved to maven entirely, but I thought we
>>had agreed early on that we would maintain the ability to build from
>>ant. Also, Craig pointed out that if we want nightly builds, we need to
>>have a working build.xml.
>>
>>I see two ways to handle this:
>>
>>1. Run maven ant:generate-build and replace build.xml with the result.
>>
>>This will add a get-deps target telling ant to grab the jars from
>>ibiblio.org -- e.g.,
>>
>><get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true"
>>ignoreerrors="true"
>>src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar">
>></get>
>>
>>This works for me from the command line; but something tells me the
>>nightly build might not like it and I have no idea whether or not the
>>whole script has some hidden dependencies on maven.
>>
>
>
> Commons-FileUpload (among others) has a build.xml generated by Maven, and
> it seems to run fine for the nightly builds. As long as the "clean" and
> "dist" targets can be generated, and the output of the "dist" target goes
> in to a "dist" subdirectory, Maven-generated build files should be ok.
>
>
>>2. Modify build.xml and build.properties.sample to include
>>commons-lib.home, commons-beanutils.jar, commons-logging.jar and
>>commons-collections.jar properties and expect the user (or bot) to fill
>>these in, grab the jars and put them in the specified directories.
>>
>>The advantage of 1. is that it guarantees that builds from maven and ant
>>use the same jars. The advantage of 2 is that build.xml is simpler and
>>more standard.
>>
>>What are other maven-based projects doing to handle this?
>>
>
>
> I'd definitely go with option 1 -- that way, you don't have to manually
> keep the two in sync. Just regenerate the build.xml when dependencies are
> changed.
>
>
>
>>Phil
>
>
> Craig
>
Thanks, Craig.
I will submit a patch.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] maven magic and build.xml -- how to get ant build working
again
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 1 Jun 2003, Phil Steitz wrote:
> Date: Sun, 01 Jun 2003 09:14:56 -0700
> From: Phil Steitz <ph...@steitz.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [math] maven magic and build.xml -- how to get ant build working
> again
>
> Our ant build (and hence nightly) is currently broken, since we have
> added dependencies on commons-beanutils, bringing along collections and
> logging. I personally have moved to maven entirely, but I thought we
> had agreed early on that we would maintain the ability to build from
> ant. Also, Craig pointed out that if we want nightly builds, we need to
> have a working build.xml.
>
> I see two ways to handle this:
>
> 1. Run maven ant:generate-build and replace build.xml with the result.
>
> This will add a get-deps target telling ant to grab the jars from
> ibiblio.org -- e.g.,
>
> <get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true"
> ignoreerrors="true"
> src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar">
> </get>
>
> This works for me from the command line; but something tells me the
> nightly build might not like it and I have no idea whether or not the
> whole script has some hidden dependencies on maven.
>
Commons-FileUpload (among others) has a build.xml generated by Maven, and
it seems to run fine for the nightly builds. As long as the "clean" and
"dist" targets can be generated, and the output of the "dist" target goes
in to a "dist" subdirectory, Maven-generated build files should be ok.
> 2. Modify build.xml and build.properties.sample to include
> commons-lib.home, commons-beanutils.jar, commons-logging.jar and
> commons-collections.jar properties and expect the user (or bot) to fill
> these in, grab the jars and put them in the specified directories.
>
> The advantage of 1. is that it guarantees that builds from maven and ant
> use the same jars. The advantage of 2 is that build.xml is simpler and
> more standard.
>
> What are other maven-based projects doing to handle this?
>
I'd definitely go with option 1 -- that way, you don't have to manually
keep the two in sync. Just regenerate the build.xml when dependencies are
changed.
> Phil
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] matters of copyright
Posted by Phil Steitz <ph...@steitz.com>.
Tim O'Brien wrote:
> Gamma.java specifically mentioned that is was based on "Numerical
> Recipes in C" which is not available under a license compatible with the
> ASL. All code currently in [math] which depends on Gamma.java has been
> removed. If it can be shown that this code does not violate the
> copyright maintained by NR, then I'll *gladly* and *quickly* reverse
> this action. This isn't meant to discourage contribution of any
> individual.
>
> http://www.nr.com/com/info-copyright.html - Information pertaining to NR
> copyright. http://www.nr.com/infotop.html - Restrictions on "commercial
> use"
>
> Here are some proposed guidelines for [math] to help us avoid this
> situation in the future:
>
> 1. Patches must be accompanied by a clear reference to a "source" - if
> code has been "ported" from another language, clearly state the source
> of the original implementation. If the "expression" of a given
> algorithm is derivative, please note the original source (textbook,
> paper, etc.).
>
> 2. References to source materials covered by restrictive proprietary
> licenses should be avoided.
+1 I have adding these to a new subsection called 'Licensing and
copyright' under Guidlines in the developer.xml patch that I posted
earlier today and have now submitted here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=20404
The full text of the original plus the new section now reads:
Guidelines
Developers are asked to comply with the following development
guidelines. Code that does not comply with the guidelines including the
word must will not be committed. Our aim will be to fix all of the
exceptions to the " should " guidelines prior to a release.
Coding Style
Commons-math follows Code Conventions for the Java Programming Language
.<hypertext link> As part of the maven build process, style checking is
performed using the checkStyle plugin, using the properties specified in
checkStyle.properties . Committed code should generate no checkStyle errors.
Documentation
* Committed code must include full javadoc.
* All component contracts must be fully specified in the javadoc class,
interface or method comments, including specification of acceptable
ranges of values, exceptions or special return values.
* References to definitions for all mathematical terms used in component
documentation must be provided, preferably as HTML links.
* Implementations should use standard algorithms and references to
algorithm descriptions should be provided, preferably as HTML links.
Unit Tests
* Committed code must include unit tests.
* Unit tests should provide full path coverage.
* Unit tests should verify all boundary conditions specified in
interface contracts, including verification that exceptions are thrown
or special values (e.g. Double.NaN, Double.Infinity) are returned as
expected.
Licensing and copyright
* All new source file submissions must include the Apache Software
License in a comment that begins the file
* All contributions must comply with the terms of the Apache Contributor
License Agreement (CLA) <hypertext link>
* Patches must be accompanied by a clear reference to a "source" - if
code has been "ported" from another language, clearly state the source
of the original implementation. If the "expression" of a given algorithm
is derivative, please note the original source (textbook, paper, etc.).
* References to source materials covered by restrictive proprietary
licenses should be avoided.
>
> IMHO, commons-math should not be currently concerned with porting
> existing code or utilities - we're looking to create a simple, compact
> package which provides basic functionality not available in the core
> J2SE distribution. This package should also look to provide a few
> differentiators - (tight integration with beanutils, collections,
> digester, betwixt).
I agree here as well.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] matters of copyright
Posted by Al Chou <ho...@yahoo.com>.
--- "J.Pietschmann" <j3...@yahoo.de> wrote:
> The site
> http://yacas.sourceforge.net/Algomanual.html
> may be interesting in this context, in particular
> http://yacas.sourceforge.net/Algochapter6.html
>
> The software is GPL but maybe they'll even agree to
> lifting some code from them...
I came across that project a few days ago when I was looking for the Web page
about famous constants. Skimming the manual, it looks like YACAS implements
Mathematica's syntax and capabilities, using Lisp. Very interesting, but not
obvious how we would use anything from it.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] matters of copyright
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: Wednesday, June 11, 2003 4:00 PM
> To: Jakarta Commons Developers List
> Subject: Re: [math] matters of copyright
>
>
> The site
> http://yacas.sourceforge.net/Algomanual.html
> may be interesting in this context, in particular
> http://yacas.sourceforge.net/Algochapter6.html
>
> The software is GPL but maybe they'll even agree to
> lifting some code from them...
>
> J.Pietschmann
>
Also, here's a public domain library containing some matrix routines:
http://math.nist.gov/javanumerics/jama/
We might want to borrow a linear systems solver from here.
Brent Worden
http://www.brent.worden.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] matters of copyright
Posted by "J.Pietschmann" <j3...@yahoo.de>.
The site
http://yacas.sourceforge.net/Algomanual.html
may be interesting in this context, in particular
http://yacas.sourceforge.net/Algochapter6.html
The software is GPL but maybe they'll even agree to
lifting some code from them...
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] matters of copyright
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Monday, June 2, 2003, at 07:54 AM, Phil Steitz wrote:
> Brent Worden wrote:
>>> Gamma.java specifically mentioned that is was based on "Numerical
>>> Recipes in C" which is not available under a license compatible with the
>>> ASL.
>> What is specifically mentioned was "is based on the formulas and
>> descriptions" found in NR and it clearly states in
>> http://www.nr.com/com/info-copyright.html that "Of course, the
>> mathematical
>> algorithms that underly the programs are not copyrightable..."
>
> This is a good point. The full text of the paragraph that starts with
> that sentence is:
>
> "Of course, the mathematical algorithms that underly the programs are not
> copyrightable. So, the test of whether a similar program is actually
> infringing on the Numerical Recipes copyright is whether the expression
> of the underlying algorithm is so similar to that in Numerical Recipes as
> to make clear that the infringing program was in fact derived from the
> Numerical Recipes program. It is usually very easy to tell if something
> was copied from Numerical Recipes, even if variable names are changed
> (for example), since all programs are full of arbitrary stylistic choices
> as to the order in which things are done, the way expressions are written,
> etc."
>
> I am not a lawyer and I have learned that lawyers often see things very
> differently than I do, but to me it looks like as long as all we are
> using are the formulas in NR, we *might* be OK, as long as:
>
> * "our" implementation does not end up looking like it was "derived from
> the NR program"
> * the formulas that we use are part of the "mathematical algorithms"
> rather than part of the "expression of the algorithms"
>
> The best situation,IMHO, is to have non-NR references that describe the
> algorithms. If NR itself provides these, we should refer to the original
> source (cf earlier discussion of corrected mean computations). I would
> suggest that given the potential legal entanglements, we should try to
> avoid formulas or algorithms that we can find *only* in NR.
IMHO
AIUI the critical point is whether the encoded algorithm (rather than the
mathematics behind it) is a clean room implementation or not but i would
certainly say that we should certainly try to provide a number of
references. providing only one reference should certainly be a danger sign.
what concerns me is not the references (copyright would be equally
infringed whether we include a reference or not) but that we're going to
have to be very careful about ensuring that (as far as is possible)
contributions are are not simply rewriting or derivative works of
protected algorithmic code. we should have the java and mathematics here
to provide clean room implementations for mathematical algorithms (if
these are needed) but we're going to need help from the good folks out
there who know the most common implementations (you know who you are!) to
ensure that we can spot any problems as quickly as possible. we should
probably make some sort of effort to audit all new implementations before
each release.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] matters of copyright
Posted by Phil Steitz <ph...@steitz.com>.
Brent Worden wrote:
>>Gamma.java specifically mentioned that is was based on "Numerical
>>Recipes in C" which is not available under a license compatible with the
>>ASL.
>
>
> What is specifically mentioned was "is based on the formulas and
> descriptions" found in NR and it clearly states in
> http://www.nr.com/com/info-copyright.html that "Of course, the mathematical
> algorithms that underly the programs are not copyrightable..."
This is a good point. The full text of the paragraph that starts with
that sentence is:
"Of course, the mathematical algorithms that underly the programs are
not copyrightable. So, the test of whether a similar program is actually
infringing on the Numerical Recipes copyright is whether the expression
of the underlying algorithm is so similar to that in Numerical Recipes
as to make clear that the infringing program was in fact derived from
the Numerical Recipes program. It is usually very easy to tell if
something was copied from Numerical Recipes, even if variable names are
changed (for example), since all programs are full of arbitrary
stylistic choices as to the order in which things are done, the way
expressions are written, etc."
I am not a lawyer and I have learned that lawyers often see things very
differently than I do, but to me it looks like as long as all we are
using are the formulas in NR, we *might* be OK, as long as:
* "our" implementation does not end up looking like it was "derived from
the NR program"
* the formulas that we use are part of the "mathematical algorithms"
rather than part of the "expression of the algorithms"
The best situation,IMHO, is to have non-NR references that describe the
algorithms. If NR itself provides these, we should refer to the original
source (cf earlier discussion of corrected mean computations). I would
suggest that given the potential legal entanglements, we should try to
avoid formulas or algorithms that we can find *only* in NR.
Phil
>
> 1) logGamma is derived using (6.1.3) and (6.1.5) from NR and the Paul
> Godfrey's paper on Lanczos coefficients found at
> http://my.fit.edu/~gabdo/gamma.txt.
>
> 2) regularizedGammaP is derived using (6.2.1) and (6.2.5) from NR. I also
> have hand-written notes on how I derived the implementation from those
> formulas that I would be happy to provide for your viewing.
>
> 3) ChiSquaredDistribution and GammaDistribution are based on (6.2.1) and
> (6.2.18) from NR and the fact that ChiSquared(v) ~ Gamma(v/2, 2) which can
> be found in Casella and Berger.
>
> The t-distribution patch has several modifications to the comments of all
> the mentioned classes with links to all the cited material.
>
> Also, the t patch makes use of other mathematical algorithms found in NR.
>
> A) The continued fraction class is based on (5.2.1) and the modified Lentz
> algorithm defined in that same section and accredited to Thompson and
> Barnett.
>
> B) logGamma uses the cf class and (6.2.7) from NR to provide better
> convergence than the series.
>
> C) logBeta uses (6.1.9) from NR.
>
> D) regularizedBeta is derived using the cf class and (6.4.1), (6.4.5) and
> (6.4.6) from NR.
>
> E) TDistribution is based on (6.4.9) from NR.
>
> Brent Worden
> http://www.brent.worden.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] matters of copyright
Posted by Brent Worden <br...@worden.org>.
>
> Gamma.java specifically mentioned that is was based on "Numerical
> Recipes in C" which is not available under a license compatible with the
> ASL.
What is specifically mentioned was "is based on the formulas and
descriptions" found in NR and it clearly states in
http://www.nr.com/com/info-copyright.html that "Of course, the mathematical
algorithms that underly the programs are not copyrightable..."
1) logGamma is derived using (6.1.3) and (6.1.5) from NR and the Paul
Godfrey's paper on Lanczos coefficients found at
http://my.fit.edu/~gabdo/gamma.txt.
2) regularizedGammaP is derived using (6.2.1) and (6.2.5) from NR. I also
have hand-written notes on how I derived the implementation from those
formulas that I would be happy to provide for your viewing.
3) ChiSquaredDistribution and GammaDistribution are based on (6.2.1) and
(6.2.18) from NR and the fact that ChiSquared(v) ~ Gamma(v/2, 2) which can
be found in Casella and Berger.
The t-distribution patch has several modifications to the comments of all
the mentioned classes with links to all the cited material.
Also, the t patch makes use of other mathematical algorithms found in NR.
A) The continued fraction class is based on (5.2.1) and the modified Lentz
algorithm defined in that same section and accredited to Thompson and
Barnett.
B) logGamma uses the cf class and (6.2.7) from NR to provide better
convergence than the series.
C) logBeta uses (6.1.9) from NR.
D) regularizedBeta is derived using the cf class and (6.4.1), (6.4.5) and
(6.4.6) from NR.
E) TDistribution is based on (6.4.9) from NR.
Brent Worden
http://www.brent.worden.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math] matters of copyright
Posted by Tim O'Brien <to...@discursive.com>.
Gamma.java specifically mentioned that is was based on "Numerical
Recipes in C" which is not available under a license compatible with the
ASL. All code currently in [math] which depends on Gamma.java has been
removed. If it can be shown that this code does not violate the
copyright maintained by NR, then I'll *gladly* and *quickly* reverse
this action. This isn't meant to discourage contribution of any
individual.
http://www.nr.com/com/info-copyright.html - Information pertaining to NR
copyright. http://www.nr.com/infotop.html - Restrictions on "commercial
use"
Here are some proposed guidelines for [math] to help us avoid this
situation in the future:
1. Patches must be accompanied by a clear reference to a "source" - if
code has been "ported" from another language, clearly state the source
of the original implementation. If the "expression" of a given
algorithm is derivative, please note the original source (textbook,
paper, etc.).
2. References to source materials covered by restrictive proprietary
licenses should be avoided.
IMHO, commons-math should not be currently concerned with porting
existing code or utilities - we're looking to create a simple, compact
package which provides basic functionality not available in the core
J2SE distribution. This package should also look to provide a few
differentiators - (tight integration with beanutils, collections,
digester, betwixt).
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] maven magic and build.xml -- how to get ant build working
again
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I've committed a Maven Generated version of build.xml. We should see
this evening if the automated build process is successfully with the
added dependencies, I've tested it from the command line on my machine
with success.
With this the case build.properties.sample is no longer relevant, I am
tempted to remove or alter its contents to more accurately represent
what can be set. I suspect this could contain examples of how to set the
location of the lib directory among other things.
-Mark
Phil Steitz wrote:
> Our ant build (and hence nightly) is currently broken, since we have
> added dependencies on commons-beanutils, bringing along collections and
> logging. I personally have moved to maven entirely, but I thought we
> had agreed early on that we would maintain the ability to build from
> ant. Also, Craig pointed out that if we want nightly builds, we need to
> have a working build.xml.
>
> I see two ways to handle this:
>
> 1. Run maven ant:generate-build and replace build.xml with the result.
>
> This will add a get-deps target telling ant to grab the jars from
> ibiblio.org -- e.g.,
>
> <get dest="${libdir}/commons-beanutils-1.5.jar" usetimestamp="true"
> ignoreerrors="true"
> src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar">
>
> </get>
>
> This works for me from the command line; but something tells me the
> nightly build might not like it and I have no idea whether or not the
> whole script has some hidden dependencies on maven.
>
> 2. Modify build.xml and build.properties.sample to include
> commons-lib.home, commons-beanutils.jar, commons-logging.jar and
> commons-collections.jar properties and expect the user (or bot) to fill
> these in, grab the jars and put them in the specified directories.
>
> The advantage of 1. is that it guarantees that builds from maven and ant
> use the same jars. The advantage of 2 is that build.xml is simpler and
> more standard.
>
> What are other maven-based projects doing to handle this?
>
> Phil
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org