Home » Language IDEs » ServerTools (WTP) » J2EE Module Dependencies not persisting
|
| Re: J2EE Module Dependencies not persisting [message #174320 is a reply to message #174218] |
Thu, 13 July 2006 10:08   |
 Frits Jalvingh
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
I have the same problem and have reported this *several times* in
Bugzilla and this newsgroup. The whole deployment mechanism in the
current WTP is a complete trainwreck and worse- it is designed as such
!? See for instance https://bugs.eclipse.org/bugs/show_bug.cgi?id=138648
with the "Excellent" comments.. I am really surprised by all this; the
Eclipse Platform seems well thought out (and the code looks good) but
this part of WTP is VERY badly designed and the code is pretty awful.
This whole newsgroup is *filled* with people bitten by this problem but
nothing happens.
In the current version you need to add every project which has compiled
code (a source directory) to the J2EE dependencies. This causes (ONLY)
the compiled output of the project to be JARred and placed in
WEB-INF/lib. In addition it CHANGES the "dependent" project's metadata -
it adds a Utility Project facet (${DEITY} knows why, and I really hate
it that projects that are only USED within WTP are suddenly changed) so
don't forget to commit the dependent projects 8-(
And as you noticed also: all of the jars in the dependencies are of
course not deployed, otherwise it would work and that was appearently
not a design criteria. You need to walk all of the project and add all
of their jars by hand. Which is a project maintenance nightmare but who
cares.
If they would have designed for UNusability they could NOT have done a
better job.
In addition all of the latest versions of the WTP are one big bug as far
as deployment is concerned, so getting this to work is almost
impossible. The main bugs are:
- Changes to the J2EE dependencies are not persisted (most of the time)
- Changes seem to be persisted but are not visible in the page
- Jars added get dropped from time to time
- Changes to the page are not picked up by the deployed projects. Often
one needs to exit Eclipse and restart to get changes to be seen at all.
If you really want to get this to work - the *only* way I have ever
gotten any reasonally big project to work is by manually editing the
..settings/org.eclipse.wst.common.component (or .settings/.component file
for older versions) and adding the dependencies there and leave the J2EE
properties page alone because it *will* fsck up the file.
As an alternative (which at least WORKS all of the time) is to add
Apache Tomcat oid as a project to your workspace and create a .java file
which starts it inline. In this way you can easily run, debug and code
without ever using the deployment crap again.
Good luck...
Frits Jalvingh
Greg Adams wrote:
> I'm using the Callisto release. I have a project consisting of lots of
> base classes and lots of jars that are on the project's build path and
> exported on the Java Build Path -> Order and Export tab. I also have a
> dynamic web project that references this project on its build path.
> I'm trying to cause the base level project to be jarred up and deployed
> with the web project. Also the jars that are exported by the base level
> project need to be deployed with the web project. Some searching around
> has led me to try adding the base level project to the J2EE Module
> Dependencies tab of the web project's properties page. This causes the
> base level project to be jarred up and deployed with the web project,
> but not the jars exported by the base level project. I've also tried the
> "Add JARS..." button on the J2EE Module Dependencies tab and added the
> base level project's jars to the dependencies list, and ultimately this
> does work, but should I really need to do this? Shouldn't exported JARS
> from the base level project be included automatically? Or at least
> shouldn't there be some way to have these JARS picked up?
>
> Also, none of my selections are apparent the next time I open the J2EE
> Module Dependencies tab. Nothing is selected. I can only tell what's
> selected by viewing the .components file in the .settings directory. If
> I try to add something to the J2EE Module Dependencies and don't select
> what was already selected, the old selections are lost (i.e. I have to
> make all my module selections in one shot).
>
> Is anyone else having problems with this? Is there a bug entered already?
>
|
|
|
| Re: J2EE Module Dependencies not persisting [message #174485 is a reply to message #174218] |
Fri, 14 July 2006 18:10 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
Greg,
Maybe this bug covers your problem:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=148533
With WinXP, JDK 1.5.0_07, and the Callisto release, I'm not seeing the
problem using the procedure mentioned in the bug. There may be more to
triggering the bug than just what is documented in the bug.
It would be a help if you could create a new workspace and see if you
can duplicate the error with the procedure specified. If so, then
attach a zip of the two projects to the bug. Hopefully the missing
detail can be discovered and the bug fixed. Thanks.
Cheers,
Larry
Greg Adams wrote:
> I'm using the Callisto release. I have a project consisting of lots of
> base classes and lots of jars that are on the project's build path and
> exported on the Java Build Path -> Order and Export tab. I also have a
> dynamic web project that references this project on its build path.
> I'm trying to cause the base level project to be jarred up and deployed
> with the web project. Also the jars that are exported by the base level
> project need to be deployed with the web project. Some searching around
> has led me to try adding the base level project to the J2EE Module
> Dependencies tab of the web project's properties page. This causes the
> base level project to be jarred up and deployed with the web project,
> but not the jars exported by the base level project. I've also tried the
> "Add JARS..." button on the J2EE Module Dependencies tab and added the
> base level project's jars to the dependencies list, and ultimately this
> does work, but should I really need to do this? Shouldn't exported JARS
> from the base level project be included automatically? Or at least
> shouldn't there be some way to have these JARS picked up?
>
> Also, none of my selections are apparent the next time I open the J2EE
> Module Dependencies tab. Nothing is selected. I can only tell what's
> selected by viewing the .components file in the .settings directory. If
> I try to add something to the J2EE Module Dependencies and don't select
> what was already selected, the old selections are lost (i.e. I have to
> make all my module selections in one shot).
>
> Is anyone else having problems with this? Is there a bug entered already?
>
|
|
|
| Re: J2EE Module Dependencies not persisting [message #174723 is a reply to message #174485] |
Mon, 17 July 2006 20:36 |
Greg Adams
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
True, if I simply followed the procedure, it didn't happen. I had to
fiddle around a bit to get it to happen, and I think this shed some light
on what's really causing the problem. There's some kind of conflict
between the Java Build Path "Projects" settings and the J2EE Module
Dependencies pages.
Steps to reproduce:
1. Create a Java Project
2. Create a Dynamic Web Project
3. Add the Java Project from Step 1 to the Build Path under Projects for
the Dynamic Web Project created in Step 2.
4. Add the Java Project from Step 1 to the J2EE Module Dependencies for
the Dynamic Web Project created in Step 2.
5. Open properties again and inspect the J2EE Module Dependencies tab. The
Java Project is no longer selected.
6. If you deselect the Java Project on the Build Path page and hit ok,
then reopen the properties and inspect the J2EE Module Dependencies tab,
the Java Project is once again selected.
Note: If you add the Java Project as a J2EE Module Dependency first, hit
Ok, then go back to the Build Path properties page, and try to add the
Java Project as a build path entry, you get an error message "Build path
contains duplicate entry: 'Java Project' for project".
So, it appears that adding a project as a J2EE Module Dependency causes it
to be added as a Build path entry automatically. J2EE Module dependencies
and build path projects entries should be mutually exclusive, and the J2EE
Module dependency property page should check to see whether the project is
already added as a Build Path entry and handle it more intelligently.
I've got the two projects exhibiting this problem zipped up, but I can't
attach anything, since I'm using the web interface to the newsgroup. If
you follow these steps, you should be able to reproduce it I think. Let me
know if you still can't.
This will still not address the problem of being able to deploy jars from
a module dependency through the J2EE Module dependencies mechanism, which
IMO is an extremely serious shortcoming. Adding each JAR manually from
each dependent project is not something I'll be planning on doing anytime
soon. In my projects there are hundreds of JARS exported by included
projects that need to be deployed with the Web Application, and
maintaining the dependencies would be a nightmare in WTP.
> Greg,
>
> Maybe this bug covers your problem:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=148533
>
> With WinXP, JDK 1.5.0_07, and the Callisto release, I'm not seeing the
> problem using the procedure mentioned in the bug. There may be more to
> triggering the bug than just what is documented in the bug.
>
> It would be a help if you could create a new workspace and see if you can
> duplicate the error with the procedure specified. If so, then attach a zip
> of the two projects to the bug. Hopefully the missing detail can be
> discovered and the bug fixed. Thanks.
>
> Cheers,
> Larry
|
|
|
| Re: J2EE Module Dependencies not persisting [message #174763 is a reply to message #174723] |
Tue, 18 July 2006 15:04 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
Thanks Greg. This clarifies the problem/bug. I just encountered it
myself with respect to Dynamic Web Projects migrated from WTP 1.0.x.
In WTP 1.0.x, the J2EE Module Dependencies were added to the Java build
path in addition to being included in the ".components" file, with the
checkbox state detection depending on this. The WTP 1.0.x Web App
Libraries container didn't include these dependencies.
In WTP 1.5, the Web App Libraries container does try to include these
dependencies, but doesn't add new dependencies if they are already on
the build path. The checkbox state detection in WTP 1.5 depends on the
jar being present in Web App Libraries, so it is left unchecked in this
situation. I'll make sure there is something in Bugzilla to address
this. Bug 148533, may be the one.
With respect to exported jar handling, feel free to add your use case to:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=138648
Or at least add yourself as a CC since this is likely to be the bug
where this issue will be addressed.
Cheers,
Larry
Greg Adams wrote:
> True, if I simply followed the procedure, it didn't happen. I had to
> fiddle around a bit to get it to happen, and I think this shed some
> light on what's really causing the problem. There's some kind of
> conflict between the Java Build Path "Projects" settings and the J2EE
> Module Dependencies pages. Steps to reproduce:
>
> 1. Create a Java Project
> 2. Create a Dynamic Web Project
> 3. Add the Java Project from Step 1 to the Build Path under Projects for
> the Dynamic Web Project created in Step 2.
> 4. Add the Java Project from Step 1 to the J2EE Module Dependencies for
> the Dynamic Web Project created in Step 2.
> 5. Open properties again and inspect the J2EE Module Dependencies tab.
> The Java Project is no longer selected.
> 6. If you deselect the Java Project on the Build Path page and hit ok,
> then reopen the properties and inspect the J2EE Module Dependencies tab,
> the Java Project is once again selected.
>
> Note: If you add the Java Project as a J2EE Module Dependency first, hit
> Ok, then go back to the Build Path properties page, and try to add the
> Java Project as a build path entry, you get an error message "Build path
> contains duplicate entry: 'Java Project' for project".
>
> So, it appears that adding a project as a J2EE Module Dependency causes
> it to be added as a Build path entry automatically. J2EE Module
> dependencies and build path projects entries should be mutually
> exclusive, and the J2EE Module dependency property page should check to
> see whether the project is already added as a Build Path entry and
> handle it more intelligently.
>
> I've got the two projects exhibiting this problem zipped up, but I can't
> attach anything, since I'm using the web interface to the newsgroup. If
> you follow these steps, you should be able to reproduce it I think. Let
> me know if you still can't.
> This will still not address the problem of being able to deploy jars
> from a module dependency through the J2EE Module dependencies mechanism,
> which IMO is an extremely serious shortcoming. Adding each JAR manually
> from each dependent project is not something I'll be planning on doing
> anytime soon. In my projects there are hundreds of JARS exported by
> included projects that need to be deployed with the Web Application, and
> maintaining the dependencies would be a nightmare in WTP.
>
>> Greg,
>>
>> Maybe this bug covers your problem:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=148533
>>
>> With WinXP, JDK 1.5.0_07, and the Callisto release, I'm not seeing the
>> problem using the procedure mentioned in the bug. There may be more to
>> triggering the bug than just what is documented in the bug.
>>
>> It would be a help if you could create a new workspace and see if you
>> can duplicate the error with the procedure specified. If so, then
>> attach a zip of the two projects to the bug. Hopefully the missing
>> detail can be discovered and the bug fixed. Thanks.
>>
>> Cheers,
>> Larry
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:01:29 GMT 2024
Powered by FUDForum. Page generated in 0.03816 seconds |
] 
Search
Help
Register
Login
Home
