http://svn.codehaus.org/mojo/c-builds/

Don't know if it has a web site up yet at http://mojo.codehaus.org/

On 15/01/2007, at 11:03 AM, Ole Ersoy wrote:

Oh - cool - thanks Brett.

Do you know what the project URL for c-builds is by
chance?

I tried:

http://c-builds.codehaus.org/

I also tried googleing, and
looking through all the confluence projects
at codehaus, but did not see a c-builds (Just so you
know I made attempts before asking :-) )

Thanks again,
- Ole


--- Brett Porter <[EMAIL PROTECTED]> wrote:

Seems consistent with what's happening in the
c-builds stuff at
mojo.codehaus.org - you might want to ask there?

The additions to archiva sound interesting too.

- Brett

On 14/01/2007, at 3:35 AM, Ole Ersoy wrote:

Hi,

I'm in need of a RPM repository that is yum
accessible, where all the RPMs are produced by
Maven,
and I wanted to check if anyone else is interested
in
the same thing?

The primary goal is to be able to produce yum
installs
of Apache and other servers/applications that were
built using a 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).

Here's a brief synapsis of the
requirements/benefits.

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 generated and installed.  These servers
will
use an the standard UNIX/LINUX FHS layout, and use
best practices with respect to UNIX/LINUX file
permissions and ownership.

I have a lot of this work done already, I just
wanted
to see whether there are others interested in this
type of approach and whether there are any
thoughts on
how to go about creating the central location for
this
type of effort?

Cheers,
- Ole








______________________________________________________________________

______________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html



---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]






______________________________________________________________________ ______________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to