commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: [JJAR] New features
Date Sat, 10 Aug 2002 20:52:47 GMT
On 8/10/02 2:30 PM, "Nicola Ken Barozzi" <> wrote:

> 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
>>>>> 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 ;-)

Riffing on this further, the recent discovery that the speed of light may
not be constant might imply that time is speeding up.  If that's so, it
explains a lot about my life lately...

>>> 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?

I don't understand.
>> 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?

In DVSL, Bill Burton (I think) did a nice addition to let us specify tools
to be included in the DVSL context.  It looks like this :

<dvsl basedir="doc" destdir="build/doc"
      extension=".html" style="style/apache.xsl"
  <tool name="toolbox.string.mystring" value="Some arbitrary text" />
  <tool name="toolbox.tool.footool" value="Footool" />
  <velconfig name="runtime.log" value="${basedir}/dvsl.log" />

I would bet the same could be done for JJARTask.  See - look at the Tool support.

>>> 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.

I just need to find the slot to do it.

>> 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.

I am going to use JJAR in the project I'm working on, as I have to deploy
code across ~50 machines, and the best way I can think of is something like
JJAR.  To that end, I should find a timeslot to get it done - it's just a
matter of stress.  When the stress to get this tool working exceeds the
stress for everything else, it will be done in short order :)

Geir Magnusson Jr. 
Research & Development, Adeptra Inc.

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

View raw message