ad your point 2)
For what i've experienced, the dependencies of a WAR
may only be derived if the actual project itself is of
type WAR too.

As opposite, the dependencies from a WAR imho must not
be derived if the actual project is e.g. of type EAR. 

Do we need any further distinction?

lg,
strub


--- Matt Raible <[EMAIL PROTECTED]> schrieb:

> 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]
> 
> 



                
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

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

Reply via email to