Interesting. Does it periodically scan for changes, or does it hook in
with the underlying file system notifications to receive changes? I
believe that the Win32 resources API has the ability to pick up
changes; it would be good if that worked for other systems too.
Does it do the reverse,
I misread Jeff's earlier post. The template is fine. I agree with Jeff,
forbidden access should always be an error, it will never work at runtime.
Thanks for the tip on deprecated methods John. This means we have to
javadoc to internal classes to add the @deprecated tag? Not really a big
can you point out a precise problem? I had used an older version of the
JDT UI prefs template (I've now updated the project) but organizing
imports on the code did not change anything (ie.., they were properly
organized).
Jeff
Pascal Rapicault/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL
The issue is on Mac the SWT event loop must run on the main thread. That
is a pretty hard thing to do in an OSGi environment. When a bundle is
activated it has no idea what thread is activating it. Even if the bundle
knew the activating thread was the main thread it would never want to
Interesting. So it might be that the coding practice project setup
instructions need to be tweaked. I worked with Tom last night to clean
things up and setup templates for both the JDT Core and UI related
preferences. The assumptoin on my part was that if these pref files were
simply copied
It depends how you are launching it. If you've got 'osgi.noExit=true'
then I'd expect to see that behaviour. Are you running with eclipse
-application ? If so, I'd expect that when your application
returns from the run() method, it would shut down the framework. Do
you know you are returning
Thanks Tom,
That was exactly the information that I needed.
Patrick
On Aug 30, 2007, at 4:34 PM, Thomas Watson wrote:
The issue is on Mac the SWT event loop must run on the main thread.
That is a pretty hard thing to do in an OSGi environment. When a
bundle is activated it has no idea
looking through the artifact repo code I noticed that the way it is now,
MirrorRequests get/are given a RequestHandler and then that is used to do
the actual file transfer. Is there a usecase that drives the repo
communication policy to be externally defined? That is, is there a reason
that
