[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-dev] Compile errors in today's 2.0.2 stream build
|
On the topic of manually updating the classpaths ...
How does one go about ensuring that classpaths generated by a feature.xml
that includes platform specific plugins/fragments are platform non-specific?
e.g.
We have a number of fragments in the CDT
org.eclipse.cdt.core.linux
org.eclipse.cdt.core.win32
org.eclipse.cdt.core.solaris
org.eclipse.cdt.core.qnx
They are included in the feature.xml file (as Feature Plugins and Fragments)
The IDE does not let me enter them as
org.eclipse.cdt.core.${os}
and complains if I edit the source of the feature.xml file
As a result any classpath generated includes all of the plugins and not the
org.eclipse.cdt.core.${os} that I would prefer.
I can edit the resulting build.xml file to use
org.eclipse.cdt.core.${os} instead of the list shown above.
Unfortunately that leaves me manually maintaining the classpaths.
-Judy
... wearing my CDT open source hat
¨¨¨°ºo§oº°¨¨¨¨°ºo§oº°¨¨¨¨°ºo§oº°¨¨¨¨°ºo§oº°¨¨¨
Judy N. Green Software Engineer
QNX Software Systems Ltd. www.qnx.com
¨¨¨°ºo§oº°¨¨¨¨°ºo§oº°¨¨¨¨°ºo§oº°¨¨¨¨°ºo§oº°¨¨¨
> -----Original Message-----
> From: dejan@xxxxxxxxxx [mailto:dejan@xxxxxxxxxx]
> Sent: Wednesday, October 09, 2002 2:33 PM
> To: eclipse-dev@xxxxxxxxxxx
> Subject: Re: [eclipse-dev] Compile errors in today's 2.0.2
> stream build
>
>
> If you ever wondered why it is better to use PDE for
> computing classpaths,
> this is why. PDE would never add org.eclipse.update.core
> project to your
> classpath if it wasn't in the 'requires' list. When classpath
> and prereqs
> are maintained manually, out-of-sync cases like this one are possible.
>
> Regarding the problem at hand, importing update.core for one
> utility class
> only (VersionedIdentifier) doesn't look like a good idea.
>
>
>
> Regards,
>
> Dejan Glozic, Ph.D.
> Manager, Eclipse Platform Components
> D2/MY7/8200/MKM
> IBM Canada Ltd.
> Tel. 905 413-2745 T/L 969-2745
> Fax. 905 413-4854
>
>
>
>
>
>
> "Martin
>
>
> Aeschlimann" To:
> eclipse-dev@xxxxxxxxxxx
>
> <Martin_Aeschliman cc:
>
>
> n@xxxxxxx> Subject: Re:
> [eclipse-dev] Compile errors in today's 2.0.2 stream build
>
> Sent by:
>
>
> eclipse-dev-admin@
>
>
> eclipse.org
>
>
>
>
>
>
>
>
> 10/09/2002 01:57
>
>
> PM
>
>
> Please respond to
>
>
> eclipse-dev
>
>
>
>
>
>
>
>
>
>
>
>
> We tracked the problem down to a nifty compiler issue:
>
> In plugin org.eclipse.jdt.ui.tests:
>
> class TestWorkbench extends Workbench {
> ....
> }
>
> In plugin org eclipse.ui:
>
> class Workbench {
> ....
> private VersionedIdentifier[] collectFeatures() {
> ...
> }
> ....
> }
>
> Class VersionedIdentifier is located in plugin
> 'org.eclipse.update.core'.
>
> 'org.eclipse.jdt.ui.tests' prereqs 'org eclipse.ui' but not
> 'org.eclipse.update.core': Its a 'Workbench'-internal that
> VersionedIdentifier is used.
> However the compiler asks that all types in a superclasses
> signature must
> also be visible when compiling the subclass. Kent assured us
> that this is
> the right compiler behavior.
>
> As the method VersionedIdentifier[] collectFeatures() has
> been introduced
> just recently for 2.0.2, that's why this didn't show up before.
>
> Two choices to get it compiling again:
> a.) All the plugins that contain a class that extends
> Workbench have to add
> org.eclipse.update.core as a prereq.
> -> 4 - 5 plugins are concerned
> b.) We change Workbench' so that 'VersionedIdentifier'
> doesn't show up in
> the signature
>
> b.) seems to be the more secure approach for now as we don't
> know if there
> are other client plugins that extend Workbench but do not prereq
> 'org.eclipse.update.core'.
> Other ideas?
>
> Martin
>
>
>
>
> "Sonia Dimitrov"
>
> <Sonia_Dimitrov@ot To:
> eclipse-dev@xxxxxxxxxxx
>
> i.com> cc:
>
> Sent by: Subject:
> [eclipse-dev]
> Compile errors in today's 2.0.2 stream build
> eclipse-dev-admin@
>
> eclipse.org
>
>
>
> 10/09/2002 05:20
>
> PM
>
> Please respond to
>
> eclipse-dev
>
>
>
>
>
>
>
> Looks like the file extensions of my previous attachments
> caused alarm with
> some virus scanners. Here are the logs in a more familiar format:
>
> (See attached file: logs.zip)
>
> My apologies for any inconvenience.
>
> Sonia
>
> ----- Forwarded by Sonia Dimitrov/OTT/OTI on 10/09/2002 11:15 AM -----
>
> "Sonia Dimitrov"
> <Sonia_Dimitrov@ot To:
> eclipse-dev@xxxxxxxxxxx
> i.com> cc:
> Sent by: Subject:
> [eclipse-dev]
> Compile errors in today's 2.0.2 stream build
> eclipse-dev-admin@
> eclipse.org
>
>
> 10/09/2002 10:39
> AM
> Please respond to
> eclipse-dev
>
>
>
>
>
>
> (See attached file: cvstests.jar.bin.log)(See attached file:
> javadebugtests.jar.bin.log)(See attached file:
> javauitests.jar.bin.log)
>
> Contributors, please advise.
>
> Sonia
>
> ----- Forwarded by Sonia Dimitrov/OTT/OTI on 10/09/2002 10:36 AM -----
>
> sonia_dimitrov@ot
>
> i.com To:
> sonia_dimitrov@xxxxxxx, dean_roberts@xxxxxxx,
> cc:
>
> 10/09/2002 10:24 Subject:
> [eclipse-builder]
> Compile errors in build M20021009
> AM
>
>
>
>
>
>
>
> /builds/202/src/plugins/org.eclipse.jdt.debug.tests/temp.folde
> r/javadebugtests.jar.bin.log
>
>
>
>
> /builds/202/src/plugins/org.eclipse.jdt.ui.tests/temp.folder/j
> avauitests.jar.bin.log
>
>
>
>
> /builds/202/src/plugins/org.eclipse.team.tests.cvs.core/temp.f
> older/cvstests.jar.bin.log
>
>
>
>
>
>
> (See attached file: cvstests.jar.bin.log)(See attached file:
> javadebugtests.jar.bin.log)(See attached file:
> javauitests.jar.bin.log)
>
>
>
>
>
>
>
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
>
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
