Skinny War Possible Solution?

[David Weintraub <qa...@gmail.com>]

I have been struggling with the Skinny War issue. The problem is that you
have to manually track your libraries in each war, then go through your ear
to get the libraries working. This is the anti-thesis of what Maven is
suppose to be doing.

I understand the complexities of the issue. When a project builds the wars,
it doesn't know what libraries each war will be dependent upon. When the ear
is built, it is too late for the ear to try to calculate what are the
duplicate jars.

However, I believe I found a possible solution to this issue. The solution
would be to create ultra-skinny wars which contain no jar files at all.
Instead, all jar files will be stored in the ear. It's not exactly the
solution we are looking for, but it does work.

What we would need is the directory location where the wars will store their
jar files and where the ear will pick up these jarfiles. Duplicates are
handled by the fact that since all the jars are in a single directory, if a
war downloads a jar that another war has already downloaded, the second war
will simply replace that jarfile with a duplicate jarfile. This could be
done with a property in the project's root pom.xml.

When a war is built, and this property is set, the war will download its
dependencies to this directory instead of putting them into the WEB-INF/lib
directory. When the ear is built, and this property is set, the ear project
will include the downloaded jars in this directory when the ear is built.

There will have to be changes in the maven-ear-plugin and the
maven-war-plugin to recognize this property. Plus, there may have to be
further configurations for stating whether this war is suppose to be skinny
or not, the changes in the classpath in the MANIFEST.MF file, etc. However,
I believe these would be relatively minor.

In the end, you eliminate the duplicate jars without having to go through
all sorts of manipulation in the dependencies settings of your wars and ear.

Do you think this will work?

-- 
David Weintraub
qazwart@gmail.com

Re: Skinny War Possible Solution?

[Jörg Schaible <jo...@gmx.de>]

David Weintraub wrote at Mittwoch, 14. Oktober 2009 00:00:

> On Tue, Oct 13, 2009 at 5:13 PM, Jörg Schaible
> <jo...@gmx.de>wrote:
> 
>> David Weintraub wrote:
>>
>> Too complicated, especially since you skip Maven's dependency version
>> resolution by this directory where you collect the wars.
>>
> 
> I don't see how I skip the dependency version resolution. The wars are
> still calculating those dependencies and tracking them in the MANIFEST.MF
> classpath and in the pom.xml they store in the META-INF directory.

You skip it in the ear.

>> For a skinny war don't configure the jar location and use
>> the "packagingExcludes" parameter to skip the webapp/WEB-INF/lib.
>>
>> In the ear declare now both artifacts. The jar will ensure that all
>> transitive deps are included also. If you do not use skinny wars, only
>> declare the war.
>>
> 
> This is the entire problem. I am manually doing all of this stuff that
> Maven was suppose to cure.

It does not have to for standard wars.
 
> We're building the ear, looking at the wars, figuring out the duplicates,
> tweak the poms, repeat and rinse.  Now, if we use a new version of a jar
> or add a new jar dependency, I have to start the whole process from
> scratch.
> 
> I'm told this problem stems from the fact that Maven treats all of my wars
> as separate projects when they build. They simply cannot communicate with
> each other. The ear builds after the wars, so it cannot clean up this
> mess.
> 
> The packagingExcludes is not a solution, but the symptom of the problem.

No, it simply prohibits the war plugin to build a standard war. With the
additional jar artifacts Maven will resolve the dependencies on its own for
the ear.
 
- Jörg


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

Re: Skinny War Possible Solution?

[David Weintraub <qa...@gmail.com>]

On Tue, Oct 13, 2009 at 5:13 PM, Jörg Schaible <jo...@gmx.de>wrote:

> David Weintraub wrote:
>
> Too complicated, especially since you skip Maven's dependency version
> resolution by this directory where you collect the wars.
>

I don't see how I skip the dependency version resolution. The wars are still
calculating those dependencies and tracking them in the MANIFEST.MF
classpath and in the pom.xml they store in the META-INF directory.


> For a skinny war don't configure the jar location and use
> the "packagingExcludes" parameter to skip the webapp/WEB-INF/lib.
>
> In the ear declare now both artifacts. The jar will ensure that all
> transitive deps are included also. If you do not use skinny wars, only
> declare the war.
>

This is the entire problem. I am manually doing all of this stuff that Maven
was suppose to cure.

We're building the ear, looking at the wars, figuring out the duplicates,
tweak the poms, repeat and rinse.  Now, if we use a new version of a jar or
add a new jar dependency, I have to start the whole process from scratch.

I'm told this problem stems from the fact that Maven treats all of my wars
as separate projects when they build. They simply cannot communicate with
each other. The ear builds after the wars, so it cannot clean up this mess.

The packagingExcludes is not a solution, but the symptom of the problem.

-- 
David Weintraub
qazwart@gmail.com

Re: Skinny War Possible Solution?

[Jörg Schaible <jo...@gmx.de>]

David Weintraub wrote:

> I have been struggling with the Skinny War issue. The problem is that you
> have to manually track your libraries in each war, then go through your
> ear to get the libraries working. This is the anti-thesis of what Maven is
> suppose to be doing.
> 
> I understand the complexities of the issue. When a project builds the
> wars, it doesn't know what libraries each war will be dependent upon. When
> the ear is built, it is too late for the ear to try to calculate what are
> the duplicate jars.
> 
> However, I believe I found a possible solution to this issue. The solution
> would be to create ultra-skinny wars which contain no jar files at all.
> Instead, all jar files will be stored in the ear. It's not exactly the
> solution we are looking for, but it does work.
> 
> What we would need is the directory location where the wars will store
> their jar files and where the ear will pick up these jarfiles. Duplicates
> are handled by the fact that since all the jars are in a single directory,
> if a war downloads a jar that another war has already downloaded, the
> second war will simply replace that jarfile with a duplicate jarfile. This
> could be done with a property in the project's root pom.xml.
> 
> When a war is built, and this property is set, the war will download its
> dependencies to this directory instead of putting them into the
> WEB-INF/lib directory. When the ear is built, and this property is set,
> the ear project will include the downloaded jars in this directory when
> the ear is built.
> 
> There will have to be changes in the maven-ear-plugin and the
> maven-war-plugin to recognize this property. Plus, there may have to be
> further configurations for stating whether this war is suppose to be
> skinny or not, the changes in the classpath in the MANIFEST.MF file, etc.
> However, I believe these would be relatively minor.
> 
> In the end, you eliminate the duplicate jars without having to go through
> all sorts of manipulation in the dependencies settings of your wars and
> ear.
> 
> Do you think this will work?

Too complicated, especially since you skip Maven's dependency version
resolution by this directory where you collect the wars. Let Maven do the
work, it handles the deps already. What we do with war projects now it to
set the package type as jar, set the target path of the jar plugin
to "target/webapp/WEB-INF/lib" and configure the war plugin with a
classifier bound to the package phase (webapp will be assembled in
target/webapp).

As result you will have two artifacts:
groupId:artifactId:version:jar
groupId:artifactId:version:classifier:war

For a skinny war don't configure the jar location and use
the "packagingExcludes" parameter to skip the webapp/WEB-INF/lib.

In the ear declare now both artifacts. The jar will ensure that all
transitive deps are included also. If you do not use skinny wars, only
declare the war.

BTW: We use this setup mainly for war overlays where we want to avoid to
redeclare all the transitive deps again.

- Jörg



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