/usr/share/java as maven repository?

[Arnaud Vandyck]

Many thanks for the clarifications.

So if we are talking about refactoring /usr/share/java, let's do it in
some sort of Debian way. We'll write a wrapper around different build
system to let them understand our layout. (is it what you meant?)

;-)

2007/12/19, Dalibor Topic <robilad at kaffe.org>:
> Arnaud Vandyck wrote:
> >> To simplify things a bit I would suggest to
> >> convert /usr/share/java to something maven understands as repository instead
> >> of creating another repo.
> >>
> >
> > Maybe we can think about refactoring /usr/share/java, but why do we
> > use the maven layout. I did not fully understand the remark from
> > Dalibor about the "undirection" comments, but I understood don't bind
> > to a specific way. Dalibor, was it what you explained (and I tried to
> > understand)?
> There are several different build systems for java applications that
> support some form of
> a repository concept. They are also all kind of different in what the
> expected format of the
> repository is:
>
> Maven 1
> Maven 2
> Ivy
> bnd/OBR
> Raven
> JSR 277
>
> Picking one over the other is hopeless, as we'll likely encounter
> applications and libraries
> using any of those in the future, in the same way how people just didn't
> stay happy with
> make/ant/etc. Such programs will likely depend on the same jars, just
> 'wrapped' suitably
> to make them 'visible' for each build system in the way it likes to see
> its repository, as
> poms, gems, ivy poms, bundles, jam files, etc.
>
> So I think the economical way forward is to add a layer of indirection
> between what the
> build tools see as their image of the repository formed by packages in
> /usr/share/java
> and the actual /usr/share/java binaries.
>
> That would let us support any current or future build system with any
> idea of what its
> particular repository layout should be, without having to pick one as a
> default, and having
> to switch to another default later, decoupling what we do inside
> /usr/share/java from a
> particular repository layout chosen by a build tool.
>
> I'd suggest solving the first problem on your list first, and only that
> problem for the next release.
> Once we have some experience with using maven to satisfy build
> requirements, I think we'll
> be able to make a more informed decision which of the three ways forward
> on the second problem
> to pick.
>
> cheers,
> dalibor topic
>


-- 
Arnaud Vandyck