Home » Eclipse Projects » Plugin Development Environment (PDE) » Rebuilding target platform without closing Eclipse
| Rebuilding target platform without closing Eclipse [message #61181] |
Tue, 12 May 2009 22:56  |
 Will Horn
Messages: 265
Registered: July 2009 |
Senior Member |
|
|
In my RCP project, the target platform is maintained by a script (actually a
maven goal). If the configuration changes (adding or removing plugins), the
developer needs to re-run the script to update the target platform.
Currently this requires closing Eclipse, running the script, and starting
Eclipse again.
Since the script is easily run in Eclipse, this an annoying step.
Essentially, I need to tell Eclipse/PDE to release the target directory and
suspend compilation while the target is rebuilt.
By the way, I've tried (as a workaround) to switch to the default target
temporarily, but this fails as jars in the old target are still locked.
This is also messy anyways, because switching to the default target
initiates a full rebuild which will have tons of errors.
|
|
| |
| Re: Rebuilding target platform without closing Eclipse [message #61326 is a reply to message #61181] |
Wed, 13 May 2009 04:14  |
Chris Aniszczyk
Messages: 674
Registered: July 2009 |
Senior Member |
|
|
Will Horn wrote:
> In my RCP project, the target platform is maintained by a script
> (actually a maven goal). If the configuration changes (adding or
> removing plugins), the developer needs to re-run the script to update
> the target platform. Currently this requires closing Eclipse, running
> the script, and starting Eclipse again.
:(
>
> Since the script is easily run in Eclipse, this an annoying step.
> Essentially, I need to tell Eclipse/PDE to release the target directory
> and suspend compilation while the target is rebuilt.
>
> By the way, I've tried (as a workaround) to switch to the default target
> temporarily, but this fails as jars in the old target are still locked.
> This is also messy anyways, because switching to the default target
> initiates a full rebuild which will have tons of errors.
Is there a reason you don't use PDE's target definition format to help
alleviate the pain here?
http://eclipsesource.com/blogs/2009/04/29/target-platform-pr ovisioning/
In 3.4 and earlier versions, some people would keep a 'target project'
in their SCM and a target definition pointing to those sets of bundles.
This worked pretty well and was shareable with teammates, they just
needed to ensure that the target was checked out, up to date. And when
things changed, they needed to reset the target. As of 3.5, you can use
target definitions to point to a p2 repo and get your deps that way.
That's the direction we'll be pointing people to in the future.
Does that help?
Cheers,
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
|
|
| |
| Re: Rebuilding target platform without closing Eclipse [message #61529 is a reply to message #61326] |
Wed, 13 May 2009 17:22 |
Will Horn
Messages: 265
Registered: July 2009 |
Senior Member |
|
|
Hi Chris,
I have read your blog post and the new PDE target features look good. There
are a few challenges I face:
* The application depends on in-house jars that themselves bring in about 80
maven artifacts, many of which are not OSGi bundles. Using maven and bnd, I
can dynamically build a target platform that provides these bundles.
* I need to create the target platform for headless build also. I am
tracking http://bugs.eclipse.org/266311 about this.
I've used the SCM approach before. With that you have a target platform,
but not a target "definition" - i.e. it's hard to keep track of what is
actually in the target. It's also a pain when you upgrade versions, because
you have to delete abc-1.0.jar and add abc-2.0.jar.
It is interesting though, that the SCM method doesn't run into the same
problems I have with jars being locked. Maybe there something in
Eclipse/PDE that will release a jar if you are doing a team update on that
file? Another interesting data point that I just noticed is the locked jars
seem to consistently be source jars. Any ideas how to release those?
Thanks,
Will
"Chris Aniszczyk" <zx@eclipsesource.com> wrote in message
news:gudhfg$404$1@build.eclipse.org...
> Will Horn wrote:
>> In my RCP project, the target platform is maintained by a script
>> (actually a maven goal). If the configuration changes (adding or
>> removing plugins), the developer needs to re-run the script to update the
>> target platform. Currently this requires closing Eclipse, running the
>> script, and starting Eclipse again.
>
> :(
>
>>
>> Since the script is easily run in Eclipse, this an annoying step.
>> Essentially, I need to tell Eclipse/PDE to release the target directory
>> and suspend compilation while the target is rebuilt.
>>
>> By the way, I've tried (as a workaround) to switch to the default target
>> temporarily, but this fails as jars in the old target are still locked.
>> This is also messy anyways, because switching to the default target
>> initiates a full rebuild which will have tons of errors.
>
> Is there a reason you don't use PDE's target definition format to help
> alleviate the pain here?
>
> http://eclipsesource.com/blogs/2009/04/29/target-platform-pr ovisioning/
>
> In 3.4 and earlier versions, some people would keep a 'target project' in
> their SCM and a target definition pointing to those sets of bundles. This
> worked pretty well and was shareable with teammates, they just needed to
> ensure that the target was checked out, up to date. And when things
> changed, they needed to reset the target. As of 3.5, you can use target
> definitions to point to a p2 repo and get your deps that way. That's the
> direction we'll be pointing people to in the future.
>
> Does that help?
>
> Cheers,
>
> Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
> http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
|
|
| | |
| Re: Rebuilding target platform without closing Eclipse [message #597348 is a reply to message #61181] |
Wed, 13 May 2009 04:14 |
Chris Aniszczyk
Messages: 674
Registered: July 2009 |
Senior Member |
|
|
Will Horn wrote:
> In my RCP project, the target platform is maintained by a script
> (actually a maven goal). If the configuration changes (adding or
> removing plugins), the developer needs to re-run the script to update
> the target platform. Currently this requires closing Eclipse, running
> the script, and starting Eclipse again.
:(
>
> Since the script is easily run in Eclipse, this an annoying step.
> Essentially, I need to tell Eclipse/PDE to release the target directory
> and suspend compilation while the target is rebuilt.
>
> By the way, I've tried (as a workaround) to switch to the default target
> temporarily, but this fails as jars in the old target are still locked.
> This is also messy anyways, because switching to the default target
> initiates a full rebuild which will have tons of errors.
Is there a reason you don't use PDE's target definition format to help
alleviate the pain here?
http://eclipsesource.com/blogs/2009/04/29/target-platform-pr ovisioning/
In 3.4 and earlier versions, some people would keep a 'target project'
in their SCM and a target definition pointing to those sets of bundles.
This worked pretty well and was shareable with teammates, they just
needed to ensure that the target was checked out, up to date. And when
things changed, they needed to reset the target. As of 3.5, you can use
target definitions to point to a p2 repo and get your deps that way.
That's the direction we'll be pointing people to in the future.
Does that help?
Cheers,
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
|
|
| |
| Re: Rebuilding target platform without closing Eclipse [message #597407 is a reply to message #61326] |
Wed, 13 May 2009 17:22 |
Will Horn
Messages: 265
Registered: July 2009 |
Senior Member |
|
|
Hi Chris,
I have read your blog post and the new PDE target features look good. There
are a few challenges I face:
* The application depends on in-house jars that themselves bring in about 80
maven artifacts, many of which are not OSGi bundles. Using maven and bnd, I
can dynamically build a target platform that provides these bundles.
* I need to create the target platform for headless build also. I am
tracking http://bugs.eclipse.org/266311 about this.
I've used the SCM approach before. With that you have a target platform,
but not a target "definition" - i.e. it's hard to keep track of what is
actually in the target. It's also a pain when you upgrade versions, because
you have to delete abc-1.0.jar and add abc-2.0.jar.
It is interesting though, that the SCM method doesn't run into the same
problems I have with jars being locked. Maybe there something in
Eclipse/PDE that will release a jar if you are doing a team update on that
file? Another interesting data point that I just noticed is the locked jars
seem to consistently be source jars. Any ideas how to release those?
Thanks,
Will
"Chris Aniszczyk" <zx@eclipsesource.com> wrote in message
news:gudhfg$404$1@build.eclipse.org...
> Will Horn wrote:
>> In my RCP project, the target platform is maintained by a script
>> (actually a maven goal). If the configuration changes (adding or
>> removing plugins), the developer needs to re-run the script to update the
>> target platform. Currently this requires closing Eclipse, running the
>> script, and starting Eclipse again.
>
> :(
>
>>
>> Since the script is easily run in Eclipse, this an annoying step.
>> Essentially, I need to tell Eclipse/PDE to release the target directory
>> and suspend compilation while the target is rebuilt.
>>
>> By the way, I've tried (as a workaround) to switch to the default target
>> temporarily, but this fails as jars in the old target are still locked.
>> This is also messy anyways, because switching to the default target
>> initiates a full rebuild which will have tons of errors.
>
> Is there a reason you don't use PDE's target definition format to help
> alleviate the pain here?
>
> http://eclipsesource.com/blogs/2009/04/29/target-platform-pr ovisioning/
>
> In 3.4 and earlier versions, some people would keep a 'target project' in
> their SCM and a target definition pointing to those sets of bundles. This
> worked pretty well and was shareable with teammates, they just needed to
> ensure that the target was checked out, up to date. And when things
> changed, they needed to reset the target. As of 3.5, you can use target
> definitions to point to a p2 repo and get your deps that way. That's the
> direction we'll be pointing people to in the future.
>
> Does that help?
>
> Cheers,
>
> Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
> http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 12:28:50 GMT 2024
Powered by FUDForum. Page generated in 0.04583 seconds |
] 
Search
Help
Register
Login
Home
