look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network...
- Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 4 Jul 2011 16:56, "Kasun Gajasinghe" <kasu...@gmail.com> wrote: > On Mon, Jul 4, 2011 at 8:34 PM, Ralph Goers <ralph.go...@dslextreme.com >wrote: > >> The question I asked was, "will you be putting the slf4j, Log4j, >> commons-logging, and Logback into your shared library" - presumably under >> /usr/shared. This has nothing to do with Maven, per se. Maybe I'm not clear >> on what you are doing but I see two possibilities: >> 1. You are placing all the resultant jars in a common directory, such as >> /usr/share/lib, where applications will use them. This won't work for the >> reasons below. >> > > This isn't the case. > > >> 2. You are building all these projects as independent entities under >> /usr/share. If this is the case then it sounds like you are (sort of) >> duplicating the Maven repository and I have no idea why this is of benefit >> to anyone, especially since you will only support a single version of an >> artifact. >> > > Almost true. For example, slf4j jar is under /usr/share/slf4j/lib/slf4j.jar. > And, we have a concept called "SLOT" which is almost acts like the first > level of a two level index if you are familiar with DBMS. A particular SLOT > contains a set of versions (ex. 1.1, 1.12, 1.2 etc.) which are compatible > with each other. So, only one jar can be installed in a particular SLOT. > There can be several SLOTs, implying we can have more than one version of an > artifact. ex. jarjar new version is in SLOT 1, i.e. /usr/share/jarjar-1/ > > And, these jars in /usr/share/*/lib/*.jar are not only for maven. To be > specific not intended for maven. These are for system use. Any application > maven or not is able to benefit from these. What we are doing is using these > jars under maven, so we don't have to download these again. > > >> >> I could understand this if you are building applications end users can use >> that are written in Java, but in that case I'd wonder why you don't just use >> out-of-the-box Maven and either a) just download the dependencies from the >> central repo or b) build the dependencies from their source and deploy them >> to your local repository. Of course, with the second option you would have >> to build several versions of the dependencies. >> > > To reiterate, our main usecase is supporting packagers at system level. > There's a need to have a custom build for them. It's not like we > blind-foldly building maven again instead of using official maven build! To > answer your question; at system-level, maven should be run completely > offline (even at first time!). We have mechanisms in place to take care of > the deps via DEPEND in ebuilds, which I'm not going to explain. Read about > Gentoo if you got spare time. It'll be interesting! :) > > --Kasun > > >> >> Ralph >> >> On Jul 4, 2011, at 6:11 AM, Kasun Gajasinghe wrote: >> >> > On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers < ralph.go...@dslextreme.com >> >wrote: >> > >> >> The point I am making is that if you have all those jars together >> something >> >> is not going to work correctly. SLF4J only allows one logging >> >> implementation. If you have all of SLF4J's jars, including the binding >> for >> >> Log4j as well as Logback, then SLF4J will throw a runtime exception. >> >> >> >> Commons Logging also has quirks. If Log4j is present then it will be >> used >> >> by default, otherwise it will do something else. >> >> >> > >> >> When you start dumping a whole bunch of jars together in one directory >> you >> >> had better understand how they are all going to relate to each other. >> >> >> > >> > I don't get it. log4j and logback won't be included in gentoo's uber-jar >> > since they aren't dependencies of apache-maven [1]. commons-logging and >> > slf4j will be integrated since they are integrated in the upstream >> official >> > build as well. What makes you think that I'm bundling together all the >> > available logging implementations? Is there a need to? >> > >> > [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html >> > >> > Regards, >> > --Kasun >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > -- > ~~~*******'''''''''''''*******~~~ > Kasun Gajasinghe, > University of Moratuwa, > Sri Lanka. > Blog: http://blog.kasunbg.org > Twitter: http://twitter.com/kasunbg
