directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Update on JPackage Work
Date Mon, 15 Jan 2007 14:54:35 GMT
Very cool.  Thanks for following through on this Ole. - John

On Sat, 2007-01-13 at 18:32 -0800, Ole Ersoy wrote:
> Hey Guys,
> 
> Just a quick update on JPackage work stuff.
> 
> Actually it's more like a tightened design goal
> description around the work, but most of that work has
> been completed, with the archiva stuff being an
> exception.
> 
> It may not be JPackage work anymore, because I
> discovered that they were putting a version free
> symlink in the repository pointing to the
> corresponding versioned package, and then calling that
> the 
> "Standard" package for a specific version of their
> repository.  Sound tricky?
> 
> They have versions of repositories.  Each version is
> allowed to have only one version of a package in it. 
> Yeeees.
> 
> This means that all the other packages should support
> this version, at least in principle.  Wowwwww Horseee.
> 
> So,
> 
> here the the design description around the type of
> repository I think we need, that is now my target.
> 
> PRIMARY GOAL
> To be able to produce yum installs of Apache and 
> other servers/applications that were built using
> dependencies from a 
> Maven repository that is synchronized with the RPM
> repository.
> 
> There will be a layer on top of this that ensures
> Maven best 
> practices with respect to dependency management and 
> plugin management of the poms that are used to 
> produce the RPM spec file (Later I want to combine 
> it with the Archiva server for automatic signature
> checking).
> 
> EASE OF USE
> - A Maven download with preconfigured repository
> settings 
> pointing to a Maven repository that is synced with the
> 
> corresponding RPM repository is made available for
> download.  
> The purpose of this download is to minimize the effort
> required 
> by developers who wish to write artifacts that will 
> commit RPMs to the repository.  
> Thus it will come with archetypes that produce Java
> projects 
> and other project which ensure repository quality
> requirements are met.
> 
> ONLY MAVEN BUILT ARTIFACTS IN THE REPOSITORY
> - Only Maven artifacts will be allowed in the RPM
> repository, 
> at least in the beginning.  The reason for this is to
> focus quality 
> control automation around a set of Maven plugins.
> 
> ALL RPMS ARE A 1:1 MATCH WITH THE CORRESPONDING MAVEN
> PROJECT
> - This is so that RPMS are automatically generated and
> applications 
> that depend on these RPMS have a 1:1 match with the
> original 
> dependencies that developers used when creating the
> application / server.
> 
> SERVER INSTALL AUTOMATION TOOLS FOR RPM
> - So that servers built from the maven artifacts can
> be 
> easily created and installed.  These servers will use
> the 
> standard UNIX/LINUX FHS layout, and use best practices
> with 
> respect to UNIX/LINUX file permissions and ownership.
> 
> Cheers,
> - Ole
> 
> 
>  
> ____________________________________________________________________________________
> Don't pick lemons.
> See all the new 2007 cars at Yahoo! Autos.
> http://autos.yahoo.com/new_cars.html 
> 


Mime
View raw message