Home » Language IDEs » ServerTools (WTP) » Classpath entry will not be exported or published.
| |
| Re: Classpath entry will not be exported or published. [message #191723 is a reply to message #191707] |
Tue, 24 April 2007 17:32   |
 Ivan Biddles
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Dear Rob,
Thank you for your quick reply and all the good data.
I just want to make sure I understand what you are saying and that I am
doing this right.
I have some projects that run on both the server and in an RCP client.
One, for example, has a dependency on commons-codec and commons-httpclient
so, for client purposes, I bundled those two JAR files into the project.
That works fine on the client.
My overall master server project was originally defined as an ordinary
Java project and the deployment was pieced together by exporting the main
WAR file (via Sysdeo's plug-in) and then the dependent projects were
exported to Tomcat/lib as JAR files separately.
This had several problems not least of which was that I was not building a
comprehensive WAR file with all the dependent JAR files in it. That was
when I switched to making it a dynamic web project and ran into these
warnings.
The reason that it all builds correetly, BTW, is that I also have the
codec and httpclient JARs defined in the server project.
The ideal would be if the JAR files included in the common project could
get deployed into the WAR file automatically without having to specify
them also in the server project. I take it that is not a possibility
though.
So with the next I-build, if I understand you correctly, I will be able to
keep the embedded JAR files in the common project, so that it works on the
client, but also in the server project and build the server project
without getting these warnings.
Is that about right?
Best wishes, Ivan
|
|
| |
| Re: Classpath entry will not be exported or published. [message #191739 is a reply to message #191730] |
Wed, 25 April 2007 03:52 |
Ivan Biddles
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Dear Rob,
> Assuming I understand the use case correctly, this is possible
> now (usingM6) and is exactly what will happen if you select these
> Jar cp entries as dependencies in the "J2EE Module Dependencies"
> UI: they will get deployed in the WEB-INF/lib dir of the WAR.
> Once you select them as module dependencies, the warnings will
> disappear (since WTP now knows that they will be available at
> runtime).
This sounds great. I apologize that this a long post but it seems that
there may be something wrong so I have documented everything I did and my
conclusions.
I do want to run through my use case one more time as this seems an
important capability and this discussion may help others reading this.
Using just two projects to keep it simple (I actually have 8 to 10 common
projects plus a server project):
1. I have a common project (let's call it "base", because it contains some
common base classes) that is to run as a plug-in in an RCP client but it
is also needed as a JAR file on the server. It includes two other jar
files -- commons-httpclient.jar and commons-codec.jar.
2. The server project (let's call it "server") is a project that is to
create a WAR file for deployment in Tomcat 6.0.10.
3. Originally, "server" was just a plain old Java project which I
converted to a dynamic web project because I wanted a more direct way of
exporting a WAR file. (Previously I had to remember to export "base" and
the others each time as well as the WAR file.)
4. I opened the properties for "server" and marked "base" as a dependency
in the J2EE Module Dependencies tab.
5. This is when I first got the warnings:
Classpath entry /base/commons-codec.jar will not be exported
or published.
Classpath entry /base/commons-httpclient.jar will not be exported
or published.
6. It wasn't a problem (except that there were close to 100 such warnings)
because I put the two JAR files in the "server" project to ensure they
were included in the WAR file, and they were.
So that is the basic use case. I need the "base" project to be included in
the "server" project without the warnings and to also be deployable as a
plug-in JAR file for the client.
Here is the new problem -- I modified a class in "base" and had to
redeploy.
The new WAR file generated from the "server" project was fine and included
"base" and its changes. However, when I exported "base" as a "deployable
plugin or fragment" it is no longer recognized by Eclipse as a plug-in.
When I looked into it I found that the MANIFEST.MF file is no longer
exported in plug-in manifest format but as a two-line plain JAR manifest
(just Manifest-version and Class-Path). Naturally, Eclipse ignores it as a
plug-in.
The only thing I have done to "base", other than the one or two-line
source code change, was to make it a dependency of "server". When I did
that several things appeared to happen:
a. A META-INF directory and MANIFEST.MF file (of the two-line variety)
were added to my src directory
b. A .settings directory was added with three files in it:
- org.eclipse.wst.common.component file
- org.eclipse.wst.common.project.facet.core.xml
- org.eclipse.jdt.core.prefs
The existing plug-ins that I did not add as a "server" dependency still
work as plug-ins and do not have a .settings directory nor a META-INF in
the src directory.
I suspected that the new MANIFEST.MF file (in src) overwrites the plug-in
manifest in the exported plug-in JAR file, so I renamed the new
MANIFEST.MF file to MANIFEST.MF2 and, sure enough, both appear in the
plug-in JAR file ... and the plug-in is now a plug-in once more.
If I then go back to the "server" and export it as a WAR file, with the
new file still named MANIFEST.MF2, the WAR file is generated just as
before.
So I guess one question is what is the purpose of the added manifest file?
It breaks the plug-in build but the server build works whether it is there
or not, so maybe it just be omitted when a project is added as a
dependency.
Best wishes, Ivan
|
|
| | | | | | |
| Re: Classpath entry will not be exported or published. [message #191953 is a reply to message #191848] |
Wed, 02 May 2007 17:40 |
Rob Frost
Messages: 64
Registered: July 2009 |
Member |
|
|
hi Ivan,
See below.
-Rob
"Ivan Biddles" <ivanb@scientology.net> wrote in message
news:6045f5c0858f73f412cda8816d017738$1@www.eclipse.org...
> Dear Rob,
>
> You have been amazingly helpful. I upgraded to the I20070426 build of WTP
> and its dependencies and the problem was fixed exactly as you said it
> would be.
>
> I really like WTP as a product, so I hope you don't mind me asking just a
> few more questions so that I and others can get it working the way I/they
> need.
>
> 1. How do I get rid of "classpath entry" warnings for the various
> containers?
>
> I currently have:
>
> org.eclipse.pde.core.requiredPlugins 21 warnings
> org.eclipse.jdt.junit.JUNIT_CONTAINER/3.8.1 11 warnings
>
> I tried the same <attributes> tag trick, but that resulted in errors.
Note that as of this week's I-build, you no longer will need to manually
edit the .classpath file to add the dependency attribute for the case of a
Utility project referenced only by a dynamic web project. Although the "J2EE
Module Dependencies" UI is not yet displayed for these projects, you can
enable the dependency attribute for these cp entries via a new QuickFix on
the warning that is generated for them and you can remove them directly via
the Java Build Path UI (select the "Publish/export dependency" attribute
under the cp entry and select "Remove")
>
> Invalid classpath component dependency ...
> The associated classpath container cannot be included in the
> published/exported module
>
In this case, I think the warning is appropriate: you have a deployable
project which potentially has class dependencies on libraries that may not
be available on the server.
An extension point is now available to filter out certain classpath
containers from the set of classpath entries that are considered for
potential inclusion in the published/exported structure of the module (the
warning therefore won't be generated for these), however, this is really
only useful for adopters with custom container implementations (the PDE and
JUnit container are not among the set that are automatically filtered out by
WTP).
Aside from just disabling the "Classpath Dependency Validator" (via project
Validation preferences; not recommended since important errors would also be
lost), you cannot currently suppress that warning; I've added you to the
bugzilla that covers the addition of preferences to support that level of
validator granularity: https://bugs.eclipse.org/bugs/show_bug.cgi?id=185112
> 2. If I wrongly mark a project as a dependency, and it is changed into a
> utility project, how do I revert it back to being an ordinary project?
That is not currently possible (at least in an automated fashion via WTP;
use of source control to revert to a previous version would work), see the
following bugzilla for more information on this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=141056
> 3. My development machine is not attached to the internet and will not be.
> Now that I have turned my "server" project into a dynamic web project I
> get warnings:
>
> The file cannot be validated as the host "www....."
> is currently unreachable.
>
> How do I turn off that warning?
See the following bugzilla for more information on this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=104413; also, the JEE related
schemas and DTD were have just been bundled with WTP.
> 4. I get a similar problem with the WSDL validator. How do I turn that
> off?
>
> WS-I: A problem occured while running the WS-I WSDL conformance
> check:
> org.eclipse.wst.wsi.internal.analyzer.WSIAnalyzerException:
> The file WS-I Test Assertion Document (TAD) document was either
> not found ...
>
> 5. Is there somewhere that I can read more about the way this all works,
> especially the .classpath file and the classpathentry tag? I have read
> through the on-line help and haven't found the depth of information you
> have provided.
Documentation for the classpath entry publish/export support does not yet
exist in the WTP builds (the M6 New and Noteworthy includes an outline of
the funtionality). I've cc'd you on the following bugzilla which covers the
addition of these docs (a more detailed description is in the bugzilla
comments): https://bugs.eclipse.org/bugs/show_bug.cgi?id=185176
> Thank you again for all your help. Best wishes, Ivan
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 05:19:04 GMT 2024
Powered by FUDForum. Page generated in 0.04369 seconds |
] 
Search
Help
Register
Login
Home
