search

wjw465150 / run-jetty-run

Automatically exported from code.google.com/p/run-jetty-run
0 stars 0 forks source link

Can't share launch configs because absolute paths used in "classpath" #18

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
We like to commit launch configs to source control and share them amongst
team members. However, the run jetty run launch configs have default
classpath entries that use absolute paths. For example:
"C:/Java/eclipse/eclipse-ganymede/configuration/org.eclipse.osgi/bundles/689/1/.
cp/lib/jetty-6.1.6.jar"
So, obviously, the launch config won't work on someone else's machine.

Incidentally, it appears that the number under bundles (i.e. 689) is
different for every developer.

We have a workaround, which is to manually edit the launch config, remove
all the absolute paths and replace them with "Advanced->Add Variable
String" entries of the form:
"${bundle_loc:runjettyrun}/lib/jetty-6.1.6.jar"

Original issue reported on code.google.com by i.am.pau...@googlemail.com on 20 Aug 2008 at 12:10

GoogleCodeExporter commented 9 years ago 
Please attach a launch config that shows the problem.

Original comment by James.Sy...@gmail.com on 4 May 2009 at 1:00

GoogleCodeExporter commented 9 years ago 
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...

Original comment by i.am.pau...@googlemail.com on 5 May 2009 at 8:57

Attachments:

GoogleCodeExporter commented 9 years ago 
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?

Original comment by James.Sy...@gmail.com on 5 May 2009 at 11:52

GoogleCodeExporter commented 9 years ago 
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 :-)

Original comment by i.am.pau...@googlemail.com on 15 May 2009 at 6:50

GoogleCodeExporter commented 9 years ago 
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".

Original comment by James.Sy...@gmail.com on 16 May 2009 at 2:48

GoogleCodeExporter commented 9 years ago 
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?

Original comment by James.Sy...@gmail.com on 17 May 2009 at 2:30

GoogleCodeExporter commented 9 years ago 
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?

Original comment by ricardo....@gmail.com on 27 Aug 2009 at 10:08

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

Original comment by James.Sy...@gmail.com on 28 Aug 2009 at 12:04

GoogleCodeExporter commented 9 years ago 
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?

Original comment by ricardo....@gmail.com on 10 Sep 2009 at 11:49

GoogleCodeExporter commented 9 years ago 
Add this issue as a part for 1.2.2 , 
plan to use Container to manager Jetty Bundle in future.

Original comment by tonylovejava on 20 Mar 2011 at 5:47

GoogleCodeExporter commented 9 years ago 
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 .

Original comment by tonylovejava on 21 Mar 2011 at 3:59

GoogleCodeExporter commented 9 years ago 
Committed in r95.

Original comment by tonylovejava on 21 Mar 2011 at 4:00