It would be nice! In AppFuse only one war is ever overlayed. I am guessing
pretty rare. For AppFuse it would be sufficient to prioritise the local
On 11/15/06, Brian E. Fox <
>
> I think it's also necessary to allow control over the ordering of the
> overlay. Otherwise it's kinda random based on the way the dependencies
> are resolved isn't it?
>
> -----Original Message-----
> From: Matt Raible [mailto:
mraible@...]
> Sent: Tuesday, November 14, 2006 1:56 PM
> To:
dev@...
> Cc:
dev@...
> Subject: Re: [appfuse-dev] War plugin overlays: New plugin to handle
> transitive dependencies
>
> Just some thoughts on enhancements:
>
> It'd be nice if we could 1) get this into the war plugin and 2) add 3
> different modes:
>
> 1. Default - the way things are now, where dependencies aren't
> inherited. This would allow backwards compatibility and not suprise
> anyone.
>
> 2. Include Dependencies - excludes everything from WEB-INF/lib and
> includes all dependencies - making them available to all plugins as well
> (i.e. esp. IDEA, Eclipse and NetBeans).
>
> 3. Merge - has a way of allowing web.xml and other configuration files
> to be merged. Of course, it'd need certain include and exclude
> patterns.
>
> With #3, it may be possible to produce some sort of wars-as-plugins
> features where you could develop a small set of functionality and
> "merge" it into a larger application. This seems like a pretty simple
> way to do plugins. Of course, you'd probably have to create a pretty
> fancy XML parser/merger/munger.
>
> Thoughts? What are the chances of getting this plugin included in the
> war plugin?
>
> Matt
>
> On 11/11/06, Michael Horwitz <
mike.horwitz@...> wrote:
> > Hi,
> >
> > I have been helping out with the development of the AppFuse project
> > over the last month where we make heavy use of the war overlay feature
>
> > in the Maven war plugin. It is a really nifty feature!
> >
> > To get max power with war overlays I have developed the Warpath plugin
>
> > that allows projects to use war artifacts as fully fledged
> > dependencies. In
> > brief:
> >
> > 1) The contents of the /WEB-INF/classes directory in the war
> > dependency artifacts can be included in the project's classpath for
> > normal compile, etc tasks.
> > 2) Transitive dependencies from the war dependency artifacts become
> > available for use by other plugins, e.g. compile and ear - so no more
> > having to include all the dependencies when creating skinny wars!
> >
> > The plugin has now been actively used in the AppFuse project for the
> > last few months, and I feel it is at a point where it is both usable
> and stable.
> > Would the war plugin team be interested in including the warpath
> > functionality inside the war plugin? It would seem to be the most
> > natural place to host it.
> >
> > As a side issue one sticking point for us with war overlays has been
> > the overlay by timestamp for files included in the web project being
> > built. In a multi-web module project like AppFuse this has led to some
>
> > unpredictable behaviour when a file from a dependent war overwrites a
> > file in the war project being built. Although it is possible to
> > influence the behaviour of the overlay using dependentWarExcludes, it
> > is a maintenance heavy approach when many files are involved and
> > requires continual updates to the project's pom file.
> >
> > Would it be possible to include functionality, perhaps as a
> > configurable feature, in the Maven war plugin to automatically prefer
> > all files from the war project being built over those from dependent
> > war files regardless of file timestamp? I would be more than happy to
> > do the necessary work and submit a patch.
> >
> > Thanks
> >
> > Mike Horwitz
> >
>
>
> --
>
http://raibledesigns.com>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
dev-unsubscribe@... For additional
> commands, e-mail:
dev-help@...
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
dev-unsubscribe@...
> For additional commands, e-mail:
dev-help@...
>
>