| problem with pde plugin 'export wizard' [message #16131] |
Fri, 08 August 2008 06:25  |
Eclipse User |
|
|
|
Originally posted by: totolaricot.mac.com
workbench is used to build a client server system with ~70 modules (some
of them shared) including something like this:
A
subset of a library X for client side use
B
complete version of library X for server side use
C
* client/server module that imports the subset of library X via import
packages xxxx.yyyy.zzz
the library can be used on client and server projects
* has A listed as a 'extra classpath' dependency on the Dependencies
screen
* contains 1 sub libraries listed in 'runtime information' on the
build manifest tab
D
* client/server module that imports the subset of library X via import
packages xxxx.yyyy.zzz
the library can be used on client and server projects
* has A listed as a 'extra classpath' dependency on the Dependencies
screen
* contains 2 sub libraries listed in 'runtime information' on the
build manifest tab
using PDE export bundle wizard, module C can be exported with the export
wizard, while module D cannot built because at compile time, the classes
in xxxx.yyyy.zzzz are not included in the build classpath.
I actually checked the generated build.xml files in both cases and they
are indeed different (C does have an entry for project A while D does
not). While looking at the generated classpath, I was also surprised to
see some things that I did not want there but had been pulled from the
target platform definition.
pde is the most unstable piece of xxxxxxx I have ever seen, not to
mention how pathetic some of its source code looks when compared with
some other projects. the number of problems I have had with things
working then not then again in the last 2 years is absolutely grotesque.
and btw whether or not you like how I say it, or even believe what say
does not change the fact that what I describe is real (and no, I don't
have the time to prepare some nice test cases for some of the
aberrations I have seen - some of them are really blatant - like making
the autogenerated dependencies list differ in two consecutive
recalculations)...
|
|
|
| Re: problem with pde plugin 'export wizard' [message #16147 is a reply to message #16131] |
Fri, 08 August 2008 07:39  |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
hi L.,
I have also bundles for client / server use, where some things 'overlap',
sometimes the client only uses a part of what the server uses.
in these cases its always good to organize your pde environment well:
some tips from me:
1. use different working sets for server and client
2. have two different target definition files for server and client
then to export from PDE:
use your client (or server) workingset
use your client (or server) PDE Target (simply under preferences - PDE -
target click Load Target, dont forget "chris" checkbox ;-)
now you're sure, PDE onky knows the bundles for client (or server) and
can do the correct export, have correct dependencies etc.
L. Mihalkovic schrieb:
> workbench is used to build a client server system with ~70 modules (some
> of them shared) including something like this:
>
> A
> subset of a library X for client side use
> B
> complete version of library X for server side use
> C
> * client/server module that imports the subset of library X via import
> packages xxxx.yyyy.zzz
> the library can be used on client and server projects
> * has A listed as a 'extra classpath' dependency on the Dependencies
> screen
> * contains 1 sub libraries listed in 'runtime information' on the build
> manifest tab
> D
> * client/server module that imports the subset of library X via import
> packages xxxx.yyyy.zzz
> the library can be used on client and server projects
> * has A listed as a 'extra classpath' dependency on the Dependencies
> screen
> * contains 2 sub libraries listed in 'runtime information' on the build
> manifest tab
>
> using PDE export bundle wizard, module C can be exported with the export
> wizard, while module D cannot built because at compile time, the classes
> in xxxx.yyyy.zzzz are not included in the build classpath.
>
> I actually checked the generated build.xml files in both cases and they
> are indeed different (C does have an entry for project A while D does
> not). While looking at the generated classpath, I was also surprised to
> see some things that I did not want there but had been pulled from the
> target platform definition.
>
> pde is the most unstable piece of xxxxxxx I have ever seen, not to
> mention how pathetic some of its source code looks when compared with
> some other projects. the number of problems I have had with things
> working then not then again in the last 2 years is absolutely grotesque.
> and btw whether or not you like how I say it, or even believe what say
> does not change the fact that what I describe is real (and no, I don't
> have the time to prepare some nice test cases for some of the
> aberrations I have seen
L,
if you really think there's something wrong, then you should take the
time to create a testcase and help to find the reason
hey - this is the way open source works ;-)
ekke
- some of them are really blatant - like making
> the autogenerated dependencies list differ in two consecutive
> recalculations)...
>
|
|
|
| Re: problem with pde plugin 'export wizard' [message #575997 is a reply to message #16131] |
Fri, 08 August 2008 07:39 |
| Eclipse User |
|
|
|
Originally posted by: ekkehard.gentz-software.de
hi L.,
I have also bundles for client / server use, where some things 'overlap',
sometimes the client only uses a part of what the server uses.
in these cases its always good to organize your pde environment well:
some tips from me:
1. use different working sets for server and client
2. have two different target definition files for server and client
then to export from PDE:
use your client (or server) workingset
use your client (or server) PDE Target (simply under preferences - PDE -
target click Load Target, dont forget "chris" checkbox ;-)
now you're sure, PDE onky knows the bundles for client (or server) and
can do the correct export, have correct dependencies etc.
L. Mihalkovic schrieb:
> workbench is used to build a client server system with ~70 modules (some
> of them shared) including something like this:
>
> A
> subset of a library X for client side use
> B
> complete version of library X for server side use
> C
> * client/server module that imports the subset of library X via import
> packages xxxx.yyyy.zzz
> the library can be used on client and server projects
> * has A listed as a 'extra classpath' dependency on the Dependencies
> screen
> * contains 1 sub libraries listed in 'runtime information' on the build
> manifest tab
> D
> * client/server module that imports the subset of library X via import
> packages xxxx.yyyy.zzz
> the library can be used on client and server projects
> * has A listed as a 'extra classpath' dependency on the Dependencies
> screen
> * contains 2 sub libraries listed in 'runtime information' on the build
> manifest tab
>
> using PDE export bundle wizard, module C can be exported with the export
> wizard, while module D cannot built because at compile time, the classes
> in xxxx.yyyy.zzzz are not included in the build classpath.
>
> I actually checked the generated build.xml files in both cases and they
> are indeed different (C does have an entry for project A while D does
> not). While looking at the generated classpath, I was also surprised to
> see some things that I did not want there but had been pulled from the
> target platform definition.
>
> pde is the most unstable piece of xxxxxxx I have ever seen, not to
> mention how pathetic some of its source code looks when compared with
> some other projects. the number of problems I have had with things
> working then not then again in the last 2 years is absolutely grotesque.
> and btw whether or not you like how I say it, or even believe what say
> does not change the fact that what I describe is real (and no, I don't
> have the time to prepare some nice test cases for some of the
> aberrations I have seen
L,
if you really think there's something wrong, then you should take the
time to create a testcase and help to find the reason
hey - this is the way open source works ;-)
ekke
- some of them are really blatant - like making
> the autogenerated dependencies list differ in two consecutive
> recalculations)...
>
|
|
|
Powered by
FUDForum. Page generated in 0.52438 seconds
] 
Search
Help
Register
Login
Home
