One has to wonder why the PDE should be restricted to 1.4. It's not as
if it needs to run on small devices is it? Isn't 1.4 End of Life
already too? It seems hard to argue that it's important for the full
IDE to run on such an old JRE. I suppose that's more of a pde-dev
question...
Curtis Windatt wrote:
@Ian Yes, the error has
not been
fixed by Pascal's changes. The 1.4 binaries are available, so the
error is not affecting my work, other than having an annoying red x in
my file :)
@Thomas The Eclipse Platform
project
is strictly 1.4. Both PDE UI and PDE Build are using p2 apis.
Curtis
Maybe I'm doing something wrong, but I have a Java 1.4
project that depends on p2 (much like PDE does) and I still get the
same
error that Curtis pointed out. I have the p2 sources in my workspace.
Maybe this wasn't the problem we were trying to solve.
cheers,
ian
On Wed, Jan 6, 2010 at 12:05 AM, Daniel Le Berre <leberre@xxxxxxxxxxxxxxxxxxx>
wrote:
Thomas,
We should be able to make this work inside Eclipse Workspace because I
am using ECJ to build SAT4J bundles:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=286391
We just need to be careful about the version of eclipse (compiler) we
use (it must be at least 3.6M2 or 3.5.1 AFAIR).
You can see that in the current code: you use sat4j generics in the
Projector class for instance.
Daniel
Thomas Hallgren a écrit :
>
> This was one of my worries too. I really want to use the p2
generics
in
> Buckminster but I'm not too keen on having all the p2 source in my
> workspace.
>
> In my opinion, we should compile the p2 source for Java 1.4 for two
> purposes:
> 1. For testing that everything indeed can run on such a platform.
> 2. To provide 1.4 based bytecodes for platforms where no 1.5
alternative
> exists.
>
> Question is, what platforms is it that needs to remain on 1.4?
Isn't
> that just a few embedded devices? If so, shouldn't the default be
to
> compile for 1.5 and then to provide special down-compiled distros
for
> those embedded devices? If I remember correctly, there are some
> significant gains (size and performance) when compiling for 1.5
compared
> to the 1.4.
>
> Just a thought. I realize that it goes beyond the p2 domain.
>
> - thomas
>
>
> On 2010-01-05 23:18, Daniel Le Berre wrote:
>> Indeed, it works.
>>
>> However, I am wondering if it is really a good idea: working
that
way
>> with generics prevents one project to see the generic classes
of another
>> project, correct?
>> (If I apply the same technique for sat4j, I can no longer use
the
>> generic classes of org.sat4j.core in org.sat4j.pb!!!!)
>>
>> It is the expected behavior for PDE people for instance
reusing
p2
>> bundles.
>>
>> But inside p2 projects, it would mean inability to share
generic
code
>> between bundles...
>>
>> Daniel
>>
>> Pascal Rapicault a écrit :
>>
>>> I have released the changes to the project preference
settings
in the p2
>>> projects to enable down compilation in the IDE.
>>>
>>>
>>> Inactive hide details for Curtis Windatt---04/01/2010
10:54:45
>>> PM---Recently a number of the query API were changed to
use
geneCurtis
>>> Windatt---04/01/2010 10:54:45 PM---Recently a number of
the
query API
>>> were changed to use generics, this causes some annoyances
in PDE (as we
>>> are strictly 1.4), b
>>>
>>>
>>> From:
>>> Curtis Windatt/Ottawa/IBM@IBMCA
>>>
>>> To:
>>> P2 developer discussions<p2-dev@xxxxxxxxxxx>
>>>
>>> Date:
>>> 04/01/2010 10:54 PM
>>>
>>> Subject:
>>> [p2-dev] Extending classes with generics
>>>
>>>
------------------------------------------------------------------------
>>>
>>>
>>>
>>> Recently a number of the query API were changed to use
generics,
this
>>> causes some annoyances in PDE (as we are strictly 1.4),
but
up until now
>>> I can work around them. However, I have a problem
extending
a class with
>>> generics, specifically MatchQuery
>>>
>>> IQuery query = new MatchQuery() {
>>> public boolean isMatch(Object candidate) {
>>> if (candidate instanceof IInstallableUnit) {
>>> if (P2Utils.isBundle((IInstallableUnit) candidate)) {
>>> return true;
>>> }
>>> }
>>> return false;
>>> }
>>> };
>>>
>>> The compiler complains that I need to extend the isMatch(T
candidate)
>>> instead, but I am unable to use generics in PDE.
>>>
>>> As a side note, why was size() removed from IQueryResult?
It was quite
>>> convenient for me when creating arrays of
InstallableUnitDescriptions
>>> and other objects that get filled in based on the query
result
iterator.
>>> Now I have to grab one of the sets and ask it for the
size.
Not a big
>>> deal, but it felt natural to ask the result for its size,
since you can
>>> ask it for an iterator.
>>>
>>> Curtis_______________________________________________
>>> p2-dev mailing list
>>> p2-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>
>>>
>>>
>>>
------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> p2-dev mailing list
>>> p2-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>
>>
>>
>
>
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
>
--
Daniel Le Berre mailto:leberre@xxxxxxxxxxxxxxxxxxx
MCF, CRIL-CNRS UMR
8188, Universite d'Artois
http://www.cril.univ-artois.fr/~leberre
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com
| http://twitter.com/eclipsesource_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|