You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Karl Wright <kw...@metacarta.com> on 2010/02/09 15:21:36 UTC

Ant builds

I'm looking at what is required for ant builds of LCF, and for this I sort of want to understand "accepted practices" for Apache 
builds of this kind.

(1) Structure

LCF will build many distinct jars, which need to be kept distinct because not all deployments can build or include all 
functionality.  So there will be, at minimum:

- A set of jars representing the framework itself
- A set of jars for each connector

I say a "set" here, because some components (e.g. the framework and the documentum connector) do in fact contain multiple 
sub-components.

The question is - do we want a single ant build for the whole thing?  Or independent ant builds for each major component?  Based 
on the way it's packaged in debian for MetaCarta, independent components would be better.  Is that acceptable?

(2) Dependencies

LCF requires upstream dependencies, many from apache, others from third parties such as postgresql.  The dependencies come in 
the following flavors:
- Sun dependency (standard jsp tag library jars and tlds: jstl.jar, standard.jar, sql.tld, c.tld, fmt.tld, x.tld, and servlet.jar)
- Apache dependency, unexceptional (commons-fileupload, commons-collections, commons-codec, commons-logging, log4j, axis, castor)
- Apache dependency, requiring upstream modifications in order to build properly (commons-httpclient, xerces2-java)
- LGPL dependency, possibly requiring upstream modifications in order to run properly (jcifs)
- LGPL dependency, not requiring upstream modifications in order to run properly (postgres jdbc driver)
- BSD jar dependency (Bitstream pool driver, jdbcpool-0.99.jar)
- Third party proprietary jars (not enumerated here)
- Dependencies which will be immediately removed (metacarta-license.jar)

I take it we'll just presume, for the purposes of ant, that the correctly generated jars are just dropped in the ant/lib area? 
What ant build strategy should we use for all of the above categories?

(3) Axis/castor build items

Connectors that build from wsdls or xsds use axis or castor to generate the appropriate java class code.  Is there a standard 
Apache ant task that we can use for these?

Thanks,
Karl

Re: Ant builds

Posted by Grant Ingersoll <gs...@apache.org>.
OK, I should be able to fill this out either tonight or tomorrow morning and get the clearance going.

On Feb 9, 2010, at 4:51 PM, Karl Wright wrote:

> Grant Ingersoll wrote:
>> On Feb 9, 2010, at 9:21 AM, Karl Wright wrote:
>>> I'm looking at what is required for ant builds of LCF, and for this I sort of want to understand "accepted practices" for Apache builds of this kind.
>>> 
>>> (1) Structure
>>> 
>>> LCF will build many distinct jars, which need to be kept distinct because not all deployments can build or include all functionality.  So there will be, at minimum:
>>> 
>>> - A set of jars representing the framework itself
>>> - A set of jars for each connector
>>> 
>>> I say a "set" here, because some components (e.g. the framework and the documentum connector) do in fact contain multiple sub-components.
>>> 
>>> The question is - do we want a single ant build for the whole thing?  Or independent ant builds for each major component?  Based on the way it's packaged in debian for MetaCarta, independent components would be better.  Is that acceptable?
>>> 
>>> (2) Dependencies
>>> 
>>> LCF requires upstream dependencies, many from apache, others from third parties such as postgresql.  The dependencies come in the following flavors:
>>> - Sun dependency (standard jsp tag library jars and tlds: jstl.jar, standard.jar, sql.tld, c.tld, fmt.tld, x.tld, and servlet.jar)
>> Do you know which Sun licenses?  There might be Apache equivalents here.
> 
> http://java.sun.com/products/jsp/jstl/
> 
> We actually may not need all or even any of these; they were originally part of the environment when much greater use of tags was contemplated.
> 
> servlet.jar

That one is fine, other projects ship that.

-Grant

Re: Ant builds

