Hello Maxim,
Thank you for your answer. I haven't expected such quick feedback. I am
here to help you with OSGi, I believe that together we will be able to
get Ignite free of troubles it gives.
I abstained from creating new issues as there are two which already
outline end user problem: IGNITE-17216, IGNITE-17216.
I do not see a problem with moving ignite-osgi module to other
repository as long as we avoid dependency cycles.
Since igite-osgi functionality seem to be limited to bootstrapping
ignite and its classloading it does not depend per say on where code
itself is located. I suppose that osgi-karaf and osgi-paxlogging should
follow that move to keep all osgi related things in one place.
Major concern I can raise is how to keep it up so it does not sink over
time. Integration tests I mentioned will form a safety net, but they
need to be part of build pipeline to follow changes in main repository.
Some of recent changes I found about cleaning out some inner-dependency
paths (ie. indexing-h2 relation: IGNITE-17046), are very helpful to
solidify OSGi metadata.
One of major problems which are hard to solve without cooperation is
mentioned "split package" which is currently found in the sources. This
happens when same package is defined (and exported) from two places.
Currently both ignite-core and indexing bring contents of
org.apache.ignite.internal and spi packages:
- org.apache.ignite.internal.managers.systemview.walker
- org.apache.ignite.internal.mxbean
- org.apache.ignite.internal.processors.cache.query
- org.apache.ignite.internal.processors.query.stat
- org.apache.ignite.internal.visor.cache.index
- org.apache.ignite.internal.visor.verify
- org.apache.ignite.spi.systemview.view
To be fair, I don't know yet what is scope of these and that's where I
need most of your guidance. I don't think we will be able to stabilize
osgi integration to guarantee it will work reliably if these stay.
Kind regards,
Łukasz
On 4.07.2022 19:43, Maxim Muzafarov wrote:
Hello Łukasz,
Nice to meet you!
Currently there are some known issues with the Apache Ignite OSGi
integration. We have a lack of time and knowledg to support it, so any
help are very appreciated. I also have a a plan to move this
integration to the Apache Ignite Extensions project [1] and release it
when all the issues are resolved. Here is an umbrella ticket for it
[2].
What do you think if I move the OSGi to the Apache Ignite Extensions
first and after it we will resolve the issue you mentioned above? I
can help with a review and try to do the best I can here.
Anyway if this plan wouldn't work for you, please, feel free to create
an issue here [3] with your PR.
[1] https://github.com/apache/ignite-extensions
[2] https://issues.apache.org/jira/browse/IGNITE-17019
[3] https://issues.apache.org/jira/projects/IGNITE/
On Mon, 4 Jul 2022 at 20:26, Łukasz Dywicki <l...@code-house.org> wrote:
Hello everyone,
First of all thank you for awesome project and its maintenance. My name
is Łukasz and I am committer of Apache Karaf and Apache PLC4X projects
hence you most likely don't know me as I am coming from other part of
ASF ecosystem.
I was asked about looking at Apache Ignite OSGi metadata as project we
are trying to use Ignite with is bound to the OSGi runtime. After a bit
of look I found that metadata generation is partial and overall
infrastructure in this area haven't received any polishing since a while.
Since there are "split packages" and few additional troubles I wanted to
check with you if there is a will to move that part ahead. Is there a
will or plan to retain the metadata or rather throw it away?
Last week I made a draft PR with changes which allowed me to run ignite
inside Apache Karaf (4.3.x): https://github.com/apache/ignite/pull/10133
There are several maven pom updates and, so far, one code relocation in
kubernetes module. I based all changes on exiting properties:
osgi.import.package, osgi.export.package, osgi.private.package
I think there are few more places where "split package" is found,
however I did not look very carefully at these yet.
Looking forward to hear out your guidance in how you would like to get
these changes, if at all. If you would be up to move that part forward I
can sacrifice more time in making metadata generation and validation
more rebust through ie. basic OSGi integration tests. PR I linked above
automatically validates import and export constraints for Karaf feautes.
Kind regards,
Łukasz
