Eclipse Community Forums: ServerTools (WTP)

Help

Home

Home » Language IDEs » ServerTools (WTP) » classpath listener

Show: Today's Messages :: Show Polls :: Message Navigator

classpath listener [message #208377]

Mon, 11 February 2008 13:44

Raster R

Messages: 77
Registered: July 2009

Member

Hi,

I am creating a plugin.
In this I am modifying the build class path using JavaCore.
This is working fine.

But I am expecting the changes to be mirrored in the file
".settings\org.eclipse.wst.common.component".

This is not working fine.

When I edit the ".classpath" file manually and cause the same build path
changes the file ".settings\org.eclipse.wst.common.component" reflects the
changes.

It appears there is a listener in the background which is not getting
invoked when I edit the build class path using JavaCore. How can I raise
an event to trigger the listener?

Raster

Report message to a moderator

Re: classpath listener [message #208398 is a reply to message #208377]

Mon, 11 February 2008 14:43

Rob Frost

Messages: 64
Registered: July 2009

Member

hi Raster,

There indeed is an IElementChangedListener
(org.eclipse.jst.j2ee.refactor.listeners.J2EEElementChangedL istener in the
org.eclipse.jst.j2ee plugin) that automatically updates the required
mappings in .settings/org.eclipse.wst.common.component in response to Java
src path additions/removals/changes.

I'm not exactly clear on the type of change you are making via the JDT API
but I have personally encountered instances in the past where the src path
change delta was merged into another delta and lost (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=121431 for details of cases
where this can happen). This delta merging behavior prevents the
J2EEElementChangedListener from ever seeing the src path event and making
the update to the component file.

If you are making your buid path change in a context that is impact by such
a delta merge, then you will need to explicitly execute the required
IVirtualFolder.createLink() or removeLink() methods to trigger the component
file updates.

If you do not believe a delta merge is happening and the event should be
getting processed, please open a bugzilla with details.

Hope this helps,

-Rob

"Raster" <crscca@yahoo.co.in> wrote in message
news:5092c5e00e7480f9beea01f7cd17532d$1@www.eclipse.org...
> Hi,
>
> I am creating a plugin.
> In this I am modifying the build class path using JavaCore.
> This is working fine.
>
> But I am expecting the changes to be mirrored in the file
> ".settings\org.eclipse.wst.common.component".
>
> This is not working fine.
>
> When I edit the ".classpath" file manually and cause the same build path
> changes the file ".settings\org.eclipse.wst.common.component" reflects the
> changes.
>
> It appears there is a listener in the background which is not getting
> invoked when I edit the build class path using JavaCore. How can I raise
> an event to trigger the listener?
>
>
>
> Raster
>
>
>
>

Report message to a moderator

Re: classpath listener [message #208507 is a reply to message #208398]

Tue, 12 February 2008 04:52

Raster R

Messages: 77
Registered: July 2009

Member

Hi,

Thanks for your help.
I was able to sort it out after that.
Now I NEED ANOTHER HELP> How can I ensure that when I update the classpath
using the code the listeners will not kick in for for a specific update.

I have two updates to make to the build path.
Update 1 should reflect in the
".settings\org.eclipse.wst.common.component" file.
Update 2 is done after update1. Update 2 should not reflect in
".settings\org.eclipse.wst.common.component" file.

R

Report message to a moderator

Re: classpath listener [message #208543 is a reply to message #208507]

Tue, 12 February 2008 15:05

Rob Frost

Messages: 64
Registered: July 2009

Member

No simple answer for this one.

The listener is designed to update the mappings in
org.eclipse.wst.common.component for all Java src path changes that occur in
WTP projects. A hook to enable extenders to control this behavior does not
currently exist (there is a mechanism to optionally disable the automatic
refactoring on project rename/delete but a need for finer grained control
over the Java src folder refactoring has not previously been seen).

Depending on the nature of the change you are making, there may be event
generation side effects you could take advantage of (e.g. the delta merge)
to pervent the listener from responding to the change, however, relying on
these would be risky and not be recommended. The alternative would be to
revert the automatic component file change via the IVirtualFolder API after
you make build path update; the listener spawns a job to handle the
component file update so you would need to wait for the currently executing
jobs in that family (defined in J2EEElementChangedListener) to complete
before attempting the revert.

You may want to go ahead and open a bugzilla for your use case to capture
the details and cover the potential addition of a mechanism similar to
IOptionalRefactorHandler.

-Rob

"Raster" <crscca@yahoo.co.in> wrote in message
news:1087f4fc4046e7658c14b5354ed25c27$1@www.eclipse.org...
> Hi,
>
> Thanks for your help.
> I was able to sort it out after that.
> Now I NEED ANOTHER HELP> How can I ensure that when I update the classpath
> using the code the listeners will not kick in for for a specific update.
> I have two updates to make to the build path.
> Update 1 should reflect in the
> ".settings\org.eclipse.wst.common.component" file.
> Update 2 is done after update1. Update 2 should not reflect in
> ".settings\org.eclipse.wst.common.component" file.
>
> R
>

Report message to a moderator

Previous Topic:	import JSP from an other project in the build path
Next Topic:	Getting the action that contributed a facet wizard page

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 08:13:39 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter