Jeppe, Certainly 2 has to be the way to go. We can add stuff to the archetypes to ease this process for users. Moreover, we could add specific lift modules that carried the right dependencies and boot wire up to save the users writing boilerplate. i.e.:
+ lift-logging \ - lift-log4j \ - lift-logback The overhead of this would be negligible. Thoughts? Cheers, Tim On Feb 6, 11:28 am, Jeppe Nejsum Madsen <[email protected]> wrote: > Heiko Seeberger <[email protected]> writes: > > Hi, > > > On 5 February 2010 22:11, Jeppe Nejsum Madsen <[email protected]> wrote: > > >> 2) is the cleanest solution since the choice of logging backend is made > >> explicit. But this requires people to change their poms in order to get > >> any logging. > > > Let's go for 2) because in real-world projects people will have to adjust > > the POM anyway. E.g. for persistence modules or for 3rd party libs. > > After some thoughts, I agree. > > One issue remains: Configuration of the actual logging backend (ie log4j > or logback) to load e.g. prod, test & dev configs. > > We can either > > 1) Try to be smart and figure out which backend is available and > configure it automatically. This (I learned :-) doesn't sit too well > with OSGi and is not really the Lift way. > > 2) Require backend specific configuration in Boot. This is the Lift way, > but it's a breaking change > > Opinions? > > /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
