Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Web Tools Project (WTP) » classpath listener
classpath listener [message #208377] Mon, 11 February 2008 08:44 Go to next message
Raster Mising name is currently offline Raster Mising name
Messages: 75
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
Re: classpath listener [message #208398 is a reply to message #208377] Mon, 11 February 2008 09:43 Go to previous messageGo to next message
Rob Frost is currently offline 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
>
>
>
>
Re: classpath listener [message #208507 is a reply to message #208398] Mon, 11 February 2008 23:52 Go to previous messageGo to next message
Raster Mising name is currently offline Raster Mising name
Messages: 75
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
Re: classpath listener [message #208543 is a reply to message #208507] Tue, 12 February 2008 10:05 Go to previous message
Rob Frost is currently offline 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
>
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:
  


Current Time: Thu Jul 31 13:50:17 EDT 2014

Powered by FUDForum. Page generated in 0.01660 seconds