ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject RE: public repositories: what is best practice for, how do you do, ...
Date Wed, 22 Nov 2006 13:20:26 GMT
Robert, 

0. I'm not sure what is better : always keep the version numbers in the
filenames in your repository or just placing them in a directory with the
version numbers.  I have even no idea of any pros/cons in favor of one or
the other solution.

1. My first idea is that your ivy file is never read.  In that case, ivy
search for a jave named 'module'.jar.

2. It looks like you want actually one repository per third party product
each one containing all its dependencies.  It is unusual.  The problem that
you will have is when you need a jar contained as a lib in two third party
product.  Which one should be used?  You might also have problems to
maintain all the meta-data.

3. You can play with type of artefacts or with configurations.  By using the
types, you can ask to retrieve all artefacts of the type 'doc' or 'jar' or
both. The difference with configurations is that you can have different
dependencies.


Gilles

> -----Original Message-----
> From: Robert Buck [mailto:rbuck@m-Qube.com] 
> Sent: Wednesday, November 22, 2006 1:52 PM
> To: ivy-user@incubator.apache.org
> Subject: public repositories: what is best practice for, how 
> do you do, ...
> 
> Hi
>  
> I set up my own public repository. It works great, but until 
> now I have only dealt with very simple content and structures 
> (one directory and single jars).
>  
> In general, what is the best way to handle declaring 
> publications and declaring dependencies, when there exists 
> several jars, in some subdirectory, jars not named after the product.
>  
> For instance:
>  
> |-----ws
> |  |---commons
> |  |   |---util
> |  |       |---1.0.1
> |  |           |---lib (ws-commons-util-1.0.1.jar)
> |  |---xmlrpc
> |       |---3.0
> |           |---lib (many jars)
> |--xerces-j
>     |---2.8.1  (resolver.jar, xercesImpl.jar, xml-apis.jar)
> 
> I have two questions...
> 
> 1. When I try to resolve the third party product, xerces-j, 
> Ivy indicates that it is trying to resolve jars named 
> xerces-j.jar! But,
> 
> <ivy-module version="1.0">
>   <info organisation="apache" module="xerces-j" revision="2.8.1"
> status="release" publication="20060914060200">
>     <license name="Apache"
> url="http://www.apache.org/licenses/LICENSE-2.0.txt"/>
>     <ivyauthor name="VeriSign" url="http://www.verisign.com/"/>
>     <repository name="ivyrep" url="http://localhost:20080/ivyrep/"
> pattern="[organisation]/[module]/ivy-[revision].xml" ivys="true"
> artifacts="true"/>
>     <description homepage="http://xerces.apache.org/xerces-j/">Xerces2
> Java is a high performance, fully compliant XML 
> parser.<br/></description>
>   </info>
>   <configurations>
>     <conf name="default" description="for minimal use"/>
>   </configurations>
>   <publications>
>     <artifact name="xercesImpl" type="jar" conf="default"/>
>   </publications>
> </ivy-module>
> 
> Declares that xercesImpl.jar is the publication.
> 
> 2. It turns out that xmlrpc depends upon ws-commons-util, and 
> each of these products as provided by apache stores the jars 
> in a lib directory.
> I would like to preserve the directory structure as provided 
> by the vendor, in this case Apache (keep the jars in the lib 
> directory). How do you declare publications in this case, and 
> declare dependencies? I have not been able to get this to 
> work. In a nutshell, I'd like to be able to declare a 
> publication in a respository by indicating a subdirectory to 
> look in, and the regular expression pattern for the specific 
> jar files to match.
> 
> 3. In general, I'd like to be able to declare different 
> classes of publications in the public repository: doc, jars, 
> all. Have 'docs' so developers can download doc on demand 
> only. Have 'jars' so the product may be compiled. Have 'all' 
> so we can bring down a full product which may be comprised of 
> shell scripts, jars, docs, and the like.
> 
> Bob
> 
> 


Mime
View raw message