[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: eclipselink (new package, needed to package Spring Framework 3.0)

Miguel Landaeta wrote:
> Hi team,
> I am looking for a sponsor for my package "eclipselink".
> * Package name    : eclipselink
>   Version         : 2.0.2-1
>   Upstream Author : Oracle, Sun Microsystems Inc. and others
> * URL             : http://www.eclipse.org/eclipselink/
> * License         : Eclipse Public License, Eclipse Distribution License, BSD, GPL2, CDDL
>   Section         : java
> It builds these binary packages:
> libeclipselink-java - Eclipse Persistence Services Project
> libeclipselink-java-doc - Documentation for libeclipselink-java
> The package is lintian clean.
> The upload would fix these bugs: 581861.
> My motivation for maintaining this package is:
> This library is needed to package libspring-3.0-java.
> Besides, this is very useful in its own since provides
> several implementations of diverse persistence standards.
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/e/eclipselink
> - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
> - dget http://mentors.debian.net/debian/pool/main/e/eclipselink/eclipselink_2.0.2-1.dsc
> - Vcs-Git: git://git.debian.org/git/pkg-java/eclipselink.git
> I would be glad if someone uploaded this package for me.
> Regards,


The changelog on git and on mentors differ (the former still have
"UNRELEASED") - you may want to have the same release both on git and on
mentors, since some sponsors checkout the git rather than using mentors.

I am impressed at how fast you pulled together this java package, but
therein lies the problem as well - eclipse will not notice eclipselink,
and even if it did, it would not notice its dependencies.
  Unfortunately we have little (read: no) documentation in Debian on how
to do eclipse packages (not including eclipse itself), including you I
think we are about 3 or 4 people who has tried/has experience with it.
  It does not help that eclipselink is not "your average
eclipse"-package either. Their source zip contains the sources only
dumped together into one big pile, but their build (which they do not
ship) actually builds the source into smaller jars.

When it comes to eclipse, then Class-Path entries are ignored. Eclipse
uses its own ClassLoaders, which only care about the OSGi metadata. I
suspect the culprit is the OSGi standard and not eclipse in itself, but
nevertheless this is the sad truth.
  Without relevant OSGi metadata in the jar and /all/ of its
dependencies, eclipse either not bother looking at the jar or claim it
is unable to find the dependencies.

Furthermore, eclipse generally do not look at /usr/share/java (or
/usr/lib/java for that matter), it only looks in subdirs of
/usr/lib/eclipse. I am not entirely sure how/when/where it looks, but in
eclipselink case, we will need to ship the respective feature files (of
course, these are not available in their source zip either).

I will not rule out that this package is useful on its own as it as
(e.g. in case someone links directly against it), but eclipse will not
pick it up.
  If this is useful on its own, you may want to create a "library only"
version and a "eclipse integration" version of this package.


NB: Some may remember I filed a bug against Azureus regarding GPL and
EPL being incompatible. In case you were wondering why I have not
commented on EPL and GPL in the License listing:
  * The GPL part is not source code, so it is not linked to EPL code.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: