You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Steve Loughran <st...@apache.org> on 2004/10/26 01:17:06 UTC
repository
I have just committed a repository task. In theory it will support
repositories other than maven, but there is only maven support right
now.
<getlibraries destDir="${lib.dir}">
<mavenrepository/>
<library archive="commons-logging"
project="commons-logging" version="1.0.1"/>
</getlibraries>
Still to do:
-a good security model. Verifying MD5 on the ibiblio site is inadequate.
-extract proxy info from the current JVM.
-the test failure on resolving references.
Enjoy,
-steve
ps, wont it be cool to be able to use this to demand load ant task
libraries themselves?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: repository
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steve Loughran wrote:
> I have just committed a repository task. In theory it will support
> repositories other than maven, but there is only maven support right
> now.
>
> <getlibraries destDir="${lib.dir}">
> <mavenrepository/>
> <library archive="commons-logging"
> project="commons-logging" version="1.0.1"/>
> </getlibraries>
>
> Still to do:
> -a good security model. Verifying MD5 on the ibiblio site is inadequate.
> -extract proxy info from the current JVM.
> -the test failure on resolving references.
I applaude this effort :-)
Maybe you know the Depot project in the Incubator... well, we are
closing it for lack of development. I should have known better, but we
always learn something.
In any case, there is some code there that you may want to
grab-use-whatever, or even grab it all and use it in Ant. It's already
in Apache, so you an just go there and grab it.
http://cvs.apache.org/viewcvs.cgi/incubator/depot/trunk/?root=Apache-SVN
http://cvs.apache.org/viewcvs.cgi/incubator/depot/trunk/update/whiteboard/mmay/?root=Apache-SVN
http://cvs.apache.org/viewcvs.cgi/incubator/depot/trunk/update/src/java/org/apache/depot/update/?root=Apache-SVN
There are also Ant tasks.
http://cvs.apache.org/viewcvs.cgi/incubator/depot/trunk/update/src/java/org/apache/depot/update/ant/cache/?root=Apache-SVN
http://cvs.apache.org/viewcvs.cgi/incubator/depot/trunk/update/src/java/org/apache/depot/update/ant/sync/?root=Apache-SVN
http://cvs.apache.org/viewcvs.cgi/incubator/depot/trunk/update/src/java/org/apache/depot/update/ant/tool/?root=Apache-SVN
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: repository
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 26 Oct 2004, Steve Loughran <st...@apache.org> wrote:
> -extract proxy info from the current JVM.
HttpClient doesn't honor the settings <setproxy> would create?
Any idea whether this is going to work/compile against HttpClient
3.0alpha. I'd like to add it to Gump, of course. We have two
different HttpClient projects in Gump since CVS HEAD became vastly
incompatible to the latest released 2.x versions.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: repository
Posted by Matt Benson <gu...@yahoo.com>.
--- Russell Gold <ru...@gmail.com> wrote:
> How does this compare with
> <http://www.httpunit.org/doc/dependencies.html>,
> which has been listed
> on the external tools page for several weeks - a
> task which, when I
> offered it two months ago, was rejected with the
> comment that such
> tasks don't belong in ant proper?
As I recall, I asserted that this would be the
prevailing attitude at that time. Dominique, then
teetering at the very _brink_ of "committerhood," held
the opinion that this type of thing would likely cross
the line into being a necessity in the future. My
diagnosis was based on my observations of the
community process more than anything. I don't recall
the topic getting any more negative than that (but I'm
too lazy to go look).
-Matt
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: repository
Posted by Russell Gold <ru...@gmail.com>.
On Tue, 26 Oct 2004 00:17:06 +0100, Steve Loughran <st...@apache.org> wrote:
>
> I have just committed a repository task. In theory it will support
> repositories other than maven, but there is only maven support right
> now.
>
> <getlibraries destDir="${lib.dir}">
> <mavenrepository/>
> <library archive="commons-logging"
> project="commons-logging" version="1.0.1"/>
> </getlibraries>
How does this compare with
<http://www.httpunit.org/doc/dependencies.html>, which has been listed
on the external tools page for several weeks - a task which, when I
offered it two months ago, was rejected with the comment that such
tasks don't belong in ant proper?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: repository
Posted by Russell Gold <ru...@gmail.com>.
After some more thought, I would like to reopen the discussion on this
work. I see that we are trying to solve roughly the same problem
(projects obtaining dependencies from remote repositories) but with a
very different outlook. I think the differences are significant enough
to discuss both between us and more importantly with the ant
committers as a group.
As I see it, the two main approaches are:
1. The "getLibraries" task. Fetches a set of libraries to be fetched
from a repository and copied into a designated directory. Uses
semantics analogous to "copy" to decide whether the libraries already
present need to be replaced. The repository for a set of libraries is
not inherently part of the task, and may be specified either within
the task or on the command line. Optionally defines a classpath from
the fetched libraries.
2. The "dependencies" task. Identifies a set of files in a repository
by version and creates either a classpath or a fileset (or both) based
on the definition. Maintains a local cache of the files which may be
shared by multiple projects, loading it from the specified repository.
The repository is an inherent part of the definition. May
conditionally exclude entries from the set.
The first is essentially a generalized "copy" task while the second is
a generalized "fileset" or "path" task. I am not sure that it would be
OK to have both, and I believe that the second approach is preferable
for the following reasons:
a. The first approach forces each project to download its files
individually, and may require new downloads after a total-clean. The
second permits multiple projects on the same box to share files, and
only requires new downloads if a file is not found in the cache, thus
facilitating detached development as long as the desired files were
ever loaded on that computer.
b. The first approach provides no simple way to exclude dependencies
for alternative testing scenarios without clearing and reloading the
target directory
c. It is generally not meaningful to separate the specification of a
remote file from its home repository except in the case of mirrors
d. While ant should certainly not require anything from other projects
such as maven, the maven model for managing dependencies is fairly
well established and proven - the second approach imitates it, making
it relative easy for developers used to one to use the other as well.
Does this make sense to you?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: repository
Posted by Russell Gold <ru...@gmail.com>.
On Wed, 3 Nov 2004 19:59:14 +0000, Steve Loughran
<st...@gmail.com> wrote:
> script breaking is always an issue; ant core cannot not break stuff,
> especially as we are so very ignorant of so many uses. Note that you
> can declare tasks and types into a namespace, though I usually just
> declare stuff with a hyphen 'sf-deploy', 'axis-wsdl2java' to namespace
> stuff. No clashes yet.
>
> If not <dependencies>, then <libraries>, perhaps. Easier to spell.
Fine. Then I can still agitate for my approach via other means :)
> I did add the ability to set the classpath, so it is more declarative.
> I left off fileset as it is a more troublesome beast.
The uses which I have found for this task include the ability to copy
the selected dependencies into a single directory (while optionally
removing the version suffixes). This is very useful for binary
releases, which tend to ship their dependencies. You sort of need the
fileset for that. Otherwise, it is simpler to run from the cached
files.
> I chose not to explicitly use a central repository, because of the
> extra complexity of cross-project implications, such as race
> conditions and versions. I like my isolation. On a big project you can
> and should declare a central home for stuff.
I agree that it is a problem, and that declaring a central home is a
good idea. And having the ability to redefine the layout of the
repository is very good - I happen to have a case where that is
important for internal dependencies. I would like to understand better
how your approach helps with cross-project issues.
> Now, you can add support for the repository stuff in your task, just
> add the relevant setter. Once I add security it will be useful.
Yup.
> I had a look at the depot stuff in the apache incubator incidentally;
> if you haven't you should. Its a very ambitious project as it actually
> wanted to solve the versioning problem properly.
I did look at it after submitting my task to that group. Their
approach seemed to be essentially the same as mine, although slightly
less well developed. Of course, I might have missed something - the
project was never very active in the time I was subscribed to the
list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: repository
Posted by Russell Gold <ru...@gmail.com>.
On Wed, 3 Nov 2004 17:10:46 +0000, Steve Loughran
<st...@gmail.com> wrote:
> On Wed, 3 Nov 2004 10:24:45 -0500, Russell Gold <ru...@gmail.com> wrote:
>
>
> > On Tue, 2 Nov 2004 21:40:00 +0000, Steve Loughran
> Check out ant, rebuild it, use <getlibrary> ; or look in
> src/..../tasks/repository
>
> no docs; look at the test stuff in getlibrary.xml
>
> I will rename the task shortly; dependencies is better.
After looking over the code, I would actually prefer that you NOT use
the name "dependencies" since I think the intent and philosophy of the
getlibraries task is completely different from my dependencies task.
My intent was to be declarative - defining a fileset or classpath by
specifying artifacts which would usually by found in a local cache,
and BTW also being able to populate that cache from one or more
repositories. It was also specifically intended to use the vocabulary
and concepts already established by maven, rather than inventing new
ones.
Your task appears to be more procedural, intending to download files,
but willing to bypass the downloading if they are locally available.
The two don't appear to be really compatible, and anybody who used my
task would find their scripts broken if you take over the name to mean
something very different. For your task, the name getlibraries is
probably a better name.
Now if I could persuade you to use my task in preference, and simply
add the extensible repository model...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: repository
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Steve Loughran [mailto:stevel@apache.org]
> Sent: 26 October 2004 01:17
> To: Ant Developers List
> Subject: repository
>
>
> I have just committed a repository task. In theory it will support
> repositories other than maven, but there is only maven support right
> now.
>
> <getlibraries destDir="${lib.dir}">
> <mavenrepository/>
> <library archive="commons-logging"
> project="commons-logging" version="1.0.1"/>
Some questions:
1. Where is the source that you have committed?
2. Where is the hosts sequence declared?
3. What happens when the group id is different from the artifact id?
4. Where is timestamp policy management declared?
5. What is the policy concerning SNAPSHOT artifacts?
Cheers, Steve,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org