cocoon maven repository

[Stefan Podkowinski <sp...@gmail.com>]

Hi Dev Team

I'm currently working on a project that does bundle the cform and
portal block + core classes and is being build by maven1. This works
quite well, the only problem is that some of cocoons dependencies
cannot be found in the well known public repositories, mostly
snapshot/dated jars such as rhino.

Now I noticed that you guys are porting the whole cocoon project to
maven2. How are you managing dependencies? It would be great if you
could support maven1 as well by providing a remote repo with the
dependences. Creating pom descriptors for each block would also be
helpfull.

Regards,
Stefan

Re: cocoon maven repository

[Carsten Ziegeler <cz...@apache.org>]

Stefan Podkowinski schrieb:
> How are you going to ship cocoon distributions after moving to m2?
> Will you have all dependencies included in a whatever.tar.gz archive
> or let maven do the downloads from a remote repo (and break the
> current download/mirroring process)? In second case, whats the reason
> not to setup a m1 remote repo as well?
> 
The bin dist will contain all required jars while the src dist will use
m2 to build. All dependencies will be available on publically reachable
repositories. Most of our dependencies are available from the usual
Maven repos. The rest will be put on http://cvs.apache.org/repository
which is a m1 style repository. You'll find the required snapshots (e.g.
Rhino) there.
On the long term we will not use snapshorts but only released versions
and hope that the projects we depend on put their jars into the usual
maven repositories.

HTH
Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: cocoon maven repository

[Stefan Podkowinski <sp...@gmail.com>]

How are you going to ship cocoon distributions after moving to m2?
Will you have all dependencies included in a whatever.tar.gz archive
or let maven do the downloads from a remote repo (and break the
current download/mirroring process)? In second case, whats the reason
not to setup a m1 remote repo as well?


On 9/10/05, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Saturday 10 September 2005 23:33, Jorg Heymans wrote:
> > Stefan Podkowinski wrote:
> > > The project will be hosted on sourceforge so I can't really setup my
> > > own repository for this. Another option would be to ship dependencies
> > > not available on public repos with my distribution. But I want do
> > > avoid this if possible to keep download size for updates as small as
> > > possible.
> >
> > Actually, i think we have created a small m2 cocoon repository somewhere
> > on the Apache servers. I can't remember exactly where and how, but
> > possibly we could provide an m1 style repository as well.
> 
> There is a general "avoid snapshots" policy for ASF repositories, as they will
> not be guaranteed to be there 'forever' which may cause trouble to users, and
> a "no snapshot" policy for the repository that gets replicated to
> ibiblio.org.
> 
> If special builds, snapshots and what not can't be avoided, the best practice
> is probably to ship those explicitly.
> 
> 
> Cheers
> Niclas
>

Re: cocoon maven repository

[Niclas Hedhman <ni...@hedhman.org>]

On Saturday 10 September 2005 23:33, Jorg Heymans wrote:
> Stefan Podkowinski wrote:
> > The project will be hosted on sourceforge so I can't really setup my
> > own repository for this. Another option would be to ship dependencies
> > not available on public repos with my distribution. But I want do
> > avoid this if possible to keep download size for updates as small as
> > possible.
>
> Actually, i think we have created a small m2 cocoon repository somewhere
> on the Apache servers. I can't remember exactly where and how, but
> possibly we could provide an m1 style repository as well.

There is a general "avoid snapshots" policy for ASF repositories, as they will 
not be guaranteed to be there 'forever' which may cause trouble to users, and 
a "no snapshot" policy for the repository that gets replicated to 
ibiblio.org.

If special builds, snapshots and what not can't be avoided, the best practice 
is probably to ship those explicitly.


Cheers
Niclas

Re: cocoon maven repository

[Jorg Heymans <jh...@domek.be>]

Stefan Podkowinski wrote:
> The project will be hosted on sourceforge so I can't really setup my
> own repository for this. Another option would be to ship dependencies
> not available on public repos with my distribution. But I want do
> avoid this if possible to keep download size for updates as small as
> possible.
> 

Actually, i think we have created a small m2 cocoon repository somewhere
on the Apache servers. I can't remember exactly where and how, but
possibly we could provide an m1 style repository as well.

WDOT?

Jorg

Re: cocoon maven repository

[Stefan Podkowinski <sp...@gmail.com>]

The project will be hosted on sourceforge so I can't really setup my
own repository for this. Another option would be to ship dependencies
not available on public repos with my distribution. But I want do
avoid this if possible to keep download size for updates as small as
possible.

On 9/10/05, Jorg Heymans <jh...@domek.be> wrote:
> 
> Stefan Podkowinski wrote:
> 
> > I'm currently working on a project that does bundle the cform and
> > portal block + core classes and is being build by maven1. This works
> > quite well, the only problem is that some of cocoons dependencies
> > cannot be found in the well known public repositories, mostly
> > snapshot/dated jars such as rhino.
> >
> I usually put these in a company-wide maven proxy [1], not a perfect
> solution but for apps deployed inside the company domain it does the trick.
> 
> > dependences. Creating pom descriptors for each block would also be
> > helpfull.
> 
> pom descriptors are being created for every block yes.
> 
> 
> Regards
> Jorg
> 
> [1] http://maven-proxy.codehaus.org/
> 
>

Re: cocoon maven repository

[Jorg Heymans <jh...@domek.be>]

Stefan Podkowinski wrote:

> I'm currently working on a project that does bundle the cform and
> portal block + core classes and is being build by maven1. This works
> quite well, the only problem is that some of cocoons dependencies
> cannot be found in the well known public repositories, mostly
> snapshot/dated jars such as rhino.
> 
I usually put these in a company-wide maven proxy [1], not a perfect
solution but for apps deployed inside the company domain it does the trick.

> dependences. Creating pom descriptors for each block would also be
> helpfull.

pom descriptors are being created for every block yes.


Regards
Jorg

[1] http://maven-proxy.codehaus.org/