You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2014/10/09 11:03:49 UTC

Blocker when trying to use Tycho, because we need ApacheDS-M18...

hi guys,

I'm fighting with studio tycho since yesterday, trying to get one plugin
passing the build, with no success (apacheds-launcher).

After hours of heavy digging, I found that the
apacheds-interceptors-number was not present in the
eclipse-target-platform/target/repository/plugins repository. So I tried
to undertand why, which was quite a PITA, as the maven run on
eclipse-target-platform/ does not provide a lot of information.

So I ran mvn -X clean install instead, and I got that :

!ENTRY org.eclipse.equinox.p2.publisher.eclipse 2 0 2014-10-09 09:58:48.143
!MESSAGE An error has occurred while adding the bundle
/Users/elecharny/apacheds/studio-tycho/eclipse-target-platform/target/source/plugins/api-ldap-schema-data-1.0.0-M23.jar.
!STACK 0
org.osgi.framework.BundleException: Invalid manifest header
Import-Package: "org.apache.directory.api.ldap.model.schema.registries"
: Cannot import a package more than once
"org.apache.directory.api.ldap.model.schema.registries"
        at
org.eclipse.osgi.internal.resolver.StateBuilder.checkImportExportSyntax(StateBuilder.java:819)
        at
org.eclipse.osgi.internal.resolver.StateBuilder.validateHeaders(StateBuilder.java:212)
        at
org.eclipse.osgi.internal.resolver.StateBuilder.createBundleDescription(StateBuilder.java:63)
        at
org.eclipse.osgi.internal.resolver.StateObjectFactoryImpl.createBundleDescription(StateObjectFactoryImpl.java:33)
        at
org.eclipse.equinox.p2.publisher.eclipse.BundlesAction.createBundleDescription(BundlesAction.java:541)
        at
org.eclipse.equinox.p2.publisher.eclipse.BundlesAction.createBundleDescription(BundlesAction.java:577)
        at
org.eclipse.equinox.p2.publisher.eclipse.BundlesAction.getBundleDescriptions(BundlesAction.java:891)
        at
org.eclipse.equinox.p2.publisher.eclipse.BundlesAction.perform(BundlesAction.java:711)
        at
org.eclipse.equinox.p2.publisher.Publisher$ArtifactProcess.run(Publisher.java:207)
        at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.executeBatch(SimpleArtifactRepository.java:1344)
        at
org.eclipse.equinox.p2.publisher.Publisher.publish(Publisher.java:231)
        at
org.eclipse.equinox.p2.publisher.AbstractPublisherApplication.run(AbstractPublisherApplication.java:283)
        at
org.eclipse.equinox.p2.publisher.AbstractPublisherApplication.run(AbstractPublisherApplication.java:253)
        at
org.eclipse.equinox.p2.publisher.AbstractPublisherApplication.start(AbstractPublisherApplication.java:317)
        at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at
org.eclipse.equinox.internal.app.AnyThreadAppLauncher.run(AnyThreadAppLauncher.java:26)
        at java.lang.Thread.run(Thread.java:745)

(among thousands of other lines).

Adn effectively, when you look at the target repository content, you
find that the api-ldap-schema-data jar is not present, which leads to
the missing apacheds-interceptors-number jar too.

So what is causing this error ?

When you look into the eclipse MANIFEST.MF file for the
api-ldap-schema-data project 1.0.0-M24, you have that :

Import-Package: org.apache.directory.api.asn1.util;version="[1.0,2)",
 org.apache.directory.api.i18n;version="[1.0,2)",
 org.apache.directory.api.ldap.model.entry;version="[1.0,2)",
 org.apache.directory.api.ldap.model.exception;version="[1.0,2)",
 org.apache.directory.api.ldap.model.ldif;version="[1.0,2)",
 org.apache.directory.api.ldap.model.message;version="[1.0,2)",
 org.apache.directory.api.ldap.model.name;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema.normalizers;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema.parsers;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema.registries;version="[1.0,2)",
 org.apache.directory.api.util;version="[1.0,2)",
 org.slf4j;version="[1.7,2)",
 org.apache.directory.api.ldap.model.schema.syntaxCheckers;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema.comparators;version="[1.0,2)",
 org.apache.directory.api.ldap.aci


which is just correct. Sadly, if you open the created jar in your
.m2/repository, here is what you have for the same jar, but with the
revision we use in Studio (1.0.0-M23) :


