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...@symas.com> on 2014/12/20 17:23:04 UTC
[Studio] heads up
Hi !
so I implemented all the poml-first files, and it was not that complex.
I then tried to run a maven build...
First of all, I had to add the missing dependency on junit, for tests to
compile. Not a big deal, only a few modules requires this dependency.
Then, I tried to run :
mvn -f pom-first.xml install -DskipTests
(I don't need to run tests).
first run :
[INFO] parent ............................................ SUCCESS [
1.682 s]
[INFO] parent-plugins .................................... SUCCESS [
0.034 s]
[INFO] Apache Directory Studio ACI Item Editor Manifest Generation
FAILURE [ 1.856 s]
...
The errors are :
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]
/Users/elecharny/apacheds/stycho/plugins/aciitemeditor/src/main/java/org/apache/directory/studio/aciitemeditor/valueeditors/FilterValueEditor.java:[24,62]
package org.apache.directory.studio.ldapbrowser.common.dialogs does not
exist
[ERROR]
/Users/elecharny/apacheds/stycho/plugins/aciitemeditor/src/main/java/org/apache/directory/studio/aciitemeditor/valueeditors/FilterValueEditor.java:[25,62]
package org.apache.directory.studio.ldapbrowser.common.dialogs does not
exist
[ERROR]
/Users/elecharny/apacheds/stycho/plugins/aciitemeditor/src/main/java/org/apache/directory/studio/aciitemeditor/valueeditors/FilterValueEditor.java:[26,58]
package org.apache.directory.studio.ldapbrowser.core.model does not exist
[ERROR]
/Users/elecharny/apacheds/stycho/plugins/aciitemeditor/src/main/java/org/apache/directory/studio/aciitemeditor/valueeditors/FilterValueEditor.java:[27,58]
package org.apache.directory.studio.ldapbrowser.core.model does not exist
second run :
[INFO] parent ............................................ SUCCESS [
1.194 s]
[INFO] parent-plugins .................................... SUCCESS [
0.030 s]
[INFO] Apache Directory Studio ACI Item Editor Manifest Generation
SUCCESS [ 3.283 s]
[INFO] Apache Directory Studio ApacheDS Configuration Manifest
Generation FAILURE [ 2.477 s]
...
third run :
[INFO] parent ............................................ SUCCESS [
1.208 s]
[INFO] parent-plugins .................................... SUCCESS [
0.026 s]
[INFO] Apache Directory Studio ACI Item Editor Manifest Generation
SUCCESS [ 3.109 s]
[INFO] Apache Directory Studio ApacheDS Configuration Manifest
Generation SUCCESS [ 3.671 s]
[INFO] Apache Directory Studio ApacheDS 2.0 Configuration Manifest
Generation FAILURE [ 1.262 s]
...
As you can see, every time you re-run the build, one more module gets
successfully build. The pb is that the build order is not the expected
one : acieditor, which gets built first, depends on ldapbrowser.common, etc.
Eventually, if you just move on module by module, you end with a final
failure on the last module, schemaeditor. Here are the errors you get :
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]
/Users/elecharny/apacheds/stycho/plugins/schemaeditor/src/test/java/org/apache/directory/studio/schemaeditor/model/difference/DifferenceEngineTest.java:[28,50]
package org.apache.directory.api.ldap.model.schema does not exist
[ERROR]
/Users/elecharny/apacheds/stycho/plugins/schemaeditor/src/test/java/org/apache/directory/studio/schemaeditor/model/difference/DifferenceEngineTest.java:[29,50]
package org.apache.directory.api.ldap.model.schema does not exist
[ERROR]
/Users/elecharny/apacheds/stycho/plugins/schemaeditor/src/test/java/org/apache/directory/studio/schemaeditor/model/difference/DifferenceEngineTest.java:[30,50]
package org.apache.directory.api.ldap.model.schema does not exist
...
So there is some more work to do.
1) I have to re-order the plugins modules. They are clearly out of order.
2) I have to understand why the schemaeditor module does not compile
3) There is a mix of Import-Package and Require-Bundle. This is not
good. We shoudl discuss what we should do here, bu my take is that we
should use Import-Package for third paty dependencies (commons-lang,
etc) and Require-Bundle for our own components.
4) I have tried with the latest LDAP-API SNAPSHOT, but then I'm facing
another issue : there is one dependency that has some class at the top
level, which is stricly verboten. I still have to figure out which one
(see
https://developer.atlassian.com/docs/faq/plugin-framework-faq/using-jdom-in-osgi
for more insight on why could be the pb).
5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
oiut how to use them (there must be a solution, I just didn't had time
to investigate too much)
That's just a heads up, I still have some files to commit, but this
seems teh right approach to get the manifest geenrated automatically
instead of handling them ourselves using an editor... It makes me think
that even if we successfully succeed, we will have one more himalaya to
climb : releases...
Being a developper is the guarantee not to be bored, especially during
the long winter nights ;-)
Re: [Studio] heads up
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 20/12/14 17:54, Stefan Seelmann a écrit :
> Hi Emmanuel,
>
> I think there is no need to run the full "install" lifecycle, isn't it
> enought to run the bundle:manifest goal only to generate the manifests?
> Then also no order is required and no compilation will happen.
>
> mvn -f pom-first.xml bundle:manifest
Oh, that's right... Anyway, I fixed the order, which does the trick too.
Now I'm facing an issue when building with M27-SNAPSHOT :
[ERROR] Manifest
org.apache.directory.studio:org.apache.directory.studio.connection.core:bundle:2.0.0-SNAPSHOT
: The default package '.' is not permitted by the Import-Package syntax.
This can be caused by compile errors in Eclipse because Eclipse creates
valid class files regardless of compile errors.
The following package(s) import from the default package
[org.apache.directory.studio.connection.core,
org.apache.directory.studio.connection.core.io.jndi,
org.apache.directory.studio.connection.core.io,
org.apache.directory.studio.connection.core.io.api]
[ERROR] Error(s) found in manifest configuration
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] parent ............................................ SUCCESS [
0.322 s]
[INFO] parent-plugins .................................... SUCCESS [
0.004 s]
[INFO] Apache Directory Studio Common Core Manifest Generation SUCCESS
[ 0.509 s]
[INFO] Apache Directory Studio LDIF Parser Manifest Generation SUCCESS
[ 0.213 s]
[INFO] Apache Directory Studio Common UI Manifest Generation SUCCESS [
0.109 s]
[INFO] Apache Directory Studio ApacheDS Configuration Manifest
Generation SUCCESS [ 1.301 s]
[INFO] Apache Directory Studio Connection Core Manifest Generation
FAILURE [ 0.205 s]
>
> The main build is then be done by the "normal" pom.xml and Tycho:
>
> mvn clean install
>
> WDYT?
mvn -f pom-first.xml bundle:manifest
followed by
mvn clean install
in a shell script or a bat script is most certainly the way to go.
Re: [Studio] heads up
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Emmanuel,
I think there is no need to run the full "install" lifecycle, isn't it
enought to run the bundle:manifest goal only to generate the manifests?
Then also no order is required and no compilation will happen.
mvn -f pom-first.xml bundle:manifest
The main build is then be done by the "normal" pom.xml and Tycho:
mvn clean install
WDYT?
Kind Regards,
Stefan
On 12/20/2014 05:23 PM, Emmanuel Lécharny wrote:
> Hi !
>
> so I implemented all the poml-first files, and it was not that complex.
> I then tried to run a maven build...
>
> First of all, I had to add the missing dependency on junit, for tests to
> compile. Not a big deal, only a few modules requires this dependency.
>
> Then, I tried to run :
>
> mvn -f pom-first.xml install -DskipTests
>
> (I don't need to run tests).
>
> first run :
>
> [INFO] parent ............................................ SUCCESS [
> 1.682 s]
> [INFO] parent-plugins .................................... SUCCESS [
> 0.034 s]
> [INFO] Apache Directory Studio ACI Item Editor Manifest Generation
> FAILURE [ 1.856 s]
> ...
>
> The errors are :
>
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR]
> /Users/elecharny/apacheds/stycho/plugins/aciitemeditor/src/main/java/org/apache/directory/studio/aciitemeditor/valueeditors/FilterValueEditor.java:[24,62]
> package org.apache.directory.studio.ldapbrowser.common.dialogs does not
> exist
> [ERROR]
> /Users/elecharny/apacheds/stycho/plugins/aciitemeditor/src/main/java/org/apache/directory/studio/aciitemeditor/valueeditors/FilterValueEditor.java:[25,62]
> package org.apache.directory.studio.ldapbrowser.common.dialogs does not
> exist
> [ERROR]
> /Users/elecharny/apacheds/stycho/plugins/aciitemeditor/src/main/java/org/apache/directory/studio/aciitemeditor/valueeditors/FilterValueEditor.java:[26,58]
> package org.apache.directory.studio.ldapbrowser.core.model does not exist
> [ERROR]
> /Users/elecharny/apacheds/stycho/plugins/aciitemeditor/src/main/java/org/apache/directory/studio/aciitemeditor/valueeditors/FilterValueEditor.java:[27,58]
> package org.apache.directory.studio.ldapbrowser.core.model does not exist
>
>
> second run :
>
> [INFO] parent ............................................ SUCCESS [
> 1.194 s]
> [INFO] parent-plugins .................................... SUCCESS [
> 0.030 s]
> [INFO] Apache Directory Studio ACI Item Editor Manifest Generation
> SUCCESS [ 3.283 s]
> [INFO] Apache Directory Studio ApacheDS Configuration Manifest
> Generation FAILURE [ 2.477 s]
> ...
>
> third run :
> [INFO] parent ............................................ SUCCESS [
> 1.208 s]
> [INFO] parent-plugins .................................... SUCCESS [
> 0.026 s]
> [INFO] Apache Directory Studio ACI Item Editor Manifest Generation
> SUCCESS [ 3.109 s]
> [INFO] Apache Directory Studio ApacheDS Configuration Manifest
> Generation SUCCESS [ 3.671 s]
> [INFO] Apache Directory Studio ApacheDS 2.0 Configuration Manifest
> Generation FAILURE [ 1.262 s]
> ...
>
>
> As you can see, every time you re-run the build, one more module gets
> successfully build. The pb is that the build order is not the expected
> one : acieditor, which gets built first, depends on ldapbrowser.common, etc.
>
> Eventually, if you just move on module by module, you end with a final
> failure on the last module, schemaeditor. Here are the errors you get :
>
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR]
> /Users/elecharny/apacheds/stycho/plugins/schemaeditor/src/test/java/org/apache/directory/studio/schemaeditor/model/difference/DifferenceEngineTest.java:[28,50]
> package org.apache.directory.api.ldap.model.schema does not exist
> [ERROR]
> /Users/elecharny/apacheds/stycho/plugins/schemaeditor/src/test/java/org/apache/directory/studio/schemaeditor/model/difference/DifferenceEngineTest.java:[29,50]
> package org.apache.directory.api.ldap.model.schema does not exist
> [ERROR]
> /Users/elecharny/apacheds/stycho/plugins/schemaeditor/src/test/java/org/apache/directory/studio/schemaeditor/model/difference/DifferenceEngineTest.java:[30,50]
> package org.apache.directory.api.ldap.model.schema does not exist
> ...
>
>
> So there is some more work to do.
> 1) I have to re-order the plugins modules. They are clearly out of order.
> 2) I have to understand why the schemaeditor module does not compile
> 3) There is a mix of Import-Package and Require-Bundle. This is not
> good. We shoudl discuss what we should do here, bu my take is that we
> should use Import-Package for third paty dependencies (commons-lang,
> etc) and Require-Bundle for our own components.
> 4) I have tried with the latest LDAP-API SNAPSHOT, but then I'm facing
> another issue : there is one dependency that has some class at the top
> level, which is stricly verboten. I still have to figure out which one
> (see
> https://developer.atlassian.com/docs/faq/plugin-framework-faq/using-jdom-in-osgi
> for more insight on why could be the pb).
> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
> oiut how to use them (there must be a solution, I just didn't had time
> to investigate too much)
>
> That's just a heads up, I still have some files to commit, but this
> seems teh right approach to get the manifest geenrated automatically
> instead of handling them ourselves using an editor... It makes me think
> that even if we successfully succeed, we will have one more himalaya to
> climb : releases...
>
> Being a developper is the guarantee not to be bored, especially during
> the long winter nights ;-)
>
Re: [Studio] heads up
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 21/12/14 09:04, Emmanuel Lécharny a écrit :
> Le 20/12/14 20:28, Stefan Seelmann a écrit :
>>> 4) I have tried with the latest LDAP-API SNAPSHOT, but then I'm facing
>>> another issue : there is one dependency that has some class at the top
>>> level, which is stricly verboten. I still have to figure out which one
>>> (see
>>> https://developer.atlassian.com/docs/faq/plugin-framework-faq/using-jdom-in-osgi
>>> for more insight on why could be the pb).
>> Which dependency is that? jdom? Do we use jdom? I thought we only use
>> dom4j, but that is also a problematic dependency.
> We don't use jdom, I just posted the URL to expose the potential pb if
> there is a jar with a class on teh top level.
HOLLY.
FUCK...
Have a look at that :
http://mail-archives.apache.org/mod_mbox/felix-users/201306.mbox/%3C75B35C5A87A140D9993ADE457ADFB2FA@gmail.com%3E
It says : "You probably have Eclipse open on this project" (you bet I
have !) "and there are compile errors" (MANY !). "Eclipse still outputs
a class file for java sources with compile errors" (Stupid eclipse...)
"but these classesare weird. In particular they depend on the default
package "." " WHAT????
Yes, you get it now : Eclipse creates weird .class files into the
default package, and when you run mavn-bundle-plugin, it will throw
error messages because if this stupid useless class being around.
The solution :
mvn -f pom-first.xml ***clean*** bundle:manifest
The "clean" phase will remove all the .class files and then, the
MANIFEST.MF will be correctly built...
I can't believe it :/
Re: [Studio] heads up
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 21/12/14 10:46, Jeff MAURY a écrit :
> On Sun, Dec 21, 2014 at 9:04 AM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
> How to transform a good idea to a bad one by simply not fixing their tools
> !
>
> They are just right on this topic.
Bloody hell no !
> Maven guys are planning to change
> SNAPSHOT behavior and replace it with a timed-version of the artifact.
So what ? You still have X.Y.Z-timstamp > X.Y.Z, when the whole idea was
that a SNAPSHOT was precluding the final revision. A timestamp is still
incremental, and if you consider that anything added after X.Y.Z is just
an indication that X.Y.Z i not ready, then I don't see how -SNAPSHOT
can't do the trick ?
All in all, the base point is to forbid anyone to use a fixed revision
inside some package, thus the -SNAPSHOT notation : it's guarantee not to
guarantee anything. By using a timestamp instead, you will soon see many
released package using such broken packages.
But most of all, the 'excuse' not to accept SNAPSHOTS in OSGi 5 (when it
was supposed to be included in r5 specs) because, is : "It breaks
tools". Fucking lame excuse, sounds like "All we do have is a hammer, so
your screws better look like nails". Idiotic, to say the least...
Re: [Studio] heads up
Posted by Jeff MAURY <je...@jeffmaury.com>.
On Sun, Dec 21, 2014 at 9:04 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 20/12/14 20:28, Stefan Seelmann a écrit :
> >
> >> 4) I have tried with the latest LDAP-API SNAPSHOT, but then I'm facing
> >> another issue : there is one dependency that has some class at the top
> >> level, which is stricly verboten. I still have to figure out which one
> >> (see
> >>
> https://developer.atlassian.com/docs/faq/plugin-framework-faq/using-jdom-in-osgi
> >> for more insight on why could be the pb).
> > Which dependency is that? jdom? Do we use jdom? I thought we only use
> > dom4j, but that is also a problematic dependency.
>
> We don't use jdom, I just posted the URL to expose the potential pb if
> there is a jar with a class on teh top level.
>
> >
> >> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
> >> oiut how to use them (there must be a solution, I just didn't had time
> >> to investigate too much)
> > Right, instead of -SNAPSHOT one has to use .qualifier. The
> > maven-bundle-plugin should convert that automatically. But I agree it is
> > confusing.
>
> It's not confusing, it's completely broken. The OSGi guys are totally
> fucked up here. Just because their tools are expecting the version to
> always increase (compared to Maven where x.y.z-SNAPSHOT < x.y.z), you
> can't use SNAPSHOTS. And they rejected the proposal to include SNAPSHOT
> versionning scheme for stupid reasons... Anyway, at some point in the
> future, there will be an epiphany on thir side, or they will lose the
> battle for something smarter. May be Java 9 or Java 10 will make then
> OSGi completely useless...
>
> How to transform a good idea to a bad one by simply not fixing their tools
> !
>
They are just right on this topic. Maven guys are planning to change
SNAPSHOT behavior and replace it with a timed-version of the artifact.
Jeff
--
Jeff MAURY
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Re: [Studio] heads up
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 22/12/14 12:02, Stefan Seelmann a écrit :
> On 12/22/2014 11:29 AM, Emmanuel Lécharny wrote:
>> Le 21/12/14 18:40, Stefan Seelmann a écrit :
>>> On 12/21/2014 01:57 PM, Emmanuel Lécharny wrote:
>>>> Le 21/12/14 12:01, Stefan Seelmann a écrit :
>>>>> On 12/21/2014 09:04 AM, Emmanuel Lécharny wrote:
>>>>>>>> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
>>>>>>>> oiut how to use them (there must be a solution, I just didn't had time
>>>>>>>> to investigate too much)
>>>>>>> Right, instead of -SNAPSHOT one has to use .qualifier. The
>>>>>>> maven-bundle-plugin should convert that automatically. But I agree it is
>>>>>>> confusing.
>>>>>> removed rant
>>>>> Ok, but for dependency version it is still possible to use snapshot when
>>>>> following the version scheme x.y.z.qualifier, e.g. 1.0.0.M27-SNAPSHOT is
>>>>> a vaild version. Maven-bundle-plugins takes care to create such a valid
>>>>> OSGi version.
>>> I was wrong again. The maven-bundle-plugin converts the module version
>>> 2.0.0-SNAPSHOT to 2.0.0.SNAPSHOT in the manifest.mf, so far so good. But
>>> then tycho complains because it expects that Bundle-Version is
>>> 2.0.0.qualifier. I'll try to set the version of pom-first.xml to
>>> 2.0.0.qualifier...
>> That could work. My concern is about the fact that pom-first will use
>> qualifier to generate MANIFESTs, but the P2 generation should use
>> SNAPSHOT, so is the general build.
>>
>> Do you think it can fly this way ?
>>
> Yes, I think. The pom-first build is completely independent from the
> main tycho build. There is also no need to release any of the pom-first
> artifacts. Is is really only there to generate the manifest.mf files.
>
Ok, thanks for the heads up !
Re: [Studio] heads up
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 12/22/2014 11:29 AM, Emmanuel Lécharny wrote:
> Le 21/12/14 18:40, Stefan Seelmann a écrit :
>> On 12/21/2014 01:57 PM, Emmanuel Lécharny wrote:
>>> Le 21/12/14 12:01, Stefan Seelmann a écrit :
>>>> On 12/21/2014 09:04 AM, Emmanuel Lécharny wrote:
>>>>>>> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
>>>>>>> oiut how to use them (there must be a solution, I just didn't had time
>>>>>>> to investigate too much)
>>>>>> Right, instead of -SNAPSHOT one has to use .qualifier. The
>>>>>> maven-bundle-plugin should convert that automatically. But I agree it is
>>>>>> confusing.
>>>>> removed rant
>>>> Ok, but for dependency version it is still possible to use snapshot when
>>>> following the version scheme x.y.z.qualifier, e.g. 1.0.0.M27-SNAPSHOT is
>>>> a vaild version. Maven-bundle-plugins takes care to create such a valid
>>>> OSGi version.
>> I was wrong again. The maven-bundle-plugin converts the module version
>> 2.0.0-SNAPSHOT to 2.0.0.SNAPSHOT in the manifest.mf, so far so good. But
>> then tycho complains because it expects that Bundle-Version is
>> 2.0.0.qualifier. I'll try to set the version of pom-first.xml to
>> 2.0.0.qualifier...
>
> That could work. My concern is about the fact that pom-first will use
> qualifier to generate MANIFESTs, but the P2 generation should use
> SNAPSHOT, so is the general build.
>
> Do you think it can fly this way ?
>
Yes, I think. The pom-first build is completely independent from the
main tycho build. There is also no need to release any of the pom-first
artifacts. Is is really only there to generate the manifest.mf files.
Re: [Studio] heads up
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 21/12/14 18:40, Stefan Seelmann a écrit :
> On 12/21/2014 01:57 PM, Emmanuel Lécharny wrote:
>> Le 21/12/14 12:01, Stefan Seelmann a écrit :
>>> On 12/21/2014 09:04 AM, Emmanuel Lécharny wrote:
>>>>>> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
>>>>>> oiut how to use them (there must be a solution, I just didn't had time
>>>>>> to investigate too much)
>>>>> Right, instead of -SNAPSHOT one has to use .qualifier. The
>>>>> maven-bundle-plugin should convert that automatically. But I agree it is
>>>>> confusing.
>>>> removed rant
>>> Ok, but for dependency version it is still possible to use snapshot when
>>> following the version scheme x.y.z.qualifier, e.g. 1.0.0.M27-SNAPSHOT is
>>> a vaild version. Maven-bundle-plugins takes care to create such a valid
>>> OSGi version.
> I was wrong again. The maven-bundle-plugin converts the module version
> 2.0.0-SNAPSHOT to 2.0.0.SNAPSHOT in the manifest.mf, so far so good. But
> then tycho complains because it expects that Bundle-Version is
> 2.0.0.qualifier. I'll try to set the version of pom-first.xml to
> 2.0.0.qualifier...
That could work. My concern is about the fact that pom-first will use
qualifier to generate MANIFESTs, but the P2 generation should use
SNAPSHOT, so is the general build.
Do you think it can fly this way ?
Re: [Studio] heads up
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 12/21/2014 01:57 PM, Emmanuel Lécharny wrote:
> Le 21/12/14 12:01, Stefan Seelmann a écrit :
>> On 12/21/2014 09:04 AM, Emmanuel Lécharny wrote:
>>>>> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
>>>>> oiut how to use them (there must be a solution, I just didn't had time
>>>>> to investigate too much)
>>>> Right, instead of -SNAPSHOT one has to use .qualifier. The
>>>> maven-bundle-plugin should convert that automatically. But I agree it is
>>>> confusing.
>>> removed rant
>> Ok, but for dependency version it is still possible to use snapshot when
>> following the version scheme x.y.z.qualifier, e.g. 1.0.0.M27-SNAPSHOT is
>> a vaild version. Maven-bundle-plugins takes care to create such a valid
>> OSGi version.
I was wrong again. The maven-bundle-plugin converts the module version
2.0.0-SNAPSHOT to 2.0.0.SNAPSHOT in the manifest.mf, so far so good. But
then tycho complains because it expects that Bundle-Version is
2.0.0.qualifier. I'll try to set the version of pom-first.xml to
2.0.0.qualifier...
Kind Regards,
Stefan
Re: [Studio] heads up
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 21/12/14 12:01, Stefan Seelmann a écrit :
> On 12/21/2014 09:04 AM, Emmanuel Lécharny wrote:
>>>> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
>>>> oiut how to use them (there must be a solution, I just didn't had time
>>>> to investigate too much)
>>> Right, instead of -SNAPSHOT one has to use .qualifier. The
>>> maven-bundle-plugin should convert that automatically. But I agree it is
>>> confusing.
>> removed rant
> Ok, but for dependency version it is still possible to use snapshot when
> following the version scheme x.y.z.qualifier, e.g. 1.0.0.M27-SNAPSHOT is
> a vaild version. Maven-bundle-plugins takes care to create such a valid
> OSGi version.
>
> One problem we have is the p2-maven-plugin, the I choosed to generate
> the initial P2 repo. That doesn't allow SNAPSHOT currently but replaces
> it with a timestamp. I think we can get rid of if, I'll try...
Many thanks for the heads up, Stefan
Re: [Studio] heads up
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 12/21/2014 09:04 AM, Emmanuel Lécharny wrote:
>>> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
>>> oiut how to use them (there must be a solution, I just didn't had time
>>> to investigate too much)
>> Right, instead of -SNAPSHOT one has to use .qualifier. The
>> maven-bundle-plugin should convert that automatically. But I agree it is
>> confusing.
>
> removed rant
Ok, but for dependency version it is still possible to use snapshot when
following the version scheme x.y.z.qualifier, e.g. 1.0.0.M27-SNAPSHOT is
a vaild version. Maven-bundle-plugins takes care to create such a valid
OSGi version.
One problem we have is the p2-maven-plugin, the I choosed to generate
the initial P2 repo. That doesn't allow SNAPSHOT currently but replaces
it with a timestamp. I think we can get rid of if, I'll try...
Kind Regards,
Stefan
Re: [Studio] heads up
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 20/12/14 20:28, Stefan Seelmann a écrit :
>
>> 4) I have tried with the latest LDAP-API SNAPSHOT, but then I'm facing
>> another issue : there is one dependency that has some class at the top
>> level, which is stricly verboten. I still have to figure out which one
>> (see
>> https://developer.atlassian.com/docs/faq/plugin-framework-faq/using-jdom-in-osgi
>> for more insight on why could be the pb).
> Which dependency is that? jdom? Do we use jdom? I thought we only use
> dom4j, but that is also a problematic dependency.
We don't use jdom, I just posted the URL to expose the potential pb if
there is a jar with a class on teh top level.
>
>> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
>> oiut how to use them (there must be a solution, I just didn't had time
>> to investigate too much)
> Right, instead of -SNAPSHOT one has to use .qualifier. The
> maven-bundle-plugin should convert that automatically. But I agree it is
> confusing.
It's not confusing, it's completely broken. The OSGi guys are totally
fucked up here. Just because their tools are expecting the version to
always increase (compared to Maven where x.y.z-SNAPSHOT < x.y.z), you
can't use SNAPSHOTS. And they rejected the proposal to include SNAPSHOT
versionning scheme for stupid reasons... Anyway, at some point in the
future, there will be an epiphany on thir side, or they will lose the
battle for something smarter. May be Java 9 or Java 10 will make then
OSGi completely useless...
How to transform a good idea to a bad one by simply not fixing their tools !
Re: [Studio] heads up
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 12/20/2014 05:23 PM, Emmanuel Lécharny wrote:
> 3) There is a mix of Import-Package and Require-Bundle. This is not
> good. We shoudl discuss what we should do here, bu my take is that we
> should use Import-Package for third paty dependencies (commons-lang,
> etc) and Require-Bundle for our own components.
I agree.
> 4) I have tried with the latest LDAP-API SNAPSHOT, but then I'm facing
> another issue : there is one dependency that has some class at the top
> level, which is stricly verboten. I still have to figure out which one
> (see
> https://developer.atlassian.com/docs/faq/plugin-framework-faq/using-jdom-in-osgi
> for more insight on why could be the pb).
Which dependency is that? jdom? Do we use jdom? I thought we only use
dom4j, but that is also a problematic dependency.
> 5) OSGi does not really like SNAPSHOT a lot. I still have to firgure
> oiut how to use them (there must be a solution, I just didn't had time
> to investigate too much)
Right, instead of -SNAPSHOT one has to use .qualifier. The
maven-bundle-plugin should convert that automatically. But I agree it is
confusing.
> That's just a heads up, I still have some files to commit, but this
> seems teh right approach to get the manifest geenrated automatically
> instead of handling them ourselves using an editor... It makes me think
> that even if we successfully succeed, we will have one more himalaya to
> climb : releases...
lol, I still avoid to think about releases, it's still too far away...