Dependency standards

[Gilles Scokart <gs...@gmail.com>]

 


When reading some general info about apache
(http://www.apache.org/foundation/how-it-works.html#management ) I have seen
one of the sentence of The Apache Way :  "faithful implementation of
standards".

What does it means for ivy?  What are the existing standard (official
standards or de-facto industry standards) related to dependency management?

Making a search, I found JSR 277.
There is also the defacto standards apt, rpm and maven repository.

What else?

Don't you think that such inventory, with description and the its relation
with ivy would have his place on the wiki?


Gilles

Re: Dependency standards

[Stefano Mazzocchi <st...@apache.org>]

Stephane Bailliez wrote:
> Stefano Mazzocchi wrote:
>> [...]
>> don't forget BSD's ports
>>   
> And Stefano and Leo's stuff ? ;)

shhhhhh, it's supposed to be secret!

damn coworkers ;-)

-- 
Stefano.

Re: Dependency standards

[Stephane Bailliez <sb...@gmail.com>]

Stefano Mazzocchi wrote:
> [...]
> don't forget BSD's ports
>   
And Stefano and Leo's stuff ? ;)

Re: Dependency standards

[Stefano Mazzocchi <st...@apache.org>]

Steve Loughran wrote:
> Gilles Scokart wrote:
>>  
>>
>>
>> When reading some general info about apache
>> (http://www.apache.org/foundation/how-it-works.html#management ) I
>> have seen
>> one of the sentence of The Apache Way :  "faithful implementation of
>> standards".
>>
>> What does it means for ivy?  What are the existing standard (official
>> standards or de-facto industry standards) related to dependency
>> management?
>>
>> Making a search, I found JSR 277.
>> There is also the defacto standards apt, rpm and maven repository.
>>
>> What else?
>>
>> Don't you think that such inventory, with description and the its
>> relation
>> with ivy would have his place on the wiki?
> 
> Yes, that would be really good. Don't forget OSGi. There was a really
> good OSGi talk at apachecon eu this year.
> 
> 
> All these tools are trying to solve slightly different problems.
> 
> 
> rpm: manage the state of a single machine, downloading and installing
> the requested version of an artifact, uninstalling its precedessor.
> 
> apt: manage the state of a single machine, downloading and installing
> the requested version of an artifact, uninstalling its precedessor. If
> the artifact is only published as source, compile it based on scripts in
> the .deb package
> 
> They act on the global state of the system, and are primarily a redist
> mechanism. Wonderful though they may be.
> 
> ivy: manage the dependencies of a build, and across builds. pull down
> artifacts into a cache for efficiency.
> 
> m2: manage the dependencies of a build, and across builds. pull down
> artifacts into a cache for efficiency. With a whole project's metadata
> in the pom, on demand-compilation is possible, as is continous
> integration without the need to configure the CI server any further.
> 
> They are build time. and because you can have different versions
> side-by-side in the filesys, that is what you get. What neither of them
> do is enforce a hard split between compile time interfaces and runtime
> artifacts, or provide any runtime management of JARs you load. They dont
> dictate how you use the JARS.
> 
> OSGi: manage interaction between deployed artifacts. You can have
> different versions in different classloaders; only interface atifacts
> are exported, while impl. artifacts are kept private. Its an application
> architecture, not a build system. It has limitations (RMI dynamic
> classloading is troubled; hot swapping is only slightly possible), but
> it tells you how to design your app. Its pretty nice, although your
> modules are still coupled at the interface class level, which is fairly
> brittle. Tools that integrate by passing XML content around in process
> (Cocoon, netkernel) are more loosely coupled as there is no sharing of
> artifacts between modules, just XML content.
> 
> Also: the Perl CPAN and ruby gems systems.

don't forget BSD's ports

-- 
Stefano.

Re: Dependency standards

[Steve Loughran <st...@apache.org>]

Gilles Scokart wrote:
>  
> 
> 
> When reading some general info about apache
> (http://www.apache.org/foundation/how-it-works.html#management ) I have seen
> one of the sentence of The Apache Way :  "faithful implementation of
> standards".
> 
> What does it means for ivy?  What are the existing standard (official
> standards or de-facto industry standards) related to dependency management?
> 
> Making a search, I found JSR 277.
> There is also the defacto standards apt, rpm and maven repository.
> 
> What else?
> 
> Don't you think that such inventory, with description and the its relation
> with ivy would have his place on the wiki?

Yes, that would be really good. Don't forget OSGi. There was a really 
good OSGi talk at apachecon eu this year.


All these tools are trying to solve slightly different problems.


rpm: manage the state of a single machine, downloading and installing 
the requested version of an artifact, uninstalling its precedessor.

apt: manage the state of a single machine, downloading and installing 
the requested version of an artifact, uninstalling its precedessor. If 
the artifact is only published as source, compile it based on scripts in 
the .deb package

They act on the global state of the system, and are primarily a redist 
mechanism. Wonderful though they may be.

ivy: manage the dependencies of a build, and across builds. pull down 
artifacts into a cache for efficiency.

m2: manage the dependencies of a build, and across builds. pull down 
artifacts into a cache for efficiency. With a whole project's metadata 
in the pom, on demand-compilation is possible, as is continous 
integration without the need to configure the CI server any further.

They are build time. and because you can have different versions 
side-by-side in the filesys, that is what you get. What neither of them 
do is enforce a hard split between compile time interfaces and runtime 
artifacts, or provide any runtime management of JARs you load. They dont 
dictate how you use the JARS.

OSGi: manage interaction between deployed artifacts. You can have 
different versions in different classloaders; only interface atifacts 
are exported, while impl. artifacts are kept private. Its an application 
architecture, not a build system. It has limitations (RMI dynamic 
classloading is troubled; hot swapping is only slightly possible), but 
it tells you how to design your app. Its pretty nice, although your 
modules are still coupled at the interface class level, which is fairly 
brittle. Tools that integrate by passing XML content around in process 
(Cocoon, netkernel) are more loosely coupled as there is no sharing of 
artifacts between modules, just XML content.

Also: the Perl CPAN and ruby gems systems.

-steve

Re: Dependency standards

[Xavier Hanin <xa...@gmail.com>]

On 11/15/06, Gilles Scokart <gs...@gmail.com> wrote:
>
>
> When reading some general info about apache
> (http://www.apache.org/foundation/how-it-works.html#management ) I have
> seen
> one of the sentence of The Apache Way :  "faithful implementation of
> standards".
>
> What does it means for ivy?


I don't think it means much for Ivy, because there is no real standard in
the area of Java dependency management.

  What are the existing standard (official
> standards or de-facto industry standards) related to dependency
> management?
>
> Making a search, I found JSR 277.
> There is also the defacto standards apt, rpm and maven repository.
>
> What else?


OSGi
On non java technologies (like apt and rpm) you have also .NET assembly,
perl CPAN, ruby gem, and certainly many else. But I don't know if we have to
quote such technologies, since they are not easily usable with Java, and Ivy
has a focus on java dependency management.

Don't you think that such inventory, with description and the its relation
> with ivy would have his place on the wiki?


Comparing Ivy with existing technologies and standards is a good thing for
users, so that they better know the strength and weaknesses before choosing
Ivy.

- Xavier

Gilles
>
>
>