These are chat archives for ceylon/ceylon-ide-eclipse

6th
Apr 2016
Stéphane Épardaud
@FroMage
Apr 06 2016 07:35
am now
David Festal
@davidfestal
Apr 06 2016 07:35
so I spent quite much time yesterday trying to fix the OSGI problem
but fixing the versions is not as simple as it seems
because in several places we depend on having unbound versions
especially how we manage the qualifier
a [1.2.3, 1.2.3] import doesn't include 1.2.3.vxxxxx
of course
Stéphane Épardaud
@FroMage
Apr 06 2016 07:37
I've come to hate that qualifier
David Festal
@davidfestal
Apr 06 2016 07:37
well, it's just an example of the problems it could bring
but not the main point
the main point is that even by requiring fix version imports
we have not solved the real problem
because we still change the OSGI metadata of bundles that might already be installed in a container
and in such a case the problem will still happen
Stéphane Épardaud
@FroMage
Apr 06 2016 07:39
well, what's the solution, then?
David Festal
@davidfestal
Apr 06 2016 07:39
so IMO we have only 2 solutions:
  • either rename the deps we change
like ceylon.distribution.<originalName>
or something like that
so we're sure that it doesn't override an existing official jar with your modified jar
Stéphane Épardaud
@FroMage
Apr 06 2016 07:40
but it will still conflict with package imports, no?
David Festal
@davidfestal
Apr 06 2016 07:40
  • use the original dep jar when it already contains OSGI metadata
@FroMage : why ?
Stéphane Épardaud
@FroMage
Apr 06 2016 07:40
now two jars with different bundle names will export the same packages
our jar and the eclipse jar
David Festal
@davidfestal
Apr 06 2016 07:41
java archives don't need to have a match between bundle / jar name and the contained packages
Stéphane Épardaud
@FroMage
Apr 06 2016 07:41
well, I'm fine with renaming
David Festal
@davidfestal
Apr 06 2016 07:41
yeah, I know
Stéphane Épardaud
@FroMage
Apr 06 2016 07:41
that'll probably be easier
David Festal
@davidfestal
Apr 06 2016 07:42
what we can do is:
Stéphane Épardaud
@FroMage
Apr 06 2016 07:42
that's only for eclipse anyway, right?
David Festal
@davidfestal
Apr 06 2016 07:42
only for OSGI at least
and mainly only for aether
the other deps we have generally don't have any OSGI metadata
however I feel it we be better to rename them to publishing a modified version of a public archive with the same name / version
another important point is that
for some of these jars
guava for example
the OSGI bundle-name
is not the same as the Ceylon module name
for example
com.google.guava in OSGI
and com.google.guava.guava in the ceylon.runtime repo
Stéphane Épardaud
@FroMage
Apr 06 2016 07:45
well, we can fix that
David Festal
@davidfestal
Apr 06 2016 07:45
this would also plead for a rename
yes, we can fix it
Stéphane Épardaud
@FroMage
Apr 06 2016 07:45
I used a name to import them, derived from the maven name
but I could have picked the osgi name if I had known there was one
David Festal
@davidfestal
Apr 06 2016 07:46
but again by changing something to the jar
Stéphane Épardaud
@FroMage
Apr 06 2016 07:46
so we can rename it in our repo if you want
no, not in the jar
in our repo
David Festal
@davidfestal
Apr 06 2016 07:46
yeah, it would be the best surely
Stéphane Épardaud
@FroMage
Apr 06 2016 07:46
we can name it com.google.guava
if you think it's important
that'd be fine by me
David Festal
@davidfestal
Apr 06 2016 07:47
in fact yesterday I tried the solution of keeping the jar that already have OSGI metadata as is
but then I encountered another problem
with tycho this time
guava bundle has an optional import-package
to sun.misc
which is not resolved by tycho
which produced an error
This one I was able to fix
then
I have other tycho errors with aether
but if I succeed in fixing them
we can use standard / unchanged OSGI bundles in our distribution
that would avoid a renaming
and would allow using already-installed bundles when they already exist in containers
knwing that all the aether stuff is needed only for Eclipse
I'll keep you informed
Stéphane Épardaud
@FroMage
Apr 06 2016 07:50
yeah, they use sun.misc.Unsafe
David Festal
@davidfestal
Apr 06 2016 07:50
but good to know you're not against renaming if the alternate solution (keep OSGI bundles unchanged) fails
Stéphane Épardaud
@FroMage
Apr 06 2016 07:50
that's from the JDK, though
David Festal
@davidfestal
Apr 06 2016 07:50
it's optional
since it's not exported by any OSGI container by defauult
so tycho doesn't know how to resolve it
Stéphane Épardaud
@FroMage
Apr 06 2016 07:50
well, the names are what I made up based on the maven names, so we can always change them
David Festal
@davidfestal
Apr 06 2016 07:51
and tycho doesn't offer a way to bypass optional dependencies :-(
sure
Stéphane Épardaud
@FroMage
Apr 06 2016 07:51
it's from the JDK, it doesn't need to be exported by an OSGi container, does it?
David Festal
@davidfestal
Apr 06 2016 07:52
the OSGI container export some JDK packages but not all
by default
and tycho (which is not really an OSGI container) doesn't see the sun.misc package
but for this I found the workaround
so let me finish testing the way with unchanged OSGI bundles
(unchanged OSGI metadata)
and if it doesn't work we can work with renaming, but as you said, there is still a risk to produce import package conflicts
if a package is exported by 2 different bundles (one that uses require-bundle and the other that uses import-package)
I'llkeep you informed as soon as I've finished testing the first solution
Stéphane Épardaud
@FroMage
Apr 06 2016 07:55
ok
Roland Tepp
@luolong
Apr 06 2016 08:19

