War plugin overlays: New plugin to handle transitive dependencies

[Mike Horwitz]

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

[Brian E Fox]

Michael,

These sound like handy enhancements to have. I also have issues with the
ordering of the overlay because of the timestamps. I documented some of
it and the way we do it (with a very old war plugin version) here:
http://jira.codehaus.org/browse/MWAR-66

I would eventually like to enhance war to be able to support this
process if I ever get some time.

-Brian

-----Original Message-----
From: Michael Horwitz [mailto:mike.horwitz@...]
Sent: Saturday, November 11, 2006 6:32 AM
To: dev@...
Cc: dev@...
Subject: War plugin overlays: New plugin to handle transitive
dependencies

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



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

[Matt Raible-3]

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@...

[struberg]

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 <mraible@...> 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
> <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@...
>
>



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

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

[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@...

[Mike Horwitz]

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 <brianf@...> 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: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@...
>
>

[Brian E Fox]

We do it quite extensively now. The problem is that I'm now dependent on
an alpha war plugin that doesn't have the timestamp logic. I use the
dependency:unpack goal to unpack the artifacts in a known order (to
control order of inheritence) into the war folder before the war plugin
starts. Then the war plugin will copy files over so local files always
win.

We have our code architected such that there is a common ui template
that every war "inherits." Then we may have several ui modules that can
be reassembled into a final war package. (not always 1:1, sometimes a UI
can be included in several packages and all assemblies almost always
have multiple Uis). For unit testing purposes, all the ui's including
the common template are deployable standalone. When I build the war in
each of these modules, I actually build 2: I "normal" one for standalone
deployment, and one reusable one that doesn't contain the jars. The
problem is that since maven won't transitively inherit the war's
dependencies, we manually have to make sure that the assembly project
has all the direct dependencies copied from each of the UI poms.

-----Original Message-----
From: Michael Horwitz [mailto:mike.horwitz@...]
Sent: Wednesday, November 15, 2006 9:31 AM
To: Maven Developers List
Cc: matt@...; dev@...
Subject: Re: [appfuse-dev] War plugin overlays: New plugin to handle
transitive dependencies

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 <brianf@...> 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: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@...
>
>

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

[BenTatham]

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.