Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » Losing part of build path by "update the classpath settings"(Losing part of build path by "update the classpath settings")
Losing part of build path by "update the classpath settings" [message #551868] Mon, 09 August 2010 20:55 Go to next message
Steve M is currently offline Steve MFriend
Messages: 10
Registered: August 2010
Junior Member
Hi,

My RCP relies on another Eclipse project. However, Manifest Editor > Overview > "Update the classpath settings" removes the dependent project from my buildpath.

Is there a way to manually add dependent projects to build.properties?

Or do I need to OSGIify the external project?

Thanks,
Steve
Re: Losing part of build path by "update the classpath settings" [message #552427 is a reply to message #551868] Thu, 12 August 2010 08:24 Go to previous messageGo to next message
Steve M is currently offline Steve MFriend
Messages: 10
Registered: August 2010
Junior Member
I found a (non-ideal) workaround. I created a jar of my dependent project (export > Java > Runnable jar) and added it to my plugin (RCP) project.

This works but adds a disruptive step to my development workflow. I'd like the plugin project to pickup changes in a dependent project "on the fly", as a normal (non-plugin) project does.

Can this be done?

Thanks,
Steve
Re: Losing part of build path by "update the classpath settings" [message #553161 is a reply to message #552427] Mon, 16 August 2010 15:12 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

OSGi only sees OSGi. Your other project needs to be a bundle in order
to be used. Keep in mind you can make your other project an OSGi bundle
and it will still work fine as a standard java library for other
applications. OSGi only needs the extra information in the MANIFEST.MF
to wire up class loaders, exported packages, etc.

Is that a problem? How were you planning on deploying it?

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm


Re: Losing part of build path by "update the classpath settings" [message #554058 is a reply to message #553161] Thu, 19 August 2010 22:27 Go to previous messageGo to next message
Steve M is currently offline Steve MFriend
Messages: 10
Registered: August 2010
Junior Member
Thanks.

From what I understand, in order to make my external project an OSGI bundle I will have to package it as a jar first. (It's bulky and relies on about 20 jars)

Is there any way to avoid that? I will be editing the external project while editing my RCP so I'd like to avoid having to package as a jar to see those changes RCP...

Steve
Re: Losing part of build path by "update the classpath settings" [message #554793 is a reply to message #554058] Tue, 24 August 2010 12:22 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

maherhome wrote:
> Thanks.
>
> From what I understand, in order to make my external project an OSGI
> bundle I will have to package it as a jar first. (It's bulky and relies
> on about 20 jars)

Not really, since you can work on eclipse plugins in eclipse. You can
even have one bundle be a library plugin for all 20 jars ... their
individual licenses permitting, of course.

>
> Is there any way to avoid that? I will be editing the external project
> while editing my RCP so I'd like to avoid having to package as a jar to
> see those changes RCP...

There's no way to get around bundles can see other bundles. When you
deploy this, how is your plugin going to see the 20 jars?

PW


--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm


Re: Losing part of build path by "update the classpath settings" [message #555179 is a reply to message #554793] Wed, 25 August 2010 17:39 Go to previous messageGo to next message
Steve M is currently offline Steve MFriend
Messages: 10
Registered: August 2010
Junior Member
Quote:
Paul Webster wrote on Tue, 24 August 2010 08:22
maherhome wrote:
> Thanks.


>> Is there any way to avoid that? I will be editing the external project
>> while editing my RCP so I'd like to avoid having to package as a jar to
>> see those changes RCP...

>There's no way to get around bundles can see other >bundles.

I don't understand you, but I'm going to assume the answer is "no". Specifically, I can NOT edit the source of an Eclipse project upon which my RCP project depends and have the changes automatically picked up the RCP project. As you probably know, this CAN be done for a non RCP project with a dependent project, but I'm tired of finding a solution.

>When you
>deploy this, how is your plugin going to see the 20 jars?

In the dependent project I do an Export > Java > Runnable Jar [expand libraries] to pack everything (including lib jars) into a single jar and save it in the RCP project. 3rd party licenses are fine for this internal application.


>>PW

Steve



--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm

Re: Losing part of build path by "update the classpath settings" [message #555349 is a reply to message #555179] Thu, 26 August 2010 12:01 Go to previous message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

maherhome wrote:
> Quote:
>> > > >There's no way to get around bundles can see other >bundles. > >
>> I don't understand you, but I'm going to assume the answer is "no".

All RCP apps are OSGi apps. Based on bundles (each plugin is a bundle),
the MANIFEST.MF controls the classpath of the app. If you don't have an
OSGi manifest, then it becomes very hard to get into the classpath
hierarchy.


>> Specifically, I can NOT edit the source of an Eclipse project upon
>> which my RCP project depends and have the changes automatically picked
>> up the RCP project. As you probably know, this CAN be done for a non
>> RCP project with a dependent project, but I'm tired of finding a
>> solution.

This is the part I don't understand. If you can't edit the other
project source, then generate the jar and included it in your RCP project.

If you can edit the source (and I thought that was the original
question, edit the source at the same time you are working on your RCP
app), turn them into OSGi bundles ... i.e. add a MANIFEST.MF. Any
regular jar can be turned into an osgi bundle by adding the correct
MANIFEST.MF. it has no impact on using that jar as a regular jar, but
provides the metadata for using that jar with other OSGi bundles. Then
you don't have to build a mega jar, just deploy them as bundles with
your RCP app bundle.

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm


Previous Topic:How to Convert java projects into plugin projects
Next Topic:Synchronizing data in FormEditor
Goto Forum:
  


Current Time: Fri Apr 19 11:33:01 GMT 2024

Powered by FUDForum. Page generated in 0.02424 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top