(Avalon & Depot) Re: Moving forward or letting go

["Adam R. B. Jack" <aj...@trysybase.com>]

Niclas wrote:

> Let us start the discussion around Avalon Repository, and see if something
can
> be learnt from it (over at Avalon we are pretty pleased with it).
    [...]
> I hope you can digest this info a bit. The important Avalon crowd, Aaron,
> Stephen, Alex and myself, have expressed a wish to move Repository
> functionality into Depot, and get Depot out of Incubator and get proper
> releases out. Personally, I think Depot importance is big enough to
validate
> a TLP.

I've not been responding 'cos I've been trying to absorb & evaluate. I am
finding this thread compelling. I like a lot of what I read here.

We called Depot -- not Ruper/Greebo (original source code) -- 'cos we wanted
to be open to accept outside influences (primarily Avalon's, also Wagon's,
whatever), and reading this I'm glad we did. We need input/help/drive like
this.

My thoughts are these... Ruper was based upon the concept that we "query a
repository for latest/best fit" and download that. Not download version X
from http://Y (one can do that with a simple <ant <get (HTTP GET)) but pick
the latest 'fit', and download that. Basically, that is my passion w/ a
download tool -- don't let the developer stagnate on older jars if there is
a compatible beter one. For details see:
http://incubator.apache.org/depot/update/

That said, I think we've got too much code for a simple problem & I think
that is hindering us. [My first passion being version,
http://incubator.apache.org/depot/version/, it brings a bunch of baggage
that may or may not help Depot Update.] I think we need to maintain the goal
we have, but also supprot the simple straight-forward 'download this'. There
is enough (simple by needed) work there with MD5 checks, and maybe
click-through acceptance of licenses.

I'd be interesting in collaborating to keep parts of Depot, and integrate
with Avalon's code. I think that bringing fresh eyes into the code (and onto
the problem) would force us (Depot) to focus and clean-up the docs/designs
(on Wiki). I think a joint goal -- with joint use cases -- could really work
this out to something practical. Yes, I'd be very interested in that.

BTW: So Magic can use Ant tasks, is that it? I've read about it (in mails)
but I hadn't registered that. Interesting.

regards,

Adam

version was:(Avalon & Depot)

[Nick Chalko <ni...@chalko.com>]

Niclas Hedhman wrote:

>
>Short notice on versioning;
>We have more or less concluded that 'version strings' now in use are 
>malicious. They mix concerns too much and should probably not be used in the 
>way it is (indicating buildnumber, compatibility, development stage et 
>cetera). They should be seen as opaque strings and a separate system should 
>be made to express the orthogonal concerns of such version.
>
>  
>

That is why we have a separate project just for version concerns.

See
http://incubator.apache.org/depot/version/

Re: (Avalon & Depot) Re: Moving forward or letting go

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 21 June 2004 01:51, Adam R. B. Jack wrote:

> I'd be interesting in collaborating to keep parts of Depot, and integrate
> with Avalon's code. I think that bringing fresh eyes into the code (and
> onto the problem) would force us (Depot) to focus and clean-up the
> docs/designs (on Wiki). I think a joint goal -- with joint use cases --
> could really work this out to something practical. Yes, I'd be very
> interested in that.

Good. I'll try to set aside some time to be part of Depot move forward...

Short notice on versioning;
We have more or less concluded that 'version strings' now in use are 
malicious. They mix concerns too much and should probably not be used in the 
way it is (indicating buildnumber, compatibility, development stage et 
cetera). They should be seen as opaque strings and a separate system should 
be made to express the orthogonal concerns of such version.

More about this later.

> BTW: So Magic can use Ant tasks, is that it? I've read about it (in mails)
> but I hadn't registered that. Interesting.

Magic is really a set of Tasks, and a tiny "boiler-template" for invoking it 
all. And it is all done using the standard mechanisms available in Ant.
That said, there is a Model, which defines all the projects within the 'larger 
project', and standard targets (similar to Maven's goals) which are 
available.
And since the underlying mechansim is 100% Ant, any modifications to the 
build.xml (boiler-template mentioned above), will be carried in its expected 
fashion.
Next on _my_ agenda for Magic is to allow Java logic (in script form) to be 
invoked as part of the build process, when doing in Ant or Ant+JavaScript 
makes it messy.
Another issue I think is on our agenda, is that Avalon Repository is not used 
in Magic, since Magic builds Repository, and that would be nice to solve as 
well.


Cheers
Niclas
-- 
   +------//-------------------+
  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 
+------//-------------------+