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 <[EMAIL PROTECTED]>: > 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 _______________________________________________ pkg-java-maintainers mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
