Re: [ve-dev] About ClassPathContainer

[Rich Kulp <richkulp@xxxxxxxxxx>]

"Janak Mulani" <janak.mulani@xxxxxxxxx>
Sent by: ve-dev-admin@xxxxxxxxxxx

10/06/2004 12:35 PM

Please respond to
ve-dev

To	<ve-dev@xxxxxxxxxxx>
cc
Subject	[ve-dev] About ClassPathContainer

Hello,

I have implemented ULCContainer, ULCContainerInitializer and
ULCContainerWizardPage to enable end users to add ULC libraries to
ULCContainer.

I have the following questions:

1. ULCContainerWizardPage is an extension for <extension
point="org.eclipse.jdt.ui.classpathContainerPage">

In the finish() method I would like to access the Java Project on which
the
Container is being set.

How can we get access to the current project?

>>> Have your IClasspathContainerPage also
implement IClasspathContainerPageExtension. There is a method on that interface
that gets called giving you the Java project that the container is for.
>>>

2. In the WizardPage we let the users choose jar files to be added to the
container. This works fine the first time. Now if a user wants to replace
one jar in the container with another, the user brings up the
ULCContainerWizardPage by selecting the "configure" menu and
selects the jar
file to replace an existing one. I then replace the jar file in the
ULCContainer class. However, this is not reflected on the project. The
user
has to close and restart Eclipse to be able to see the new jar file. Is
there a better way of doing this?

>>>The configure wizard should not change
the ULCContainer itself. It just returns a new container classpath entry
with a path in the classpath entry set up to tell it what to do, like ("/ulc.ulccontainer/something/somethingelse").
Here /something/somethingelse tells either
the initializer or the container itself what to do.


This is the order of things that happen when you configure:

1) in finish you put in to the selection a new classpath
container entry that has the new path in it.
2) later it will call the classpath container initializer
for you to create a brand new classpath container with this new path
3) the brand new container (the old one is thrown
away) will take the path and create the library classpath entries that
are necessary.
And now they will show.

As an example, take a look at our, in the 1.0.1 code,
SWTContainerInitializer, SWTContainer, and SWTContainerWizardPage. In the
wizard page we can create two types of container classpath entries, one
is the path "/SWTContainer" the other is the path "/SWTContainer/JFACE".
The SWTContainerInitializer just creates a new SWTContianer and passes
this path in. Then the SWTContainer looks at this path and when it sees
just "/SWTContainer" it returns in getClasspathEntries() one
set of library entries, but if it sees "/JFACE" attached it adds
in another set of library entries.

By doing it this way the project automatically is
refreshed and the new libraries show up.

The container path must be self-sufficient in defining
what libraries are to show up. I don't know where you are storing the info
for what libraries your container shows and when it is configured, where
it stores it. It may be that you are storing it someplace else and it is
not seen right away after configuring.
>>>

Thanks,

Janak

_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ve-dev