You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/08/09 22:45:20 UTC
[JJAR] New features
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
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 6:22 AM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> Geir Magnusson Jr. wrote:
>> On 8/12/02 5:18 AM, "Michael Davey" <Mi...@Sun.COM> wrote:
>>
>>
>>> Nicola Ken wrote:
>>>
>>> [snip]
>>>
>>>
>>>
>>>> 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 think it should be the other way around. JJAR should not use the jar name
>>> to
>>> work out the package name and version. If possible, JJAR should use the
>>> Manifest details (Name, Specification-* and Implementation-*). Failing
>>> that,
>>> JJAR could use the digest of the Jar file (MD5 or SHA) and look up the
>>> package
>>> name and version from the repository.
>>
>>
>> If it's there. The idea is that the [distributed] repository is managed, so
>> the jar name can be trusted in each case.
>>
>> But I like the idea of turning to the manifest as well.
>
> Sorry, I don't get this.
> In the code I asw that JJAR *does* look at the Manifets...
It does, but can't depend on it...
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Geir Magnusson Jr. wrote:
> On 8/12/02 5:18 AM, "Michael Davey" <Mi...@Sun.COM> wrote:
>
>
>>Nicola Ken wrote:
>>
>>[snip]
>>
>>
>>
>>>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 think it should be the other way around. JJAR should not use the jar name
>>to
>>work out the package name and version. If possible, JJAR should use the
>>Manifest details (Name, Specification-* and Implementation-*). Failing that,
>>JJAR could use the digest of the Jar file (MD5 or SHA) and look up the package
>>name and version from the repository.
>
>
> If it's there. The idea is that the [distributed] repository is managed, so
> the jar name can be trusted in each case.
>
> But I like the idea of turning to the manifest as well.
Sorry, I don't get this.
In the code I asw that JJAR *does* look at the Manifets...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 5:18 AM, "Michael Davey" <Mi...@Sun.COM> wrote:
> Nicola Ken wrote:
>
> [snip]
>
>
>> 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 think it should be the other way around. JJAR should not use the jar name
> to
> work out the package name and version. If possible, JJAR should use the
> Manifest details (Name, Specification-* and Implementation-*). Failing that,
> JJAR could use the digest of the Jar file (MD5 or SHA) and look up the package
> name and version from the repository.
If it's there. The idea is that the [distributed] repository is managed, so
the jar name can be trusted in each case.
But I like the idea of turning to the manifest as well.
>
> Geir wrote:
>> 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.
>
> The Optional Package Versioning guide (guide/extensions/versioning.html from
> your J2SE API root) specifies 4 types of dependency:
> 1 Need an API that meets specification 'w'
> 2 Need an API that meets specification 'w' version 'x'
> 3 Need an API that meets specification 'w' version 'x' and is supplied by
> vendor 'z'
> 4 Need an API that meets specification 'w' version 'x' and is version 'y'
> supplied by vendor 'z'
>
> I'd suggest the following behaviour for JJAR:
>
> If package 'a' version 'b' specifies a type 1 or type 2 dependency, then once
> a
> jar has been supplied that meets the dependency, the jar can be replaced with
> newer versions of the jar (by the same vendor) as long as the dependency is
> still met.
>
That's reasonable, but this seems to be more tailored to sun's suggestion of
how the world should work, rather than how it does work. Maybe that's a
little harsh, but look at any of the commonly used non-JSR stuff, and there
is no notion of multiple vendor for a given spec, as there isn't a spec.
For example, there is no log4j, velocity or dom4j 'spec' per se, and there
is only one source for each of the above.
> Choosing the vendor in the first place and changing of vendor will most
> probably
> have to be done with user interaction as it is unlikely that the repository
> will
> be able to decide which vendor currently provides the "best" implementation.
Agreed. For the repos that an open-source community might provide (like the
Maven one) you don't choose a vendor for this stuff, as they are
single-source projects, and anything that does have multiple-vendor choice
will probably commercial implementations of Java specs (like JMS), which you
couldn't distribute. (And in my experience with things like JMS, the
looseness of the specs tends to mean that vendors aren't "drop in"
replaceable anyway...)
> Similarly, for type 3 dependencies, the jar can be replaced with newer
> versions
> by the same vendor.
>
> For a type 4 dependency, the target jar can be replaced only as long as the
> version number still matches the supplied number. So, if the dependency
> specifies Foo class version 1.2, JJAR can initially fetch version 1.2.0 and
> replace the dependency over time with 1.2_1, 1.2_5 and 1.2_99 but not 1.3_0.
>
I would trust this *only* if the specifier of the dependency (i.e. The
package owner) stated that 1.2_x works...
> Does this mean that as JJAR downloads a jar, it needs to keep a per-directory
> log of why the jar was downloaded (that is, what dependency a jar fulfils).
> Does this also apply to jars in the classpath, or should they always treated
> as
> a type 1 dependency?
Interesting - I'm not sure I would make this automatic, again as I'm not
sure how much you could trust dependency/spec claims..
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Michael Davey <Mi...@Sun.COM>.
Nicola Ken wrote:
[snip]
> 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 think it should be the other way around. JJAR should not use the jar name to
work out the package name and version. If possible, JJAR should use the
Manifest details (Name, Specification-* and Implementation-*). Failing that,
JJAR could use the digest of the Jar file (MD5 or SHA) and look up the package
name and version from the repository.
Geir wrote:
> 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.
The Optional Package Versioning guide (guide/extensions/versioning.html from
your J2SE API root) specifies 4 types of dependency:
1 Need an API that meets specification 'w'
2 Need an API that meets specification 'w' version 'x'
3 Need an API that meets specification 'w' version 'x' and is supplied by
vendor 'z'
4 Need an API that meets specification 'w' version 'x' and is version 'y'
supplied by vendor 'z'
I'd suggest the following behaviour for JJAR:
If package 'a' version 'b' specifies a type 1 or type 2 dependency, then once a
jar has been supplied that meets the dependency, the jar can be replaced with
newer versions of the jar (by the same vendor) as long as the dependency is
still met.
Choosing the vendor in the first place and changing of vendor will most probably
have to be done with user interaction as it is unlikely that the repository will
be able to decide which vendor currently provides the "best" implementation.
Similarly, for type 3 dependencies, the jar can be replaced with newer versions
by the same vendor.
For a type 4 dependency, the target jar can be replaced only as long as the
version number still matches the supplied number. So, if the dependency
specifies Foo class version 1.2, JJAR can initially fetch version 1.2.0 and
replace the dependency over time with 1.2_1, 1.2_5 and 1.2_99 but not 1.3_0.
Does this mean that as JJAR downloads a jar, it needs to keep a per-directory
log of why the jar was downloaded (that is, what dependency a jar fulfils).
Does this also apply to jars in the classpath, or should they always treated as
a type 1 dependency?
--
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/11/02 1:43 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Will JJAR ever adopt the <dependencies> element of the Maven project
> descriptor?
I see no reason why it shouldn't have a mode where it could use it also.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Will JJAR ever adopt the <dependencies> element of the Maven project
descriptor?
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/10/02 2:30 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> Geir Magnusson Jr. wrote:
>> On 8/10/02 12:48 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>>
>>
>>> Geir Magnusson Jr. wrote:
>>>
>>>> On 8/9/02 4:45 PM, "Nicola Ken Barozzi" <ni...@apache.org> 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 ;-)
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.
Yes
>
> 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"
classpath=".">
<tool name="toolbox.string.mystring" value="Some arbitrary text" />
<tool name="toolbox.tool.footool" value="Footool" />
<velconfig name="runtime.log" value="${basedir}/dvsl.log" />
</dvsl>
I would bet the same could be done for JJARTask. See
org.apache.tools.dvsl.DVSTTask - 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.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Geir Magnusson Jr. wrote:
> On 8/10/02 12:48 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
>
>>Geir Magnusson Jr. wrote:
>>
>>>On 8/9/02 4:45 PM, "Nicola Ken Barozzi" <ni...@apache.org> 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 4:12 AM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> James Strachan wrote:
>> From: "Nicola Ken Barozzi" <ni...@apache.org>
>>
>>> James Strachan wrote:
>
>>>> FWIW there's a SNAPSHOT feature in Maven whereby a project can be
>>>> dependent
>>>> on the latest, greatest snapshot release, so as bugs get fixed you
>>>> automatically get the latest version. So a verion of 'SNAPSHOT' rather
>>>> than
>>>> 1.2-b4 or whatever, just means the latest release added to the repo.
>>>> Great
>>>> for development though this mechanism probably shouldn't be used for
>>>> actual
>>>> releases though.
>>>
>>> It's in JJAR too, smarty, a *year* before Maven decided to make his own
>>> repo stuff.
>>>
>>> This file was committed on 19 August 2001:
>>
>>
>> I don't understand what you're saying. I just simply mentioned that Maven
>> uses the idea that 'SNAPSHOT' is a logical alias for the latest version
>> number. I've no idea what this has to do with the repository DTD that JJAR
>> uses.
>
>>> <!ATTLIST package
>>> name CDATA #REQUIRED
>>> default CDATA #REQUIRED
>>> latest CDATA #REQUIRED >
> ^^^^^^^^^^^^^^
>>>
>>> Ah, NIH is your mantra it seems.
>>
>> Erm, I didn't create Maven. I presume your NIH applies to Maven then?
>
> You are a Maven developer.
> You created Jelly.
> Maven uses Jelly.
>
> Does it mean that even if you are a developer for Maven you are not part
> of the Maven community?
Come on. It doesn't matter. JJAR and Maven are two entirely different
things. JJAR wants to fetch jars in a certain way, and Maven is a complete
build environment for projects. To that end, it needs to drag jars too, but
I think that is secondary to its real purpose.
Maven didn't use JJAR - lets not start Yet Another Battle over this stuff.
The notion of latest in JJAR, to the best of my recall, was to be the lasted
production version. The dev was an auto moving target. The notion of the
snapshot in maven is a nice idea, so you don't get the latest hairball from
cvs - to me, it seems that snapshot means a version that¹s in the dev tree,
but one which was considered stable by the developers.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
> James Strachan wrote:
> > From: "Nicola Ken Barozzi" <ni...@apache.org>
> >
> >>James Strachan wrote:
>
> >>>FWIW there's a SNAPSHOT feature in Maven whereby a project can be
> >>> dependent
> >>>on the latest, greatest snapshot release, so as bugs get fixed you
> >>>automatically get the latest version. So a verion of 'SNAPSHOT' rather
> >>> than
> >>>1.2-b4 or whatever, just means the latest release added to the repo.
> >>> Great
> >>>for development though this mechanism probably shouldn't be used for
> >>> actual
> >>>releases though.
> >>
> >>It's in JJAR too, smarty, a *year* before Maven decided to make his own
> >>repo stuff.
> >>
> >>This file was committed on 19 August 2001:
> >
> >
> > I don't understand what you're saying. I just simply mentioned that
Maven
> > uses the idea that 'SNAPSHOT' is a logical alias for the latest version
> > number. I've no idea what this has to do with the repository DTD that
JJAR
> > uses.
>
> >><!ATTLIST package
> >> name CDATA #REQUIRED
> >> default CDATA #REQUIRED
> >> latest CDATA #REQUIRED >
> ^^^^^^^^^^^^^^
AFAIK that just describes the latest version number of a particular package
in the respository? Thats a different thing AFAIK.
The reason I brought up the SNAPSHOT in Maven was that its used as a version
number inside the dependency list. So package A can depend on the latest
version of package B.
So with JJAR's DTD this concept could be used like this
<dep version="SNAPSHOT"/>
This concept could be used in JJAR too. Quite what this has to do with NIH
and what projects I work on I've no idea.
James
-------
http://james.weblogger.com/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Nicola Ken Barozzi <ni...@apache.org>.
James Strachan wrote:
> From: "Nicola Ken Barozzi" <ni...@apache.org>
>
>>James Strachan wrote:
>>>FWIW there's a SNAPSHOT feature in Maven whereby a project can be
>>> dependent
>>>on the latest, greatest snapshot release, so as bugs get fixed you
>>>automatically get the latest version. So a verion of 'SNAPSHOT' rather
>>> than
>>>1.2-b4 or whatever, just means the latest release added to the repo.
>>> Great
>>>for development though this mechanism probably shouldn't be used for
>>> actual
>>>releases though.
>>
>>It's in JJAR too, smarty, a *year* before Maven decided to make his own
>>repo stuff.
>>
>>This file was committed on 19 August 2001:
>
>
> I don't understand what you're saying. I just simply mentioned that Maven
> uses the idea that 'SNAPSHOT' is a logical alias for the latest version
> number. I've no idea what this has to do with the repository DTD that JJAR
> uses.
>><!ATTLIST package
>> name CDATA #REQUIRED
>> default CDATA #REQUIRED
>> latest CDATA #REQUIRED >
^^^^^^^^^^^^^^
>>
>>Ah, NIH is your mantra it seems.
>
> Erm, I didn't create Maven. I presume your NIH applies to Maven then?
You are a Maven developer.
You created Jelly.
Maven uses Jelly.
Does it mean that even if you are a developer for Maven you are not part
of the Maven community?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> James Strachan wrote:
> > ----- Original Message -----
> > From: "Geir Magnusson Jr." <ge...@adeptra.com>
> >
> >>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.
> >
> >
> > FWIW there's a SNAPSHOT feature in Maven whereby a project can be
dependent
> > on the latest, greatest snapshot release, so as bugs get fixed you
> > automatically get the latest version. So a verion of 'SNAPSHOT' rather
than
> > 1.2-b4 or whatever, just means the latest release added to the repo.
Great
> > for development though this mechanism probably shouldn't be used for
actual
> > releases though.
>
> It's in JJAR too, smarty, a *year* before Maven decided to make his own
> repo stuff.
>
> This file was committed on 19 August 2001:
I don't understand what you're saying. I just simply mentioned that Maven
uses the idea that 'SNAPSHOT' is a logical alias for the latest version
number. I've no idea what this has to do with the repository DTD that JJAR
uses. Is there something magical I'm missing in this DTD?
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
>
> <!ELEMENT repository (packagegroup*) >
> <!ELEMENT packagegroup ( package* ) >
> <!ELEMENT package ( definition | remotedefinition ) >
> <!ELEMENT definition ( info, versionset ) >
> <!ELEMENT remotedefinition (#PCDATA) >
> <!ELEMENT info ( desc, href ) >
> <!ELEMENT desc (#PCDATA) >
> <!ELEMENT href (#PCDATA) >
> <!ELEMENT versionset ( version* ) >
> <!ELEMENT version ( note, jar, dependencies ) >
> <!ELEMENT note ( #PCDATA ) >
> <!ELEMENT jar ( #PCDATA ) >
> <!ELEMENT dependencies ( dep* ) >
> <!ELEMENT dep ( #PCDATA ) >
>
> <!ATTLIST packagegroup name CDATA #REQUIRED >
> <!ATTLIST package
> name CDATA #REQUIRED
> default CDATA #REQUIRED
> latest CDATA #REQUIRED >
> <!ATTLIST version
> version CDATA #REQUIRED >
> <!ATTLIST dep
> package CDATA #REQUIRED
> version CDATA #REQUIRED >
>
>
>
> Ah, NIH is your mantra it seems.
Erm, I didn't create Maven. I presume your NIH applies to Maven then? I try
to reuse as much Jakarta software as I can.
James
-------
http://james.weblogger.com/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
> Geir Magnusson Jr. wrote:
>
> > The Mavenites are like anyone else here, free to use what they want.
>
> I never talked about the Maven community, but replied to precise persons.
Well it was me you replied to. Since both Geir and Jason, the folks who
started JJAR and Maven and have both described their histories, quite why
you're throwing NIH at me is beyond me.
> I won't talk any further into this, and will just continue to do my
> stuff by choosing what I deem best, as always.
Great.
> I'm just sad that collaboration is so hard to attain here at Jakarta.
I don't think it is, all things considered. I think the past year we've seen
lots of collaboration across Jakarta, from commons, avalon, turbine, struts,
taglibs, catus, velocity, cocoon and much more to name but a few. Alot of
the old divides seem to be lifting.
> I don't know who decided to leave the JJAR effort in the first place,
> and I don't want to know, but it's sad nevertheless that for such a
> simple idea there has been a "battle".
See the recent mails by Geir and Jason that explains it all. After todays
mails from Geir & Jason, it seems likely that JJAR and Maven will work
together very nicely.
> It all boils down to one issue.
>
> Some people think that it's good practice to cut-n-paste code from other
> Apache projects, change package names, and ignore anyone that has a
> different idea (wanna send a patch?).
>
> I don't, that's all.
OK. Do you think you could give me a clue as to what you're talking about?
Since I'm the one you NIH-ed, I'd appreciate some pointer to the project
thats upset you as I tend to use and work on quite a few different projects
and I'm still not much good at reading minds.
James
-------
http://james.weblogger.com/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Geir Magnusson Jr. wrote:
> The Mavenites are like anyone else here, free to use what they want.
I never talked about the Maven community, but replied to precise persons.
I won't talk any further into this, and will just continue to do my
stuff by choosing what I deem best, as always.
I'm just sad that collaboration is so hard to attain here at Jakarta.
I don't know who decided to leave the JJAR effort in the first place,
and I don't want to know, but it's sad nevertheless that for such a
simple idea there has been a "battle".
It all boils down to one issue.
Some people think that it's good practice to cut-n-paste code from other
Apache projects, change package names, and ignore anyone that has a
different idea (wanna send a patch?).
I don't, that's all.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Henri Yandell <ba...@generationjava.com>.
> And I keep reading it as a Monty Python-esque riff on
>
> The Knights Who Say "NIH"!
It always looks some kind of nasty chemical to me. Nitrogen Hyrdo-iodide
or something.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 8:22 AM, "Jason van Zyl" <ja...@zenplex.com> wrote:
> On Mon, 2002-08-12 at 03:02, Nicola Ken Barozzi wrote:
>>
>
>>
>> Ah, NIH is your mantra it seems.
>
> Do you even know where JJAR comes from and what started it?
>
Well, it's certainly where the dep engine came from, and there really isn't
much science to the rest of it, being the repo descriptor and the fetching
code.
> I asked Geir a long time ago for a topo sort that I could use in the
> first version of Maven to sort dependencies. It grew from there but the
> impetus was a request from me. At the same time I asked Markus Dahm for
> a graph package he was working and this was subsequently replaced with
> code provided by David Dixon-Peugh. What ensued was a dispute between
> Geir and myself about having a separate dependency descriptor.
>
> At any rate I wanted the dependency mechanism to be based on a solid
> graph package and David Dixon-Peugh has made a super contract-based
> package that is thoroughly tested (though the docs need some work).
>
> So the NIH comment isn't appreciated and isn't justified. I was
> definitely involved when it came about but chose to use a mechanism
> based on a single descriptor and a graph package.
Yes. I think we should just drop the "NIH" stuff. It's not all that
productive. The Mavenites are like anyone else here, free to use what they
want.
And I keep reading it as a Monty Python-esque riff on
The Knights Who Say "NIH"!
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2002-08-12 at 03:02, Nicola Ken Barozzi wrote:
>
>
> Ah, NIH is your mantra it seems.
Do you even know where JJAR comes from and what started it?
I asked Geir a long time ago for a topo sort that I could use in the
first version of Maven to sort dependencies. It grew from there but the
impetus was a request from me. At the same time I asked Markus Dahm for
a graph package he was working and this was subsequently replaced with
code provided by David Dixon-Peugh. What ensued was a dispute between
Geir and myself about having a separate dependency descriptor.
At any rate I wanted the dependency mechanism to be based on a solid
graph package and David Dixon-Peugh has made a super contract-based
package that is thoroughly tested (though the docs need some work).
So the NIH comment isn't appreciated and isn't justified. I was
definitely involved when it came about but chose to use a mechanism
based on a single descriptor and a graph package.
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Nicola Ken Barozzi <ni...@apache.org>.
James Strachan wrote:
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@adeptra.com>
>
>>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.
>
>
> FWIW there's a SNAPSHOT feature in Maven whereby a project can be dependent
> on the latest, greatest snapshot release, so as bugs get fixed you
> automatically get the latest version. So a verion of 'SNAPSHOT' rather than
> 1.2-b4 or whatever, just means the latest release added to the repo. Great
> for development though this mechanism probably shouldn't be used for actual
> releases though.
It's in JJAR too, smarty, a *year* before Maven decided to make his own
repo stuff.
This file was committed on 19 August 2001:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT repository (packagegroup*) >
<!ELEMENT packagegroup ( package* ) >
<!ELEMENT package ( definition | remotedefinition ) >
<!ELEMENT definition ( info, versionset ) >
<!ELEMENT remotedefinition (#PCDATA) >
<!ELEMENT info ( desc, href ) >
<!ELEMENT desc (#PCDATA) >
<!ELEMENT href (#PCDATA) >
<!ELEMENT versionset ( version* ) >
<!ELEMENT version ( note, jar, dependencies ) >
<!ELEMENT note ( #PCDATA ) >
<!ELEMENT jar ( #PCDATA ) >
<!ELEMENT dependencies ( dep* ) >
<!ELEMENT dep ( #PCDATA ) >
<!ATTLIST packagegroup name CDATA #REQUIRED >
<!ATTLIST package
name CDATA #REQUIRED
default CDATA #REQUIRED
latest CDATA #REQUIRED >
<!ATTLIST version
version CDATA #REQUIRED >
<!ATTLIST dep
package CDATA #REQUIRED
version CDATA #REQUIRED >
Ah, NIH is your mantra it seems.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] using maven's repo...
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 10:28 AM, "Jason van Zyl" <ja...@zenplex.com> wrote:
> On Mon, 2002-08-12 at 10:22, Geir Magnusson Jr. wrote:
>> On 8/12/02 10:16 AM, "Jason van Zyl" <ja...@zenplex.com> wrote:
>>
>>> On Mon, 2002-08-12 at 08:33, Geir Magnusson Jr. wrote:
>>>
>>>> 2) You can insulate people who need dependency information from the format
>>>> of the project.xml - so you can change the project.xml format on a
>>>> per-project basis (i.e. Things can evolve rather than have to jump all at
>>>> once...) and the consumer of the repo don't need to know that.
>>>
>>> Sure, then they are just dependent on another format. What's the
>>> difference really.
>>
>> They are dependent upon a format specific to the need, a comprehensive
>> package and dependency format, rather than a format that is really meant for
>> something else, the Maven project description.
>
> That's exactly what a Maven descriptor is except that it is more
> comprehensive given that it will take into dependencies that are non-JAR
> artifacts. Because all project information changes across versions,
> including dependencies, we will use each project.xml file used for a
> release to produce the graph where JJAR puts everything in one file.
> Same thing but I believe Maven's format will be easier to manage given
> that each project maintain's its own dependencies. But something JJAR
> could use would be actually manageable using a Reactor i.e. we can
> easily sweep across each project processing each descriptor used for
> each version to produce what JJAR needs.
That's exactly what I meant - just preprocess your Maven project
descriptors. Then, if they ever change, anyone using the repo won't have to
know about it if you can keep the 'Uber descriptor' stable.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] using maven's repo...
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2002-08-12 at 10:22, Geir Magnusson Jr. wrote:
> On 8/12/02 10:16 AM, "Jason van Zyl" <ja...@zenplex.com> wrote:
>
> > On Mon, 2002-08-12 at 08:33, Geir Magnusson Jr. wrote:
> >
> >> 2) You can insulate people who need dependency information from the format
> >> of the project.xml - so you can change the project.xml format on a
> >> per-project basis (i.e. Things can evolve rather than have to jump all at
> >> once...) and the consumer of the repo don't need to know that.
> >
> > Sure, then they are just dependent on another format. What's the
> > difference really.
>
> They are dependent upon a format specific to the need, a comprehensive
> package and dependency format, rather than a format that is really meant for
> something else, the Maven project description.
That's exactly what a Maven descriptor is except that it is more
comprehensive given that it will take into dependencies that are non-JAR
artifacts. Because all project information changes across versions,
including dependencies, we will use each project.xml file used for a
release to produce the graph where JJAR puts everything in one file.
Same thing but I believe Maven's format will be easier to manage given
that each project maintain's its own dependencies. But something JJAR
could use would be actually manageable using a Reactor i.e. we can
easily sweep across each project processing each descriptor used for
each version to produce what JJAR needs.
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] using maven's repo...
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 10:16 AM, "Jason van Zyl" <ja...@zenplex.com> wrote:
> On Mon, 2002-08-12 at 08:33, Geir Magnusson Jr. wrote:
>
>> 2) You can insulate people who need dependency information from the format
>> of the project.xml - so you can change the project.xml format on a
>> per-project basis (i.e. Things can evolve rather than have to jump all at
>> once...) and the consumer of the repo don't need to know that.
>
> Sure, then they are just dependent on another format. What's the
> difference really.
They are dependent upon a format specific to the need, a comprehensive
package and dependency format, rather than a format that is really meant for
something else, the Maven project description.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] using maven's repo...
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2002-08-12 at 08:33, Geir Magnusson Jr. wrote:
> On 8/12/02 8:23 AM, "Stéphane MOR" <st...@yahoo.fr> wrote:
>
> > I think that the repository will contain the project.xml file
> > for each of the projects. This way we could get each project's
> > dependencies easily. There is a goal in Maven called deploy:pom
> > which was done for this purpose, I believe.
> >
> > An advantage of this is that you can tell that A depends on B,
> > and if B depends on C, you get that info from B's repository's
> > project.xml, and you get C for free. We've been talking about
> > that and refered to it as "direct dependencies" or "first level
> > dependencies", or again "inherited dependencies", which is
> > something that may be really helpful regarding the commons for
> > instance, where inter-dependency is quite high.
>
> I think you should glom together into one place - maybe have some sort of
> sweeper that periodically (or upon checkin) rebuilds a single descriptor
> from the project.xml's that describes everything.
This is exactly what will be done with the share db of project
information. We could certainly produce an xml file in the jjar style.
That's not hard at all, but it will likely get large and I was going to
try and use JISP or Xindice to try and speed things up. This will
ultimately allow us to only specify direct dependencies in Maven, which
has been the plan all along.
> Why?
>
> 1) It makes it easy to just take one file and digest it.
Yup.
> 2) You can insulate people who need dependency information from the format
> of the project.xml - so you can change the project.xml format on a
> per-project basis (i.e. Things can evolve rather than have to jump all at
> once...) and the consumer of the repo don't need to know that.
Sure, then they are just dependent on another format. What's the
difference really.
> 3) You can add other inputs into the dependency graph other than project.xml
> files, and again, the repo consumer doesn't need to know.
Sure, that's possible.
> >
> > As for JJAR, I don't know how that sort of things could fit,
> > but I guess that both dependencies models can be merged / adapted
> > to each other so that JJAR users can use Maven repos and Maven
> > users can use JJAR repos...
>
> I think that's easily possible.
Very easy I think.
> geir
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] using maven's repo...
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 8:23 AM, "Stéphane MOR" <st...@yahoo.fr> wrote:
> I think that the repository will contain the project.xml file
> for each of the projects. This way we could get each project's
> dependencies easily. There is a goal in Maven called deploy:pom
> which was done for this purpose, I believe.
>
> An advantage of this is that you can tell that A depends on B,
> and if B depends on C, you get that info from B's repository's
> project.xml, and you get C for free. We've been talking about
> that and refered to it as "direct dependencies" or "first level
> dependencies", or again "inherited dependencies", which is
> something that may be really helpful regarding the commons for
> instance, where inter-dependency is quite high.
I think you should glom together into one place - maybe have some sort of
sweeper that periodically (or upon checkin) rebuilds a single descriptor
from the project.xml's that describes everything.
Why?
1) It makes it easy to just take one file and digest it.
2) You can insulate people who need dependency information from the format
of the project.xml - so you can change the project.xml format on a
per-project basis (i.e. Things can evolve rather than have to jump all at
once...) and the consumer of the repo don't need to know that.
3) You can add other inputs into the dependency graph other than project.xml
files, and again, the repo consumer doesn't need to know.
>
> As for JJAR, I don't know how that sort of things could fit,
> but I guess that both dependencies models can be merged / adapted
> to each other so that JJAR users can use Maven repos and Maven
> users can use JJAR repos...
I think that's easily possible.
geir
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] using maven's repo...
Posted by Stéphane MOR <st...@yahoo.fr>.
James Strachan wrote:
>----- Original Message -----
>From: "Geir Magnusson Jr." <ge...@adeptra.com>
>
>
>>On 8/12/02 6:14 AM, "James Strachan" <ja...@yahoo.co.uk> wrote:
>>
>>
>>
>>>Incidentally - after taking a fresh look at JJAR - it could be nice to
>>>implement JJAR's Repository interface using Maven's physical repository.
>>>Maven uses directories for each project/package, then seperate files for
>>>each version, rather than a single XML doc for the whole repo.
>>>
>>>So right now JJAR has RepositoryXML that implements Repository by
>>>
>>>
>parsing a
>
>
>>>single XML doc. Writing a MavenRepository class should be pretty easy,
>>>
>>>
>that
>
>
>>>could just use any Maven repo, such as the one here...
>>>
>>>
>>That was the idea, but how do you specify dependencies?
>>
>>
>
>Right now each project has a project.xml that defines its dependencies on
>other things (jars typically). Then a Maven repository contains those
>things. Ultimately I think the repository also needs to also store the
>dependency information as well, whether inside the jar META-INF in some
>format, or as some XML document in the repository.
>
Hi,
I think that the repository will contain the project.xml file
for each of the projects. This way we could get each project's
dependencies easily. There is a goal in Maven called deploy:pom
which was done for this purpose, I believe.
An advantage of this is that you can tell that A depends on B,
and if B depends on C, you get that info from B's repository's
project.xml, and you get C for free. We've been talking about
that and refered to it as "direct dependencies" or "first level
dependencies", or again "inherited dependencies", which is
something that may be really helpful regarding the commons for
instance, where inter-dependency is quite high.
A few graphs on a set of projects showed that for instance, when
Velocity was specified on more than 12 projects (out of ~100),
with the dependency inheritence, it was really only needed by
2 of them, those "giving Velocity" to all the projects that
depended on them.
Log4j, Dom4J, commons-beanutils are other good examples of the
benefits of using this mecanism.
(You can find two comparison graphs here :
http://www.qmvmo.com/maven-dev/deps-graphs.tar.gz)
As for JJAR, I don't know how that sort of things could fit,
but I guess that both dependencies models can be merged / adapted
to each other so that JJAR users can use Maven repos and Maven
users can use JJAR repos...
>I think this is happening with the 'reactor' stuff in Maven though I don't
>know enough about it yet to go into much more detail. But I should think
>this is quite easy to do, maybe as a standard part of the Maven build/deploy
>process.
>
>
Yep, that's definitely a Reactor thing, even if it needs to be a
little clearer (what should it do ? what does it already do ?).
Stéphane
>James
>-------
>http://james.weblogger.com/
>
>
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] using maven's repo...
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@adeptra.com>
> On 8/12/02 6:14 AM, "James Strachan" <ja...@yahoo.co.uk> wrote:
>
> > Incidentally - after taking a fresh look at JJAR - it could be nice to
> > implement JJAR's Repository interface using Maven's physical repository.
> > Maven uses directories for each project/package, then seperate files for
> > each version, rather than a single XML doc for the whole repo.
> >
> > So right now JJAR has RepositoryXML that implements Repository by
parsing a
> > single XML doc. Writing a MavenRepository class should be pretty easy,
that
> > could just use any Maven repo, such as the one here...
>
> That was the idea, but how do you specify dependencies?
Right now each project has a project.xml that defines its dependencies on
other things (jars typically). Then a Maven repository contains those
things. Ultimately I think the repository also needs to also store the
dependency information as well, whether inside the jar META-INF in some
format, or as some XML document in the repository.
I think this is happening with the 'reactor' stuff in Maven though I don't
know enough about it yet to go into much more detail. But I should think
this is quite easy to do, maybe as a standard part of the Maven build/deploy
process.
James
-------
http://james.weblogger.com/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] using maven's repo...
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 6:14 AM, "James Strachan" <ja...@yahoo.co.uk> wrote:
> Incidentally - after taking a fresh look at JJAR - it could be nice to
> implement JJAR's Repository interface using Maven's physical repository.
> Maven uses directories for each project/package, then seperate files for
> each version, rather than a single XML doc for the whole repo.
>
> So right now JJAR has RepositoryXML that implements Repository by parsing a
> single XML doc. Writing a MavenRepository class should be pretty easy, that
> could just use any Maven repo, such as the one here...
That was the idea, but how do you specify dependencies?
> http://www.ibiblio.org/maven/
>
> Then JJAR users could reuse Maven repositories if they wish.
>
That's the idea...
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[JJAR] using maven's repo...
Posted by James Strachan <ja...@yahoo.co.uk>.
Incidentally - after taking a fresh look at JJAR - it could be nice to
implement JJAR's Repository interface using Maven's physical repository.
Maven uses directories for each project/package, then seperate files for
each version, rather than a single XML doc for the whole repo.
So right now JJAR has RepositoryXML that implements Repository by parsing a
single XML doc. Writing a MavenRepository class should be pretty easy, that
could just use any Maven repo, such as the one here...
http://www.ibiblio.org/maven/
Then JJAR users could reuse Maven repositories if they wish.
James
-------
http://james.weblogger.com/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@adeptra.com>
> On 8/12/02 1:41 AM, "James Strachan" <ja...@yahoo.co.uk> wrote:
>
> > ----- Original Message -----
> > From: "Geir Magnusson Jr." <ge...@adeptra.com>
> >> 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.
> >
> > FWIW there's a SNAPSHOT feature in Maven whereby a project can be
dependent
> > on the latest, greatest snapshot release, so as bugs get fixed you
> > automatically get the latest version. So a verion of 'SNAPSHOT' rather
than
> > 1.2-b4 or whatever, just means the latest release added to the repo.
Great
> > for development though this mechanism probably shouldn't be used for
actual
> > releases though.
>
> I saw that - it's pretty cool.
>
> I meant refresh the versions you currently have, mainly for the case where
a
> production version of something like a dependency gets superceded by an
> upgrade for some reason.
Yes - whenever the snapshot is updated and you do a Maven build, your local
repo is updated (if you're online) with the latest snapshot from the remote
repo. Though typically snapshot builds will ultimately used for nightly
builds of CVS HEAD. So maybe some alias like LATEST which could be used for
the latest release?
Maybe some kinda wildcards could be used for dependency versions. Like 1.2.*
for any release starting with 1.2.0 or 1.2.4> for any release from 1.2.4
onwards or something? Then as new releases are made there's no need to hunt
around your dependency files and keep them up to date. I'm sure both Maven
and JJAR could benefit from something like this. Maybe even some kinda
Ant-style includes/excludes patterns?
<dependency>
<id>ant</id>
<includes>1.4.1>, 1.5.*</includes>
<excludes>1.4.1.2</excludes>
</dependency>
James
-------
http://james.weblogger.com/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 1:41 AM, "James Strachan" <ja...@yahoo.co.uk> wrote:
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@adeptra.com>
>> 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.
>
> FWIW there's a SNAPSHOT feature in Maven whereby a project can be dependent
> on the latest, greatest snapshot release, so as bugs get fixed you
> automatically get the latest version. So a verion of 'SNAPSHOT' rather than
> 1.2-b4 or whatever, just means the latest release added to the repo. Great
> for development though this mechanism probably shouldn't be used for actual
> releases though.
I saw that - it's pretty cool.
I meant refresh the versions you currently have, mainly for the case where a
production version of something like a dependency gets superceded by an
upgrade for some reason.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@adeptra.com>
> 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.
FWIW there's a SNAPSHOT feature in Maven whereby a project can be dependent
on the latest, greatest snapshot release, so as bugs get fixed you
automatically get the latest version. So a verion of 'SNAPSHOT' rather than
1.2-b4 or whatever, just means the latest release added to the repo. Great
for development though this mechanism probably shouldn't be used for actual
releases though.
James
-------
http://james.weblogger.com/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/10/02 12:48 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> Geir Magnusson Jr. wrote:
>> On 8/9/02 4:45 PM, "Nicola Ken Barozzi" <ni...@apache.org> 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...
>
> 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.
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.
>
> 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.
>
> 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.
The first two should present no problem if they aren't dependent upon the
actual format of the descriptor (as they shouldn't be).
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Geir Magnusson Jr. wrote:
> On 8/9/02 4:45 PM, "Nicola Ken Barozzi" <ni...@apache.org> 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?
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.
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.
Then JJAR and JJARTask need to have a single JJARBean that implements
common functionality too hook on.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JJAR] New features
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/9/02 4:45 PM, "Nicola Ken Barozzi" <ni...@apache.org> 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.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>