It would be nice! In AppFuse only one war is ever overlayed. I am guessing
here, but would imagine that projects that overlay more than one war will be
pretty rare. For AppFuse it would be sufficient to prioritise the local
files over those coming in from the overlay, which is a good deal simpler
than overlay ordering? Does anyone have a specific need to overlay more than
one war dependency?

On 11/15/06, Brian E. Fox <[EMAIL PROTECTED]> wrote:

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:[EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 1:56 PM
To: [EMAIL PROTECTED]
Cc: [email protected]
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to