/usr/share/java as maven repository?
robilad at kaffe.org
Wed Dec 19 15:56:40 UTC 2007
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
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
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
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
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
More information about the pkg-java-maintainers