a [1.2.3, 1.2.3] import doesn't include 1.2.3.vxxxxx

Maybe change that to [1.2.3,1.2.4)

or simply use 1.2.3
David Festal
@davidfestal
Apr 06 2016 08:20
yes, we should do something like that but this requires additional complexity in the ant build
parse the version etc ...
and I would do it only if we're sure this solution is the right one :-)
Roland Tepp
@luolong
Apr 06 2016 08:21
yeah .. we hate complexity, right...
David Festal
@davidfestal
Apr 06 2016 08:21
well, the ant build is already complex enough :-)
Roland Tepp
@luolong
Apr 06 2016 08:22
:D
David Festal
@davidfestal
Apr 06 2016 09:14
@FroMage : Here is the current list of inconsistencies between name of dependencies in the distribution Ceylon repo and the already existing OSGI names inside the archives:

Name in the Ceylon repo -> Already existing OSGI Bundle-SymbolicName

com.google.guava.guava -> com.google.guava
org.eclipse.aether.aether-api -> org.eclipse.aether.api
org.eclipse.aether.aether-connector-basic -> org.eclipse.aether.connector.basic
org.eclipse.aether.aether-impl -> org.eclipse.aether.impl
org.eclipse.aether.aether-spi -> org.eclipse.aether.spi
org.eclipse.aether.aether-transport-file -> org.eclipse.aether.transport.file
org.eclipse.aether.aether-transport-http -> org.eclipse.aether.transport.http
org.eclipse.aether.aether-util -> org.eclipse.aether.util
org.jboss.logmanager -> org.jboss.logmanager.jboss-logmanager
org.slf4j.api -> slf4j.api
org.slf4j.simple -> slf4j.simple