Import-Package:
 org.apache.directory.api.asn1.util;version="[1.0,2)",
 org.apache.directory.api.i18n;version="[1.0,2)",
 org.apache.directory.api.ldap.model.entry;version="[1.0,2)",
 org.apache.directory.api.ldap.model.exception;version="[1.0,2)",
 org.apache.directory.api.ldap.model.ldif;version="[1.0,2)",
 org.apache.directory.api.ldap.model.message;version="[1.0,2)",
 org.apache.directory.api.ldap.model.name;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema.normalizers;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema.parsers;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema.registries;version="[1.0,2)",
 org.apache.directory.api.util;version="[1.0,2)",
 org.slf4j;version="[1.7,2)",
 org.apache.directory.api.ldap.model.schema.registries,                        
<---------- WTF ???
 org.apache.directory.api.ldap.aci,
 org.apache.directory.api.ldap.model.schema.parsers,
 org.apache.directory.api.ldap.model.schema.syntaxCheckers;version="[1.0,2)",
 org.apache.directory.api.ldap.model.schema.normalizers,
 org.apache.directory.api.ldap.model.schema.comparators;version="[1.0,2)"


As we can see, the org.apache.directory.api.ldap.model.schema.registries
package is included twice, one with a given version, and another without
any version.

So why do we have this problem ?

That's clear and simple : Stefna has made a modification in the latest
LDAP API revision to remove this duplication (r1609304):

"Remove import-packages from generated MANIFEST.MF, they are now
imported by some classes and thus automatically put into manifest"

Which *will* solve this duplication issue.

Alas, we are pulling this 1.0.0-M23 revision from a transitiv dependency
from apacheds-2.0.0-M17, which still depends on this broken revision. At
this point, we *have* to get apacheDS 2.0.0-M18 released, otherwise we
are blocked on Studio because of this wrong API version :/

Ok, that is not all black and white. I have made a lot of progress in my
understanding on the Tycho process, and at this point, I wonder if it
would not be a good idea to review the API OSGified poms, and to start
doing the same work on ApacheDS and the other modules...

But first, I do think we *HAVE* to get a 2.0.0-M18 out asap.

thoughts ?

Re: Blocker when trying to use Tycho, because we need ApacheDS-M18...

Posted by Emmanuel Lécharny <el...@gmail.com>.

Le 10/10/14 00:02, Stefan Seelmann a écrit :
> Two thoughts inline...
>
> On 10/09/2014 11:03 AM, Emmanuel Lécharny wrote:
>> Alas, we are pulling this 1.0.0-M23 revision from a transitiv dependency
>> from apacheds-2.0.0-M17, which still depends on this broken revision. At
>> this point, we *have* to get apacheDS 2.0.0-M18 released, otherwise we
>> are blocked on Studio because of this wrong API version :/
> Would apacheds-2.0.0-M17 work with api-1.0.0-M24? In that case it should
> be possible to force the newer version somehow, isn't it?

The version is deduced by tycho. It's probably a better idea to use the
apacheDS SNAPSHOT at this point...
>
>> Ok, that is not all black and white. I have made a lot of progress in my
>> understanding on the Tycho process, and at this point, I wonder if it
>> would not be a good idea to review the API OSGified poms, and to start
>> doing the same work on ApacheDS and the other modules...
> That makes totally sense. And I wonder if there is some kind of test or
> verification that the generated OSGi bundle (especially the MANIFEST.MF)
> is valid, that there are no split packages, etc.?

Not that I know of. I'll check with a few people I know and who are more
deeply involved in OSGi.

I'm currently working on the LDAP API pom to expose the imported and
exported package explicitely, instead of expecting the felix plugin to
deduce the imported packages from the sources. This is a bit painful,
but that allows us to enforce the versions used for each of the imported
packages. More to come here...

Re: Blocker when trying to use Tycho, because we need ApacheDS-M18...

Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.

Two thoughts inline...

On 10/09/2014 11:03 AM, Emmanuel Lécharny wrote:
> Alas, we are pulling this 1.0.0-M23 revision from a transitiv dependency
> from apacheds-2.0.0-M17, which still depends on this broken revision. At
> this point, we *have* to get apacheDS 2.0.0-M18 released, otherwise we
> are blocked on Studio because of this wrong API version :/

Would apacheds-2.0.0-M17 work with api-1.0.0-M24? In that case it should
be possible to force the newer version somehow, isn't it?

> Ok, that is not all black and white. I have made a lot of progress in my
> understanding on the Tycho process, and at this point, I wonder if it
> would not be a good idea to review the API OSGified poms, and to start
> doing the same work on ApacheDS and the other modules...

That makes totally sense. And I wonder if there is some kind of test or
verification that the generated OSGi bundle (especially the MANIFEST.MF)
is valid, that there are no split packages, etc.?

Kind Regards,
Stefan