This piques my curiosity because I find that having added multiple war overlays to our trunk has slowed down the build time required considerably. Has anyone else experienced this?
- Damon -----Original Message----- From: Edelson, Justin [mailto:[email protected]] Sent: Monday, September 28, 2009 4:17 PM To: Maven Users List Subject: Re: Shared log4j configuration - best practice? I've done both, depending on the use case. But in general, an image is going to be a servlet context resource and thus is a reasonable use for war overlay. That said, an image certainly could be on the classpath and accessed with ClassLoader.getResourceAsStream(). On Sep 28, 2009, at 7:07 PM, "Damon Silver" <[email protected]> wrote: > For common images, say, are you putting those in a shared jar or in > a war? > If the former, how do you reference them at runtime? > > - Damon > > -----Original Message----- > From: Edelson, Justin [mailto:[email protected]] > Sent: Monday, September 28, 2009 9:51 AM > To: Maven Users List > Subject: RE: Shared log4j configuration - best practice? > > That's just how Maven works. If A depends upon B and B depends upon > C, A > depends upon C transitively. It's, of course, not always this simple > because there are different dependency scopes. See the matrix in > http://maven.apache.org/guides/introduction/introduction-to-dependency-m > echanism.html. > > WAR overlays are used specifically (or should be IMHO) for servlet > context resources. For classpath resources, just stick the files in a > JAR and add it as a dependency. > > Justin > > -----Original Message----- > From: Damon Silver [mailto:[email protected]] > Sent: Monday, September 28, 2009 12:40 PM > To: 'Maven Users List' > Subject: RE: Shared log4j configuration - best practice? > > Can you share an example pom for such a dependent project? I.e., if A > depends on B, I'm curious how A imports the dependencies from B. > Currently we're accomplishing something similar to this via war > overlays, but perhaps that isn't the optimal solution. > > Thanks, > > Damon > > -----Original Message----- > From: Kalle Korhonen [mailto:[email protected]] > Sent: Sunday, September 27, 2009 7:55 PM > To: Maven Users List > Subject: Re: Shared log4j configuration - best practice? > > Why don't you just create a submodule only containing that logging > configuration (and possible other shared classpath resources) and make > it a dependency of all the other modules? That's what we do. > > Kalle > > > On Sun, Sep 27, 2009 at 6:27 PM, Paul Benedict <[email protected]> > wrote: >> Brian, it just sounds awfully complex. A simple matter such as >> sharing > >> a log4j.property at the root of a nested project shouldn't create so >> much work. Any other avenue? I am glad you shared this information. >> >> Paul >> >> On Sat, Sep 26, 2009 at 10:12 PM, Brian Fox <[email protected]> > wrote: >> >>> Something like this approach should work: >>> >>> > http://www.sonatype.com/people/2008/04/how-to-share-resources-across-pro > ject > s-in-maven/ >>> >>> On Sat, Sep 26, 2009 at 7:37 PM, Paul Benedict >>> <[email protected]> >>> wrote: >>>> I find myself replicating the same log4j configuration in my Maven >>> projects. >>>> It's a typical setup I want my projects to always use. Is there any > good >>> way >>>> to specify one in a parent POM for all child projects? Would the >>>> maven-remote-resources-plugin be useful for this? >>>> >>>> Paul >>>> >>> >>> --- >>> ------------------------------------------------------------------ >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
