ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Seth Landsman <s...@boondock.cs.brandeis.edu>
Subject Re: Composite tasks and symlinks?
Date Mon, 26 Mar 2001 15:35:58 GMT
On Mon, Mar 26, 2001 at 11:51:54PM +1000, Peter Donald wrote:
> At 08:07  26/3/01 -0500, Seth Landsman wrote:
> >> >	(BTW, I've been thinking about a CJAN-like system for a while.  I'd
> >> >be interested in working on such a system.)
> >> 
> >> excellent - it sounds like you are volunteering ? ;)
> >
> >	Definitely.  It sounds like an interesting project.  Is this still
> >blue-sky-ish, or has actual work / discussion happened (and where)?
> 
> discussion has happened. Unfortunately it is distributed across a number of
> projects (Commons, Ant and probably Alexandria). It was originally
> suggested by Jon Stevens in december or so - which should be in the
> archives (Sorry can't be more specific). No actual work has occured as I
> think everyone has been waiting on ant2 (or at least I know I have).

	D'oh.  I'll look through the archives.  Is there a reason it isn't
an actual project off of apache.org (or jakarta.apache.org) yet?

> The technical aspects should be doable - the only limitation that as yet no
> one has mentioned is the legal constraints. Under CJAN it would presumably
> required that a master list and perhaps a complete directory of products be
> stored. Some products may not be copyright apache, some may be GPL etc. The
> problem is one of control and bandwidth. Someone could publish "unsafe"
> code in cjan (ie crypto or decss type code) and we have to be able to shut
> behaviour like that as soon as possible. However we also don't want to be
> trying to police cjan too much. In the end it will be up to the PMC (or
> perhaps Apache members/board) whether they are willing to take this risk
> and provide the bandwidth or if it needs to be hosted elsewhere.

	I see two easy, non-ideal options.

1. A package (unless it has an exception) needs to sit in the incoming
	queue for n (n = 24?) hours before it gets listed publically.
	Therefore, the queue managers can step in before it gets published.

	Known good authors could be given an exception.  This 
	exception happens by signing the upload package with a GPG
	key.

2. A package needs to be moved by a queue manager out of the incoming 
	directory.

(1), I think, is the best deal.

> >	An http header should have a last-editted header, or something
> >like that, right?  Ideally, you should be able to determine whether or
> >not you need to redownload without actually downloading the jar file.
> >The <GET> task supports this via usetimestamp.
> >	Looking forward to CJAN, there needs to be information that can
> >be gathered without downloading the whole jar (especially if the jar is big).
> >Perhaps an XML document that is associated with the jar can be downloaded
> >and inspected first.
> 
> A nice XML product descriptor would be good that listed things like
> dependencies, description, version, authout, source etc. I looked at a few
> things (RPMs/elisp packages being main focus) and there is a rough
> conformity in what each describes. We would just have to
> amalgamate/collect/think of a good way to describe it all ;)

	Right.  

> >> >	I wonder if there should be a seperate package for unix-specific
> >> >tasks?  org.apache.ant.task.unix.symlink, for example.
> >> 
> >> in ant2 - yep - however now to keep backwards compatability we are lumping
> >> them altogether ;)
> >
> >	Okay.  This one just needs some commenting and a license thrown on.
> >I'll send a patch to bugzilla for this (in the task., not task.unix package).

	Ideally, ant1 tasks should work with ant2, regardless of what ant2
looks like.  Has that been discussed / dismissed?

-Seth

Mime
View raw message