Re: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies

[Matt Raible <mr...@gmail.com>]

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 <mi...@gmail.com> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: War plugin overlays: New plugin to handle transitive dependencies

[BenTatham <be...@nanometrics.ca>]

We are currently switching over to Maven from Ant, so I hope my comments are
too newbie-ish.

I like these ideas...especially #3.  We have a hiearchy of libraries that
are actually wars because we need to do jspc in order to test things
completely.  Also, we had been using xdoclet directly on the source code to
generate the servlet mappings prior to using Maven, but now we don't have
the source in each depending library/project, so we can't do that.  So we
need a solution to merge web.xml.  I know xdoclet can insert
servlet-mappings into an existing web.xml, so really, that is all a web.xml
merger would have to do too.  It would not have to be a fully text xml
merger, just the relevant components, and you could configure which
components of the web.xml you want to be merged and which you don't.  

Anyway, for now, does anyone have any ideas on how to merge the web.xml's?  

I have a couple of ideas, but neither make me very happy...
1) Make a copy of the web.xml that is dependency specific in the dependent
project, and then do the merge myself once the overlay is done.  This leaves
an extra file in the war of the library though, which is messy.  
2) Depend on the sources of my libraries so I can run xdoclet again over the
whole webapp.

-Ben


Matt Raible-3 wrote:
> 
> 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.
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/War-plugin-overlays%3A-New-plugin-to-handle-transitive-dependencies-tf2612629s177.html#a8412448
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies

[Mark Struberg <st...@yahoo.de>]

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 <mr...@gmail.com> 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
> <mi...@gmail.com> 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@maven.apache.org
> For additional commands, e-mail:
> dev-help@maven.apache.org
> 
> 



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org