all the guava and aether are new
but the slf4j and logmanager inconsistencies have already been there for a while
Bastien Jansen
@bjansen
Apr 06 2016 09:15
how come we have so much problems with OSGI stuff?
people don't follow OSGI naming rules?
David Festal
@davidfestal
Apr 06 2016 09:16
well, there are sometimes differencies between the maven name and the OSGI bundlename
Bastien Jansen
@bjansen
Apr 06 2016 09:17
I saw the same kind of things in the NetBeans RCP, where modules which are supposedly OSGI-compliant have package names that can be found in more than one module
David Festal
@davidfestal
Apr 06 2016 09:17
and also utnil now we were overwriting OSGI metadata with information coming from the JBoss Modules module.xml descriptor
but now wit the new aether deps
we're finding a case where it doesn't work anymore
@bjansen : split packages are allowed in OSGI but not recommended wince they bring problems
Bastien Jansen
@bjansen
Apr 06 2016 09:18
ah ok
David Festal
@davidfestal
Apr 06 2016 09:18
but remember that the prefered dependency levelin OSGI is the package level
on the contrary it's the module /bundle level for Ceylon
David Festal
@davidfestal
Apr 06 2016 09:25
@FroMage : I'll try to rename everything consistenty with OSGI
and see where it brings me
David Festal
@davidfestal
Apr 06 2016 09:32
at least let me do it for the new stuf t least
(and not change the slf4j and jbosslogmanager stuff)
Stéphane Épardaud
@FroMage
Apr 06 2016 09:47
right, don't touch slf4j
I don't want that as a toplevel in herd
it's wrong
the rest I don't care
David Festal
@davidfestal
Apr 06 2016 09:47
yeah
Stéphane Épardaud
@FroMage
Apr 06 2016 09:47
they need to be renamed in many places
David Festal
@davidfestal
Apr 06 2016 09:48
And I'll keep the previous behavior for slf4j and jboss log manager (overwrite OSGI metadata) since they are renamed
Stéphane Épardaud
@FroMage
Apr 06 2016 09:48
the build, CeylonClassLoader, the module.xml files and folders in ceylon-runtime
David Festal
@davidfestal
Apr 06 2016 09:49
I'm modifying the aether and guava related paths and module.xml in the runtime/dist/repo
Roland Tepp
@luolong
Apr 06 2016 10:05
What about doing it the other way around for OSGI metadata // instead of declaring dependencies via Require-Bundle, we declare them all via Import-Package instead…?
David Festal
@davidfestal
Apr 06 2016 10:06
I thought of this also yes
but for the moment the problem is not with artifact we produce (.CAR archives)
Roland Tepp
@luolong
Apr 06 2016 10:06
The thing is — Ceylon modules all have naming convention that basically says, that their root package must start with module name
David Festal
@davidfestal
Apr 06 2016 10:07
it's with already existng jars with already existing OSGI metadata that we were overwriting
So for the moment the bug I'm trying to fix is related to exyernl jar dependencies
Roland Tepp
@luolong
Apr 06 2016 10:08
eh … yeah … this will not solve that, but it might help with future evolution of modules...
David Festal
@davidfestal
Apr 06 2016 10:08
as for the automatic generationof OSGI metadata by the ceylon compiler
Roland Tepp
@luolong
Apr 06 2016 10:08
… splitting up modules, etc.
David Festal
@davidfestal
Apr 06 2016 10:08
I agree we could give an option
to do that
but I also think that the Ceylon module in OSGI should by default behave as most as possible the same as it behaves in a Ceylon context
by the way it is already possible to manually replace a generated require-bundle header by import-package directives
Roland Tepp
@luolong
Apr 06 2016 10:10
yeah, I would make it default … it’s not going to affect CMR at all, I guess, but it might make it easier for folks in the OSGi land...
David Festal
@davidfestal
Apr 06 2016 10:10
don't know
but please open an issue about it
so that it can be discussed
I agree that when importing a Java archive we should provide a way to import it through import-package
but for pure-ceylon artifacts, I'm not sure import-package is the right thing to do
because then we should also generate uses directives, etc etc ...
with the risk of having incompatibilities
there should be a single source for a ceylon package IMO : the ceylon module as it is in Herd for example
but it's just a personal feeling
perhaps discussing it in the GitHub issue would show I'm wrong ;-)
Tom Bentley
@tombentley
Apr 06 2016 12:39

An internal error occurred during: "Initializing Java Tooling".
java.net.SocketTimeoutException: Timed out during connection to https://modules.ceylon-lang.org/repo/1/ceylon/language/1.2.2/ceylon.language-1.2.2.src

Er, why doesn't it use the local copy?

David Festal
@davidfestal
Apr 06 2016 12:40
don't know
open an issue ?
Bastien Jansen
@bjansen
Apr 06 2016 12:41
shouldn't the IDE use its own embedded repo?
David Festal
@davidfestal
Apr 06 2016 12:42
it does yes
but the embedded repo contains 1.2.3 if the IDE is built from
local projects
and here it(s searching for 1.2.2
Tom Bentley
@tombentley
Apr 06 2016 12:44
Does the embedded repo include the .src?
ceylon/ceylon-ide-eclipse#1757
David Festal
@davidfestal
Apr 06 2016 12:44
no not now
but it probably should
well wait a minute
Bastien Jansen
@bjansen
Apr 06 2016 12:45
oh I didn't see it was an older version
David Festal
@davidfestal
Apr 06 2016 12:45
let me check
Tom Bentley
@tombentley
Apr 06 2016 12:45
Well if it's going to have to fetch it, I have to ask why not?
Bastien Jansen
@bjansen
Apr 06 2016 12:45
is it Ceylon IDE 1.2.2 or master?
Tom Bentley
@tombentley
Apr 06 2016 12:45
I might not have updated my eclipse since before 1.2.3, so it might not be an old version from Eclipse's pov
David Festal
@davidfestal
Apr 06 2016 12:46
it has it yes
sorry
I assigned myself to it
David Festal
@davidfestal
Apr 06 2016 13:49
@FroMage
it might be possible
to use the first solution (correctly named and unchanged OSGI deps)
but first I have to fix the ceylon-p2 task to support version ranges in import-package
That should be quite quick
David Festal
@davidfestal
Apr 06 2016 15:53
haha, done but now I have to add the support for optional import-package
This has been done according to the p2 features that were used at this time
also the version of exported packages is not supported
David Festal
@davidfestal
Apr 06 2016 20:31
@FroMage : I've finally been able to build through maven with unchanged versions of the external version dependencies that are already OSGI bundles
(apart from slf4j and logmanager that are renamed and modified with require-bundle directives)
David Festal
@davidfestal
Apr 06 2016 23:10
However I still to debug problems during the eclipse start now