[oe-issues] [Bug 2729] New: java package midpath wrongly assigned RPROVIDES

[bugzilla-daemon at tinman.treke.net]

http://bugs.openembedded.org/show_bug.cgi?id=2729

           Summary: java package midpath wrongly assigned RPROVIDES
           Product: Openembedded
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Build
        AssignedTo: openembedded-issues at lists.openembedded.org
        ReportedBy: thebohemian at gmx.net


Hi,
the java package midpath is an implementation of MIDP2.0 it should therefore
RPROVIDES virtual/midp2.0 or similar.

Since midpath's author did not separate the source files for the cldc-api
things are a bit intermixed. However specification-wise cldc1.1 has nothing to
do with midp2.0.

midpath.jar is the primary artifact of the project and it is compatible to be
run on J2SE (=> implemented by GNU Classpath) and CLDC1.1 (=> implemented by
cldc1.1-api.jar which is taken from Sun's phoneME project).

So here is my suggestion for the depencies:

- midpath.jar and midpath-resources.jar make up package midpath which depends
upon virtual/cldc1.1 OR virtual/java (= happens to be j2se actually) and
provides virtal/midp2.0.

- cldc1.1-api.jar along with a compatible runtime (cacao-cldc) provide
virtual/cldc1.1

Historically a combination of GNU Classpath and Cacao/JamVM/Kaffe provides
virtual/java but that is a problematic generalisation in times where the user
can have j2se (big), cldc1.1 (medium) or midp2.0 (small) java environments.
Ideally GNU Classpath + JamVM/Cacao/.. should provide virtual/j2se and the user
should decide what kind of virtual/java she wants. That is probably another bug
report.


-- 
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.