commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [JJAR] New features
Date Sat, 10 Aug 2002 18:30:24 GMT

Geir Magnusson Jr. wrote:
> On 8/10/02 12:48 PM, "Nicola Ken Barozzi" <> wrote:
>>Geir Magnusson Jr. wrote:
>>>On 8/9/02 4:45 PM, "Nicola Ken Barozzi" <> wrote:
>>>>I'm writing fixes to JJAR to be able to check the repo without having to
>>>>connect to the net.
>>>>I remember Geir had something to commit, and in the txt there is a nice
>>>>salivating part that talks about insertion in remote repositories :-D..
>>>>Geir, pleeease commit it, or tomorrow you will find me changing the
>>>>packages and you will have a hard time merging ;-P
>>>Lets talk about it - your changes may not collide with mine and that will be
>>>cool.  If they do, we should figure out what to do.
>>Gee, why don't you commit them, man?
> Because for the past 7 months I can barely find time to wave to my wife when
> she goes to work in the morning...

Yeah, seems like a common problem, even if they say time is relative... 
for us it becomes *the* relative (ok, now that you are disgusted by the 
lame joke we can continue ;-)

>>Anyway, it's basically the JJARTask.
>>I want to make it possible for JJAR not to go on the net to check for
>>the descriptor. In fact if a version is defined and the jar is in the
>>local repo, and there are no dependencies requested there is no need to
>>check the repository descriptor.
> Go for it.   There are some interesting problems here.  First, how do you
> know what the dependencies are - you need a descriptor.

If I use the flag that tells JJAR not to get dependencies, and I give a 
version, I don't need it, since the filename conversion is enough.

In fact the tag that tells what the jar name is, is redundant, because 
in the code you seem to check package and version from the filename... 
can't we just remove it and assume that package-version is enough since 
we will always have a package-version.jar?

> The descriptor should be distributed, IMO, so we just can't stuff the
> descriptor into the jjar.jar (as it can't contain all the info, by
> definition).
> What we could do is have a descriptor in the local repo, that gets added to
> as things get brought locally.  Then you don't need to go out over the wire
> to see if all is well with the local repo.
> This presents an interesting question - can a package  have dependencies
> that change over time?  Suppose a dependency had a bug, and the authors of
> the dependency released a fix.  I guess for now, we just punt and say that a
> local definition in the local repo is definitive for any operation, and then
> later add a 'refresh' op that updates the local repo jars and descriptor.

This is a step further from what I wanted to do... I though about it and 
had your same concerns, but I also agree with your conclusions, so I 
will do it :-)

>>I also need to be able to specify a list of packages to download, so
>>that I can get them from a descriptor or an ant typedef and nave JJAR
>>get them.
> Go for it.

BTW, what do you suggest?
have attributes (a hack but more usable via ant scripts)

   packages="package1, package2, etc"
   versions="1.1-dev ,1.0, 2.0"

or make a packageTypedef?

>>Then JJAR and JJARTask need to have a single JJARBean that implements
>>common functionality too hook on.
> Hm.  I've been (or was) rewriting the core stuff that jjartask uses to clean
> them up and make the code something I would be happy to show people, as well
> as fixing the descriptor.

I can help you with this.
Don't be shy, send it to me so that I will commit it, and people won't 
know who of us 2 wrote the lame code ;-)

Seriously, I can look it over and commit it, if you concede.

> The first two should present no problem if they aren't dependent upon the
> actual format of the descriptor (as they shouldn't be).

I'll start on those then.

But please think that I would be happy to finish to fix and commit the 
changes for you.

Oh, BTW, thank you for JJAR :-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message