www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@apache.org>
Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Date Wed, 04 May 2005 17:13:12 GMT
Good stuff, maybe it'd be good to start a separate thread from the 
Eclipse plugin artifact topic. -Mark

Steve Loughran wrote:

>On 5/4/05, Niclas Hedhman <niclas@apache.org> wrote:
>  
>
>>On Wednesday 04 May 2005 19:34, Steve Loughran wrote:
>>
>>    
>>
>>>maven repositories are fun because every JAR is on a URL; you can pass
>>>them to a URL classloader as is if you want. The .pom also declares
>>>dependencies for transitive work; a bit like debian apt-get.
>>>      
>>>
>>I have missed this progress. Can you point me to the implementation of this?
>>    
>>
>
>nothing in ant yet; maybe maven2. But the idea of a java version of
>apt-get with less 'one version per system' is a vision that should
>drive us all.
>
>  
>
>
>  
>
>>>-a gui client that could work with the existing Apache repositories
>>>-a client build on AWT for broadest cross platform execution.
>>>-some way of pushing out packages to multiple systems in a cluster
>>>-support per/user, per-system packages
>>>-good auditing to determine package set (with JMX integration)
>>>
>>>That is, a Java successor to all the rpm management tools.
>>>      
>>>
>>Do you have any pointer to more elaborate ideas in this area??
>>    
>>
>
>not yet. Like I said, I was at a configuration workshop last week. It
>was mostly about XML representations of configuration/state, but we
>drifted into the Open Source area a few times
>
>-Carwen covered JPackage and Config4Gnu
> jpackage is interesting, even though I'm personally unhappy with it.
>Its strength is it tries to  integrate java package redist with the
>rpm framework. Its weaknesses are
>
>1. the core project teams dont think about it, need to be coerced into
>patching scripts and other things to work with jpackage
>
>2. RPM is very superuser-centric. I shouldnt have to be su to install
>stuff on my account.
>
>3. RPM is only good on redhat/suse/mandrake, and is somewhat brittle
>there. Partly that's to do with binaries, but also to do with
>locations of things.
>
>For the curious, I was talking about Smartfrog, and demoed a live
>download and run of Axis tcpmon from the m2 repository. The biggest
>issue i have there is signatures; we cant sign the JARs without side
>effects; I can put the SHA1 or MD5 checksums in the deployment
>descriptor, but that makes it too brittle to change.
>
>  
>
>>>Incidentally, one pressing problem with the maven repositories is
>>>there is no easy way to fetch Sun stuff. That is, if I want to use
>>>Axis with mail.jar and activation,jar, you cant get those from the
>>>Apache site for legal reasons. Do you propose any solution to the
>>>clickthrough licensing problem?
>>>      
>>>
>>Milos, didn't Netbeans itself devise some funky system for the
>>non-distributables and click-thru license approvals??
>>
>>    
>>
>
>It publishes stuff encrypted; you need to click through or have a
>secret decryption key for automated builds. I am getting very close to
>mounting a maven2 repository of sun stuff at work, just to avoid their
>clickthrough junk.
>
>  
>


Mime
View raw message