Can't share launch configs because absolute paths used in "classpath" about run-jetty-run HOT 12 CLOSED

Please attach a launch config that shows the problem.

Sorry: the problem is a bit more involved than I first described.

If you create a launch config, by default it defines the classpath with just 
this:

<stringAttribute key="org.eclipse.jdt.launching.CLASSPATH_PROVIDER"
value="RunJettyRunWebAppClassPathProvider"/>

However, if you edit the classpath in the Eclipse launch editor, then it places 
an
explicit list of the Classpath entries into the .launch file (see attached 
file).

Unfortunately, we needed to change the classpath to move our application's 
default
classpath after the RunJettyRun entries - we have a dependency on Selenium and 
that
has an old, incompatible copy of Jetty embedded in one of its jars :-( If we 
don't
put the RunJettyRun jars first then the launch won't work...

The class path that rjr now uses to start does NOT include the web app's class 
path.  
Instead, a class loader is created based on the class path of the web app's 
Eclipse 
project (e.g. the output directory, and the output directory of the projects it 
depends on, and any jars those projects depend on).  These changes may help to 
address that specific problem with Selenium such that you don't need to edit 
the 
class path.  Can you try it out?

It does address my particular problem. In other words, the default entries for
classpath in the launch editor now work OK for me.

However, if someone did need to edit the classpath for some reason, they would 
run
into this problem. It's probably a low priority issue :-)

rjr doesn't actually provide the classpath tab (that comes from the JDT, and 
includes 
the saving of the classpath configuration).  I'm uncertain whether rjr has any 
involvement in saving the contents of the classpath tab; it is likely that the 
tab is  
initialized from the values computed by rjr, and that may be done in such that 
you 
get absolute paths "too early".

Now that I've debugged the rendering of the classpath tab, it is obvious that 
rjr is 
involved in computing the contents.

I'm contemplating the following ideas:

On the theory that the classpath tab should show the runtime classpath of the 
project being 
debugged (e.g. the path to the servlets and their dependencies), I could remove 
bootstrap.jar and the jetty runtime jars from the classpath presented in the 
classpath tab. 

Have rjr provide a ClasspathVariableInitializer, which would create one or 
several classpath 
variables, which denote the location of the API jars (e.g. for javax.servlet).  
These could 
then be used by the developer to setup the JDT build path for the project being 
debugged.

I could add an IClasspathContainer implementation that provides the API jars.

rjr already hard codes the set of runtime jars needed for jetty; instead of 
having that info 
in the plug-in, it could be in Bootstrap (the main that is started).  It could 
be set to 
find the jars it needs as siblings of its own jars.  This would reduce the size 
of the 
argument list.

Any thoughts?

I've tried the workaround proposed: add the variable string
"${bundle_loc:runjettyrun}/lib/jetty-6.1.6.jar", but eclipse raises an error
"Reference to undefined variable bundle_loc"

How can I configure eclipse to recognize bundle_loc?

Sorry, I'm not familiar with bundle_loc.  Perhaps the original submitter can 
update 
this issue with more details.

Unfortunately I wasn't able to get it work, so every developer has to create a
variable pointing to jetty bundle location. Perhaps we could raise the priority 
of
this issue?

Add this issue as a part for 1.2.2 , 
plan to use Container to manager Jetty Bundle in future.

Ready since 2011/3/21 , will build in version 1.2.1 .

If you are running old project, please don't forget to 
"restore default" for classpath after you upgrade 1.2.1 .

Committed in r95.