Home » Eclipse Projects » Eclipse Platform » Dependencies on development plug-ins don't work in runtime workspace
|
| Re: Dependencies on development plug-ins don't work in runtime workspace [message #290180 is a reply to message #287024] |
Fri, 19 August 2005 11:20   |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Emma,
I'm having the same problem and am curious if
you solved it without assistance of this newsgroup...
Cheers
/Eike
shepherd@uk.ibm.com schrieb:
> I am currently developing some plug-ins and testing them using the normal
> process of launching a run-time workspace with my development plug-in
> projects enabled.
>
> In my run-time workspace, I have some other plug-in projects that have
> dependencies on the plug-ins in my development workspace. Unfortunately,
> these dependencies aren't recognised by the Eclipse platform: the
> plugin.xml editor won't even display them as available plug-ins. It only
> works if I actually INSTALL my development plug-ins into the target
> environment.
>
> This is obviously very inconvenient as I have to re-install them every
> time I change the code: is it working as designed, and if so, can I get
> round this problem somehow?
>
> Thanks in advance,
> Emma
|
|
|
| Re: Dependencies on development plug-ins don't work in runtime workspace [message #290182 is a reply to message #290180] |
Fri, 19 August 2005 12:01 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------070403000704090906000408
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
When working on EMF development, we have this problem in spades, since
(as you well know) we are building generators and libraries and, in
order to test, we need to launch a runtime workspace where generated
code must compile against the libraries we are developing. It's "a
working as designed" limitation, according to the PDE folks, because the
JDT does not support compiling against an external folder. :-(
So when developing EMF, we work around the problem in the following
way. We check out our CVS code so that the projects are physically
stored in the plugins directory of the Eclipse installation. We allow
the checkout to complete and the build to complete and then we exit
Eclipse and run a script like this:
for i in \
plugins/org.eclipse.emf.ant/emf.ant.jar \
plugins/org.eclipse.emf.codegen.ecore.ui/codegen.ecore.ui.ja r \
... lots more plugins ...
plugins/org.eclipse.xsd.example/xsd.example.jar
do
(
cd $(dirname $i)/bin
echo zip -r ../$(basename $i) *
zip -r ../$(basename $i) *
)
done
This builds the jars for all the plugins from the .class files produced
by Eclipse. We can now restart Eclipse, with -clean, and use all our
code in the main Eclipse. This too is very important for EMF because we
bootstrap our own code, e.g., to compile our JET templates we need JET
installed and to generate our models, we need EMF itself to be
installed. Because we have everything set up this way, when we launch
a runtime workspace, that workspace will use the .class files instead of
the .jars we produced, so we can test our latest changes nicely without
messing up theEMF in main Eclipse. We can also generate code in the
runtime workspace that compiles against our developed plugins, but note
that this compilation is against the .jar files not the .class files,
because of the JDT limitation I mentioned earlier, which is typically
not such a big issue because, when it actually runs, it will use the
..class files, so it's only an issue if the API is changing...
When we needed/wanted to provide jarred plugins, we thought there'd be
an even better solution because we would no longer need to build the
jars, but instead the problem basically came back to bite us yet again,
because, as you can see from the description above, having the jars is
very important for the compiler to work, so there's no way to avoid
building jars. As such we've had to modify the manifest to specify a
jarred plugin during our build so that we don't break our only good
development-time mechanism.
Eike Stepper wrote:
> Emma,
>
> I'm having the same problem and am curious if
> you solved it without assistance of this newsgroup...
>
> Cheers
> /Eike
>
>
> shepherd@uk.ibm.com schrieb:
>
>> I am currently developing some plug-ins and testing them using the
>> normal process of launching a run-time workspace with my development
>> plug-in projects enabled.
>>
>> In my run-time workspace, I have some other plug-in projects that
>> have dependencies on the plug-ins in my development workspace.
>> Unfortunately, these dependencies aren't recognised by the Eclipse
>> platform: the plugin.xml editor won't even display them as available
>> plug-ins. It only works if I actually INSTALL my development
>> plug-ins into the target environment.
>>
>> This is obviously very inconvenient as I have to re-install them
>> every time I change the code: is it working as designed, and if so,
>> can I get round this problem somehow?
>>
>> Thanks in advance,
>> Emma
>
--------------070403000704090906000408
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
When working on EMF development, we have this problem in spades, since
(as you well know) we are building generators and libraries and, in
order to test, we need to launch a runtime workspace where generated
code must compile against the libraries we are developing.
|
|
|
| Re: Dependencies on development plug-ins don't work in runtime workspace [message #290241 is a reply to message #290182] |
Mon, 22 August 2005 10:10 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Ed,
You seem to be my only angel *everywhere* ;-)
> When working on EMF development, we have this problem in spades, since
> (as you well know) we are building generators and libraries and, in
> order to test, we need to launch a runtime workspace where generated
> code must compile against the libraries we are developing. It's "a
> working as designed" limitation, according to the PDE folks, because the
> JDT does not support compiling against an external folder. :-(
As you've certainly talked with those guys, do you think that they will
remove this limitation at some point in time?
> So when developing EMF, we work around the problem in the following
> way. We check out our CVS code so that the projects are physically
> stored in the plugins directory of the Eclipse installation.
So you checkout the projects to the plugins folder and also import
them from there into your workspace?
After normal workspace build you have the class files in bin/ and
with the script below you produce the jar file that is mentioned in
the respective MANIFEST.MF. So in fact you have two copies of the compile
result?
Could you please once more clarify WHERE/WHEN WHICH class (bin/ or jar) is used?!
> We allow
> the checkout to complete and the build to complete and then we exit
> Eclipse and run a script like this:
>
> for i in \
> plugins/org.eclipse.emf.ant/emf.ant.jar \
> plugins/org.eclipse.emf.codegen.ecore.ui/codegen.ecore.ui.ja r \
> .... lots more plugins ...
> plugins/org.eclipse.xsd.example/xsd.example.jar
> do
> (
> cd $(dirname $i)/bin
> echo zip -r ../$(basename $i) *
> zip -r ../$(basename $i) *
> )
> done
just for my understanding, could the three lines between do/done also be written like this: (?)
cd $(dirname $i)
echo zip -r $(basename $i) bin
zip -r $(basename $i) bin
> This builds the jars for all the plugins from the .class files produced
> by Eclipse. We can now restart Eclipse, with -clean, and use all our
> code in the main Eclipse. This too is very important for EMF because we
> bootstrap our own code, e.g., to compile our JET templates we need JET
> installed and to generate our models, we need EMF itself to be
> installed. Because we have everything set up this way, when we launch
> a runtime workspace, that workspace will use the .class files instead of
> the .jars we produced, so we can test our latest changes nicely without
> messing up theEMF in main Eclipse. We can also generate code in the
> runtime workspace that compiles against our developed plugins, but note
> that this compilation is against the .jar files not the .class files,
> because of the JDT limitation I mentioned earlier, which is typically
> not such a big issue because, when it actually runs, it will use the
> .class files, so it's only an issue if the API is changing...
Oh, this is very complicated at a first glance.
For example, when it is most important that the jars are in place when
the runtime workbench is started, why do you also need the bin/ classes?
Or is this more a trick to reuse the plugin infrastructure (plugin.xml,
MANIFEST.MF, ...) during development in the host workspace?
Why don't you just export your plugins to the plugins/ folder each time
you have changed the code in the host workspace? Can't you explicitely
declare the *installed* plugins to be used in the launch config (instead
of the workspace ones)?
> When we needed/wanted to provide jarred plugins, we thought there'd be
> an even better solution because we would no longer need to build the
> jars, but instead the problem basically came back to bite us yet again,
> because, as you can see from the description above, having the jars is
> very important for the compiler to work, so there's no way to avoid
> building jars. As such we've had to modify the manifest to specify a
> jarred plugin during our build so that we don't break our only good
> development-time mechanism.
>
>
> Eike Stepper wrote:
>
>> Emma,
>>
>> I'm having the same problem and am curious if
>> you solved it without assistance of this newsgroup...
>>
>> Cheers
>> /Eike
>>
>>
>> shepherd@uk.ibm.com schrieb:
>>
>>> I am currently developing some plug-ins and testing them using the
>>> normal process of launching a run-time workspace with my development
>>> plug-in projects enabled.
>>>
>>> In my run-time workspace, I have some other plug-in projects that
>>> have dependencies on the plug-ins in my development workspace.
>>> Unfortunately, these dependencies aren't recognised by the Eclipse
>>> platform: the plugin.xml editor won't even display them as available
>>> plug-ins. It only works if I actually INSTALL my development
>>> plug-ins into the target environment.
>>>
>>> This is obviously very inconvenient as I have to re-install them
>>> every time I change the code: is it working as designed, and if so,
>>> can I get round this problem somehow?
>>>
>>> Thanks in advance,
>>> Emma
>>
>
|
|
|
| Re: Dependencies on development plug-ins don't work in runtime workspace [message #290242 is a reply to message #290241] |
Mon, 22 August 2005 11:20 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Eike,
Comments below.
Eike Stepper wrote:
> Ed,
>
> You seem to be my only angel *everywhere* ;-)
>
So at least that halo pinching my head is good for something!
>
>> When working on EMF development, we have this problem in spades,
>> since (as you well know) we are building generators and libraries
>> and, in order to test, we need to launch a runtime workspace where
>> generated code must compile against the libraries we are developing.
>> It's "a working as designed" limitation, according to the PDE folks,
>> because the JDT does not support compiling against an external
>> folder. :-(
>
>
> As you've certainly talked with those guys, do you think that they will
> remove this limitation at some point in time?
>
I'm trying another round of convincing folks that this would be a really
nice problem to fix. (This problem tends to seem like some wierd
problem that only the wierd EMF guys have.)
>
>> So when developing EMF, we work around the problem in the following
>> way. We check out our CVS code so that the projects are physically
>> stored in the plugins directory of the Eclipse installation.
>
>
> So you checkout the projects to the plugins folder and also import
> them from there into your workspace?
>
Yep. You can specify any location instead of accepting the workspace
location default.
> After normal workspace build you have the class files in bin/ and
> with the script below you produce the jar file that is mentioned in
> the respective MANIFEST.MF. So in fact you have two copies of the compile
> result?
>
> Could you please once more clarify WHERE/WHEN WHICH class (bin/ or
> jar) is used?!
>
The .jar is used by the main Eclipse to run and the .class files are
used by the runtime Eclipse to run. For compilation purposes, the
..class files are used within the main Eclipse when other workspace
plugins compile against your workspace plugin but the .jar file is used
by the runtime Eclipse when other plugins there compile against your
main Eclipse's workspace plugins. (All these comments assume that the
plugin.xml/MANIFEST.MF specify a jar.)
>
>> We allow the checkout to complete and the build to complete and then
>> we exit Eclipse and run a script like this:
>>
>> for i in \
>> plugins/org.eclipse.emf.ant/emf.ant.jar \
>> plugins/org.eclipse.emf.codegen.ecore.ui/codegen.ecore.ui.ja r \
>> .... lots more plugins ...
>> plugins/org.eclipse.xsd.example/xsd.example.jar
>> do
>> (
>> cd $(dirname $i)/bin
>> echo zip -r ../$(basename $i) *
>> zip -r ../$(basename $i) *
>> )
>> done
>
>
> just for my understanding, could the three lines between do/done also
> be written like this: (?)
>
> cd $(dirname $i)
> echo zip -r $(basename $i) bin
> zip -r $(basename $i) bin
>
I don't think so, because the bin folder will be in your .jar this way.
>
>> This builds the jars for all the plugins from the .class files
>> produced by Eclipse. We can now restart Eclipse, with -clean, and
>> use all our code in the main Eclipse. This too is very important for
>> EMF because we bootstrap our own code, e.g., to compile our JET
>> templates we need JET installed and to generate our models, we need
>> EMF itself to be installed. Because we have everything set up this
>> way, when we launch a runtime workspace, that workspace will use the
>> .class files instead of the .jars we produced, so we can test our
>> latest changes nicely without messing up theEMF in main Eclipse. We
>> can also generate code in the runtime workspace that compiles against
>> our developed plugins, but note that this compilation is against the
>> .jar files not the .class files, because of the JDT limitation I
>> mentioned earlier, which is typically not such a big issue because,
>> when it actually runs, it will use the .class files, so it's only an
>> issue if the API is changing...
>
>
> Oh, this is very complicated at a first glance.
> For example, when it is most important that the jars are in place when
> the runtime workbench is started, why do you also need the bin/ classes?
> Or is this more a trick to reuse the plugin infrastructure (plugin.xml,
> MANIFEST.MF, ...) during development in the host workspace?
>
Yep, it seems complicated. The runtime workbench will always (I think)
look for a bin folder with .class files so that the runtime workbench
will be running the latest compiled changes without need to build a
jar. Part of our need is to be able to bootstrap, i.e., to use our JET
compiler to compile our own JET templates or to use our own generator to
regenerate the generator's model...
> Why don't you just export your plugins to the plugins/ folder each time
> you have changed the code in the host workspace? Can't you explicitely
> declare the *installed* plugins to be used in the launch config (instead
> of the workspace ones)?
>
We could export, but when you have 50 plugins to export, that's not so
lightening quick And once you export and launch that result, you no
longer have a nice hot debug environment in which to work, since you
can't make any changes to the exported image being debugged. A few
months ago, we sat down with the PDE guys to have them help tune our
development process to better exploit the PDE, but, in the end, what I
described was still the best way to accomplish what we need with a
reasonable workflow.
>
>> When we needed/wanted to provide jarred plugins, we thought there'd
>> be an even better solution because we would no longer need to build
>> the jars, but instead the problem basically came back to bite us yet
>> again, because, as you can see from the description above, having the
>> jars is very important for the compiler to work, so there's no way to
>> avoid building jars. As such we've had to modify the manifest to
>> specify a jarred plugin during our build so that we don't break our
>> only good development-time mechanism.
>>
>> Eike Stepper wrote:
>>
>>> Emma,
>>>
>>> I'm having the same problem and am curious if
>>> you solved it without assistance of this newsgroup...
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> shepherd@uk.ibm.com schrieb:
>>>
>>>> I am currently developing some plug-ins and testing them using the
>>>> normal process of launching a run-time workspace with my
>>>> development plug-in projects enabled.
>>>>
>>>> In my run-time workspace, I have some other plug-in projects that
>>>> have dependencies on the plug-ins in my development workspace.
>>>> Unfortunately, these dependencies aren't recognised by the Eclipse
>>>> platform: the plugin.xml editor won't even display them as
>>>> available plug-ins. It only works if I actually INSTALL my
>>>> development plug-ins into the target environment.
>>>>
>>>> This is obviously very inconvenient as I have to re-install them
>>>> every time I change the code: is it working as designed, and if so,
>>>> can I get round this problem somehow?
>>>>
>>>> Thanks in advance,
>>>> Emma
>>>
>>>
>>
|
|
|
| Re: Dependencies on development plug-ins don't work in runtime workspace [message #290251 is a reply to message #290242] |
Mon, 22 August 2005 13:56 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Ed Merks schrieb:
> Eike,
>
> Comments below.
>
> Eike Stepper wrote:
>
>> Ed,
>>
>> You seem to be my only angel *everywhere* ;-)
>>
> So at least that halo pinching my head is good for something!
I hope that people don't confuse it with a beacon and gather in front of your office for help ;-)
>>> When working on EMF development, we have this problem in spades,
>>> since (as you well know) we are building generators and libraries
>>> and, in order to test, we need to launch a runtime workspace where
>>> generated code must compile against the libraries we are developing.
>>> It's "a working as designed" limitation, according to the PDE folks,
>>> because the JDT does not support compiling against an external
>>> folder. :-(
>>
>>
>>
>> As you've certainly talked with those guys, do you think that they will
>> remove this limitation at some point in time?
>>
> I'm trying another round of convincing folks that this would be a really
> nice problem to fix. (This problem tends to seem like some wierd
> problem that only the wierd EMF guys have.)
Oh no! I personally know at least two persons (Philipp being one of them),
who currently also spend a lot of extra efford to workaround this issue.
So we're at least five now (including you and shepherd@uk.ibm.com).
>>> So when developing EMF, we work around the problem in the following
>>> way. We check out our CVS code so that the projects are physically
>>> stored in the plugins directory of the Eclipse installation.
>>
>>
>>
>> So you checkout the projects to the plugins folder and also import
>> them from there into your workspace?
>>
> Yep. You can specify any location instead of accepting the workspace
> location default.
>
>> After normal workspace build you have the class files in bin/ and
>> with the script below you produce the jar file that is mentioned in
>> the respective MANIFEST.MF. So in fact you have two copies of the compile
>> result?
>>
>> Could you please once more clarify WHERE/WHEN WHICH class (bin/ or
>> jar) is used?!
>>
> The .jar is used by the main Eclipse to run and the .class files are
> used by the runtime Eclipse to run. For compilation purposes, the
> ..class files are used within the main Eclipse when other workspace
> plugins compile against your workspace plugin but the .jar file is used
> by the runtime Eclipse when other plugins there compile against your
> main Eclipse's workspace plugins. (All these comments assume that the
> plugin.xml/MANIFEST.MF specify a jar.)
Heaven, this trick is really tricky! Did you discover it by accident?
>>> We allow the checkout to complete and the build to complete and then
>>> we exit Eclipse and run a script like this:
>>>
>>> for i in \
>>> plugins/org.eclipse.emf.ant/emf.ant.jar \
>>> plugins/org.eclipse.emf.codegen.ecore.ui/codegen.ecore.ui.ja r \
>>> .... lots more plugins ...
>>> plugins/org.eclipse.xsd.example/xsd.example.jar
>>> do
>>> (
>>> cd $(dirname $i)/bin
>>> echo zip -r ../$(basename $i) *
>>> zip -r ../$(basename $i) *
>>> )
>>> done
>>
>>
>>
>> just for my understanding, could the three lines between do/done also
>> be written like this: (?)
>>
>> cd $(dirname $i)
>> echo zip -r $(basename $i) bin
>> zip -r $(basename $i) bin
>>
> I don't think so, because the bin folder will be in your .jar this way.
>
>>
>>> This builds the jars for all the plugins from the .class files
>>> produced by Eclipse. We can now restart Eclipse, with -clean, and
>>> use all our code in the main Eclipse. This too is very important for
>>> EMF because we bootstrap our own code, e.g., to compile our JET
>>> templates we need JET installed and to generate our models, we need
>>> EMF itself to be installed. Because we have everything set up this
>>> way, when we launch a runtime workspace, that workspace will use the
>>> .class files instead of the .jars we produced, so we can test our
>>> latest changes nicely without messing up theEMF in main Eclipse. We
>>> can also generate code in the runtime workspace that compiles against
>>> our developed plugins, but note that this compilation is against the
>>> .jar files not the .class files, because of the JDT limitation I
>>> mentioned earlier, which is typically not such a big issue because,
>>> when it actually runs, it will use the .class files, so it's only an
>>> issue if the API is changing...
>>
>>
>>
>> Oh, this is very complicated at a first glance.
>> For example, when it is most important that the jars are in place when
>> the runtime workbench is started, why do you also need the bin/ classes?
>> Or is this more a trick to reuse the plugin infrastructure (plugin.xml,
>> MANIFEST.MF, ...) during development in the host workspace?
>>
> Yep, it seems complicated. The runtime workbench will always (I think)
> look for a bin folder with .class files so that the runtime workbench
> will be running the latest compiled changes without need to build a
> jar. Part of our need is to be able to bootstrap, i.e., to use our JET
> compiler to compile our own JET templates or to use our own generator to
> regenerate the generator's model...
That's exactly what I need it for ;-)
I have a set of plugins that turn an ordinary IProject into a "Product"
that is governed by a "ProductModel". The latter is itself a Product
and the initial/top ProductModel is bootstrapped. Until now it only worked
by exporting the bootstrap plugin, install it and restart the host Eclipse.
It would be great if we could convince JDT guys to invest into an even
smoother solution. Tell me, if you need voters ;-)
Cheers
/Eike
>> Why don't you just export your plugins to the plugins/ folder each time
>> you have changed the code in the host workspace? Can't you explicitely
>> declare the *installed* plugins to be used in the launch config (instead
>> of the workspace ones)?
>>
> We could export, but when you have 50 plugins to export, that's not so
> lightening quick And once you export and launch that result, you no
> longer have a nice hot debug environment in which to work, since you
> can't make any changes to the exported image being debugged. A few
> months ago, we sat down with the PDE guys to have them help tune our
> development process to better exploit the PDE, but, in the end, what I
> described was still the best way to accomplish what we need with a
> reasonable workflow.
>
>>
>>> When we needed/wanted to provide jarred plugins, we thought there'd
>>> be an even better solution because we would no longer need to build
>>> the jars, but instead the problem basically came back to bite us yet
>>> again, because, as you can see from the description above, having the
>>> jars is very important for the compiler to work, so there's no way to
>>> avoid building jars. As such we've had to modify the manifest to
>>> specify a jarred plugin during our build so that we don't break our
>>> only good development-time mechanism.
>>>
>>> Eike Stepper wrote:
>>>
>>>> Emma,
>>>>
>>>> I'm having the same problem and am curious if
>>>> you solved it without assistance of this newsgroup...
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> shepherd@uk.ibm.com schrieb:
>>>>
>>>>> I am currently developing some plug-ins and testing them using the
>>>>> normal process of launching a run-time workspace with my
>>>>> development plug-in projects enabled.
>>>>>
>>>>> In my run-time workspace, I have some other plug-in projects that
>>>>> have dependencies on the plug-ins in my development workspace.
>>>>> Unfortunately, these dependencies aren't recognised by the Eclipse
>>>>> platform: the plugin.xml editor won't even display them as
>>>>> available plug-ins. It only works if I actually INSTALL my
>>>>> development plug-ins into the target environment.
>>>>>
>>>>> This is obviously very inconvenient as I have to re-install them
>>>>> every time I change the code: is it working as designed, and if so,
>>>>> can I get round this problem somehow?
>>>>>
>>>>> Thanks in advance,
>>>>> Emma
>>>>
>>>>
>>>>
>>>
|
|
|
Goto Forum:
Current Time: Sat Nov 02 19:44:56 GMT 2024
Powered by FUDForum. Page generated in 0.03885 seconds |
] 
Search
Help
Register
Login
Home