Posted by Karl Wright <kw...@metacarta.com>.
Grant Ingersoll wrote:
> On Feb 9, 2010, at 9:21 AM, Karl Wright wrote:
> 
>> I'm looking at what is required for ant builds of LCF, and for this I sort of want to understand "accepted practices" for Apache builds of this kind.
>>
>> (1) Structure
>>
>> LCF will build many distinct jars, which need to be kept distinct because not all deployments can build or include all functionality.  So there will be, at minimum:
>>
>> - A set of jars representing the framework itself
>> - A set of jars for each connector
>>
>> I say a "set" here, because some components (e.g. the framework and the documentum connector) do in fact contain multiple sub-components.
>>
>> The question is - do we want a single ant build for the whole thing?  Or independent ant builds for each major component?  Based on the way it's packaged in debian for MetaCarta, independent components would be better.  Is that acceptable?
>>
>> (2) Dependencies
>>
>> LCF requires upstream dependencies, many from apache, others from third parties such as postgresql.  The dependencies come in the following flavors:
>> - Sun dependency (standard jsp tag library jars and tlds: jstl.jar, standard.jar, sql.tld, c.tld, fmt.tld, x.tld, and servlet.jar)
> 
> Do you know which Sun licenses?  There might be Apache equivalents here.
> 

http://java.sun.com/products/jsp/jstl/

We actually may not need all or even any of these; they were originally part of the environment when much greater use of tags 
was contemplated.

servlet.jar

is also not a required dependency, although there is one in the debian distribution which is what we need to build jcifs with 
(package libservlet-2.3-java).  Should we actually need to run with it, there's an equivalent in tomcat.


>> - Apache dependency, unexceptional (commons-fileupload, commons-collections, commons-codec, commons-logging, log4j, axis, castor)

I missed one of these: poi.

>> - Apache dependency, requiring upstream modifications in order to build properly (commons-httpclient, xerces2-java)
>> - LGPL dependency, possibly requiring upstream modifications in order to run properly (jcifs)
> 
> OK, we can do LGPL via a download or via Maven.
> 
>> - LGPL dependency, not requiring upstream modifications in order to run properly (postgres jdbc driver)
> 
> Postgres JDBC driver is BSD, right? http://jdbc.postgresql.org/license.html
> 

Sorry.  Mistake on my part.

Karl

Re: Ant builds

Posted by Grant Ingersoll <gs...@apache.org>.
On Feb 9, 2010, at 9:21 AM, Karl Wright wrote:

> 
> I'm looking at what is required for ant builds of LCF, and for this I sort of want to understand "accepted practices" for Apache builds of this kind.
> 
> (1) Structure
> 
> LCF will build many distinct jars, which need to be kept distinct because not all deployments can build or include all functionality.  So there will be, at minimum:
> 
> - A set of jars representing the framework itself
> - A set of jars for each connector
> 
> I say a "set" here, because some components (e.g. the framework and the documentum connector) do in fact contain multiple sub-components.
> 
> The question is - do we want a single ant build for the whole thing?  Or independent ant builds for each major component?  Based on the way it's packaged in debian for MetaCarta, independent components would be better.  Is that acceptable?
> 
> (2) Dependencies
> 
> LCF requires upstream dependencies, many from apache, others from third parties such as postgresql.  The dependencies come in the following flavors:
> - Sun dependency (standard jsp tag library jars and tlds: jstl.jar, standard.jar, sql.tld, c.tld, fmt.tld, x.tld, and servlet.jar)

Do you know which Sun licenses?  There might be Apache equivalents here.

> - Apache dependency, unexceptional (commons-fileupload, commons-collections, commons-codec, commons-logging, log4j, axis, castor)
> - Apache dependency, requiring upstream modifications in order to build properly (commons-httpclient, xerces2-java)
> - LGPL dependency, possibly requiring upstream modifications in order to run properly (jcifs)

OK, we can do LGPL via a download or via Maven.

> - LGPL dependency, not requiring upstream modifications in order to run properly (postgres jdbc driver)

Postgres JDBC driver is BSD, right? http://jdbc.postgresql.org/license.html

> - BSD jar dependency (Bitstream pool driver, jdbcpool-0.99.jar)
> - Third party proprietary jars (not enumerated here)
> - Dependencies which will be immediately removed (metacarta-license.jar)
> 
> I take it we'll just presume, for the purposes of ant, that the correctly generated jars are just dropped in the ant/lib area? What ant build strategy should we use for all of the above categories?

We should have a lib dir under trunk that contains the files.  Similar to Lucene/Solr

> 
> (3) Axis/castor build items
> 
> Connectors that build from wsdls or xsds use axis or castor to generate the appropriate java class code.  Is there a standard Apache ant task that we can use for these?
> 
> Thanks,
> Karl