[news.eclipse.webtools] Re: How to make Eclipse put jars into WEB-INF/li

[Larry Isaacs <Larry.Isaacs@xxxxxxx>]

Mauro Molinari wrote:
> Larry Isaacs ha scritto:
> > For me, the selected jars stayed checked.  As you have surmised, just 
> > including the jars in the build path doesn't by itself mark them for 
> > inclusion in WEB-INF/lib.  Using the "J2EE Module Dependencies" page 
> > is the correct approach.  However, it's not clear why they won't stay 
> > checked.  You might check the Error Log view to see if something 
> > related is present.  You could also try creating a new project, copy 
> > the lib directory, and see if you can duplicate this issue in the new 
> > project. If not, you can compare the ".classpath" and 
> > ".settings/org.eclipse.wst.common.component" files to see what the 
> > differences are.  You could also try removing the jars from build path 
> > and adding them on the J2EE Module Dependencies page, which will 
> > automatically include them on the build path as well as include them 
> > in WEB-INF/lib.
>
> Hi Larry,
> just for my curiosity. In this post you're suggesting to add JARs to 
> classpath and then to check them in J2EE Module Dependencies to have 
> them deployed to WEB-INF/lib.

Actually, don't add them to the  build path.  Just add them on the J2EE 
Module Dependencies page and they will be included in the build path in 
addition to WEB-INF/lib.  These jars will also appear in the "Web App 
Libaries" library.

> In my own experience, however, I learnt to follow a different approach. 
> I simply put my JARs in WEB-INF/lib of WebContent: those JARs are 
> automatically added to classpath (through Web App Libraries) AND 
> deployed to WEB-INF/lib (I don't know if they are also exported to the 
> WAR, as David asked). I prefer this approach for two main reasons:
> 1) it sounds more clean to me: I think the "Web App Libraries" Library 
> in build path was actually designed for this purpose

This approach is perfectly fine.  The main disadvantage is that if you 
have a set of webapps, you duplicate the jars in each project.  Having 
the projects use the same jars can be a plus in certain situations, 
though it means the projects are no longer completely self contained.

> 2) the J2EE Module Dependencies property page is almost unusable: it's 
> full of bugs, because sometimes things don't get checked, sometimes they 
> don't get unchecked and sometimes there seem to be synchronization 
> problems between that view and the Java Build Path property page.

I've never had a problem with this feature and would be interested in 
trying to figure out what brings your issues about.  I may not encounter 
problems because I work on "development tooling", which means I work on 
improvements to Eclipse that will help with with Web application 
development.  I don't work on webapps long term.  Thus, I'm typically 
creating new projects rather than migrating a project through various 
versions of Eclipse and WTP, where maybe something a little "odd" about 
the project may cause an issue like you have experienced.  It also means 
I don't work on web projects with a team, where one team member changes 
a project in source control in a way that is only valid on that 
developer's system and causes subtle problems for others in the team.

> Because of 1), in the past I wondered what J2EE Module Dependencies was 
> made for... then I understood that it's useful when you have 
> inter-project dependencies: when you define a Dynamic Web Project to 
> depend on another project, that project is used to build the Dynamic Web 
> Project, but its classes are not deployed to WEB-INF/lib of the Dynamic 
> Web Project. Adding the required project to J2EE Module Dependencies 
> causes WTP to make a JAR of it to deploy in WEB-INF/lib.
>
> Correct me if I'm wrong in my approach: I would appreciate your opinion 
> on this very much.

This is a feature that needs to work.  If you know of use cases where it 
doesn't, please open a bug report in Bugzilla so it can be tracked.  If 
you are happy doing things the current way, then I wouldn't bother 
changing.  However, if you would benefit by this feature not having 
problems in your use case, then it might be worth investigating.

Cheers,
Larry

> Mauro.