search

FlexoVM / flexovm

30 stars 4 forks source link

Current & Future State #4

Open Zubnix opened 8 years ago

Zubnix commented 8 years ago

RoboVM is dead, long live ...VM

If we want this robovm fork to move forward, we must know what we want and how we want it.

There are several issues that need fixing first (in order of priority):

thoughts?

Dexdev08 commented 8 years ago
Zubnix commented 8 years ago

@Dexdev08 Do you mean you are in favor of focusing effort on bugvm as a general purpose robovm fork? (which is ok for me, given that the bugvm author agrees).

Dexdev08 commented 8 years ago

I think we'll end up repeating all the work they did, instead of moving the whole robovm fork movement forward. Now there are reasons to keep flexovm -- but at this point, I am not clear.

Zubnix commented 8 years ago

I think bugvm is a good choice. It seems more popular and more active than flexo. I'm not sure what the owner(s) goals are for bugvm as it seems mostly geared towards iOS/mac. If they are ok with a general purpose bugvm fork (lin, win(?), mac, android & ios), then I think it's best to concentrate the effort there.

Dexdev08 commented 8 years ago

Yes. If they are ok with a general purpose bugvm fork then we'll ride on what was already built.

Zubnix commented 8 years ago

Ok, I'll open a ticket @bugvm in a couple of days to see if they're ok with it, this should give anyone @FlexoVM the time to speak up if they object.

priand commented 8 years ago

I agree that we should concentrate on a single project. I found this one: https://github.com/MobiDevelop/robovm, which seems to be promising and clean (one single project). It is not a fork, but a copy, with the content laid out differently.

Zubnix commented 8 years ago

@priand that looks like it's nice and clean. From a pure technical point of few it looks better/nicer to start working with than bugvm. However bugvm seems to have more visibility. I don't know how much work it is to make bugvm project look nice and structured.

priand commented 8 years ago

@Zubnix so far, none has real traction/followers. BugVM was basically the first fork, so people got curious. But now that RoboVM is gone, we need to run a real project. For that, we have to to pick-up one and bet on it. As of today, there are basically all at the same feature level, which is more or less the OSS version of RoboVM. So we should figure out which one is likely to get the most attention and contributions. As of today, MobiDevelop seems to be the best candidate to me.

Zubnix commented 8 years ago

@priand fair enough. How do you propose we continue?

Ideally we'd convince everybody with his/her own robovm fork to join the project, provide patches or at least be so kind to provide a link to the new project. We'd also need a new new name as mobidevelop's fork is still called robovm. We could delete all flexovm repo's & import mobidevelop's robovm repo under non-robovm (new or different than flexovm?) name.

priand commented 8 years ago

@Zubnix I first want to make sure that it works. We succeeded in compiling the whole project this morning. That was way easier than the original RoboVM project. We're now conducting some tests to make sure that our apps run with this new build. During this stage, we'll keep the robovm name to run our apps as is. We also need to contribute the maven plug-in back from the RoboVM source repo. For the final name, we should connect with the people who started this project, and see what they think.

Dexdev08 commented 8 years ago

@priand My only concern is that we should work on a fork and rename ... eventually there might be trademark issues when the project matures.

Zubnix commented 8 years ago

I will create a new repo starting from the https://github.com/MobiDevelop/robovm repo somewhere this week and try to formulate goals, a roadmap etc.

In the meanwhile I will be on irc on channel #flexovm on freenode should anyone want to give input/ask questions.

priand commented 8 years ago

One question though: why creating a new repo rather than working with the existing one, and submit ideas/suggestions/code to the original team?

Dexdev08 commented 8 years ago

We have to eventually rename the project I guess...

On Mon, 25 Apr 2016 at 20:12 Philippe Riand notifications@github.com wrote:

One question though: why creating a new repo rather than working with the existing one, and submit ideas/suggestions/code to the original team?

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/FlexoVM/flexovm/issues/4#issuecomment-214287855

Zubnix commented 8 years ago

@priand you are free to get them on board or invite them in the discussion here. The more people that cooperate on the effort, the better.

Zubnix commented 8 years ago

I will fork mobidevelop robovm repo in the fluxvm group & delete the other repos. We'll use that as a starting point if that is ok for everybody.

priand commented 8 years ago

This is ok with me.

Dexdev08 commented 8 years ago

No problem.

On Wed, 27 Apr 2016 at 20:34 Philippe Riand notifications@github.com wrote:

This is ok with me.

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/FlexoVM/flexovm/issues/4#issuecomment-215068173

rfcclub commented 8 years ago

We should have a backup plan. At first RoboVM includes:

Đã gửi từ iPhone của tôi

Ngày 27-04-2016, vào lúc 19:39, Dexdev08 notifications@github.com viết:

No problem.

On Wed, 27 Apr 2016 at 20:34 Philippe Riand notifications@github.com wrote:

This is ok with me.

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/FlexoVM/flexovm/issues/4#issuecomment-215068173

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

Zubnix commented 8 years ago

@rfcclub I will wait before deleting them until we're 100% sure we don't need them anymore.

I propose we make a list (like you did) with functionality we absolutely want to keep and try to link the repositories that are required in that list by building & verifying (through running & testing?). This (exploratory) effort can be combined with writing up to date build documentation.

Once these build instructions are in place, we can create build files for travis-ci to ensure we always have a successful build.

priand commented 8 years ago

Adding to this list: we also need the maven plugin that is not available there, but we'll be contributing it.

Zubnix commented 8 years ago

Fork created; https://github.com/FlexoVM/robovm-community

I have requested the owners of FlexoVM to allow: waffle.io - ticket management gitter - (web based) chat with history travis-ci - continuous integration @CaptainFuture could approve these requests?

@priand is that the maven plugin you were talking about in the mobidevelop ticket? I'll add it to the list and try to put it into tickets once I can get waffle.io integrated.

priand commented 8 years ago

Yes it is.

Zubnix commented 8 years ago

Is there anyone else that can approve the mentioned tools? I'm afraid @CaptainFuture is not very active..

CaptainFuture commented 8 years ago

Sorry for the delay. @Zubnix don't you have Admin rights on all repos of FlexoVM? What kind of access do you need in order to do what you want?

I have requested the owners of FlexoVM to allow: waffle.io - ticket management gitter - (web based) chat with history travis-ci - continuous integration

How do I approve those requests? I didn't get anything in the Github notifications.

Zubnix commented 8 years ago

@CaptainFuture I don't believe I have the rights to allow 3rd party tools to access repositories as it seems only owners can do this. Go to eg.: https://waffle.io/ -> click on 'get started now' -> public repos -> organization access (bottom).

Or (looking at my own udev.be organization) go to: profile settings (top right->settings) -> bottom left (organization settings) -> oauth applications (?) Does that give you anything?

CaptainFuture commented 8 years ago

Okay...I approved waffle and Gitter. All good now?

Zubnix commented 8 years ago

don't forget travis-ci!

CaptainFuture commented 8 years ago

It didn't show travis-ci. What can I do? Btw...do you want to develop the RoboVM clone under the FlexoVM organisation or what is your plan?

Zubnix commented 8 years ago

I've requested access for travis-ci.

yeah I would like to get a community effort going for robovm. FlexoVM organisation seems to be a good starting point as others are mostly one man efforts.

CaptainFuture commented 8 years ago

Okay...approved. Let me know if you need anything else. Maybe I will be able to join development in a while...due to some unexpected workload in the past month I was completely off the radar.

rfcclub commented 8 years ago

Btw I saw it in mobidevelop/:This fork is meant to be used with libGDX. Normal iOS apps have not been tested against it. Use at your own risk. Furthermore, artifact id is changed to com.mobidevelop.robovm instead of org.robovm. If we want to use it to learn I think it's OK. For work I think we need some more investigation about what changes in that fork and whether it's compatible and worth to use it as a stable starting point or not.As a result I recommend keep old flexovm repository for a while.Change logs for initial works from MobiDevelop:https://github.com/MobiDevelop/robovm/commit/3d1e6eccf9edf5e4c05727882f587af2e2368785

Basically I feel OK for first step but some changes in compiling native part makes me worry. But it needs more ideas.  Tu Nguyen Nam Cell   : 0988530945 Email : rfc_club@yahoo.com

Vào ngày 2:38 Thứ Sáu, 29 tháng 4 2016, CaptainFuture <notifications@github.com> đã viết:

Okay...approved. Let me know if you need anything else. Maybe I will be able to join development in a while...due to some unexpected workload in the past month I was completely off the radar.— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

Zubnix commented 8 years ago

We should make integration tests (as for as possible) for all the functionality we want to keep. (a script would be ok for all I care)

We should also not focus too much on a single use case (iOS or gdx for example) but instead focus effort an solutions that work across all platforms we want to support. Another widely overlooked selling point for robovm is that you can have near native/jit like performance on linux arm (any llvm supported architecture I imagine). This is something not availabe for openjdk.

proposal: we define the functionality and platforms we want to support (and make sure we do actually support them through some simple integration tests). Ideally this begins with basic common functionality. Per supported platform we can then define more specific functionality (eg Bro & ObjC bindings).

Based on this we can gain some insight & experience in the state of other forks & the vanilla fork of robovm.

rfcclub commented 8 years ago

The key thing is still keep what RoboVM supports: Build iOS and MacOS apps & games using Java. Linux and Android already support Java so it is useless to make Java run on them, unless you want to make Java run on IoT linux OS or build an AOT compiler for Java itself. My proposal is simple: -Make RoboVM works with latest iOS and MacOS -Fully support Java 8 Next step can be:

rfcclub commented 8 years ago

Another main point: Comprehensive documents and good tools to make woek with RoboVM is easy like eat a cake.

Zubnix commented 8 years ago

I agree we should not focus on android (at all) as it basically already has it's own aot java rt. I do believe there is a strong use case for embedded linux (arm), as the current oracle solution costs you an arm and a leg or you're stuck with pure very slow interpreted mode.

If we want to fully support Java 8, it would be wise to use openjdk as the runtime instead of the (old) android runtime classes. Even Google itself switched Android to use openjdk as a base and it was originally also the goal of the RoboVM team (but I assume lack of funding made them focus their efforts on android rt).

A prerequisite to this, however, is that we don't compile to statically linked one file binaries. As the openjdk license requires that anyone that statically links to it, must provide source code. A fix would be to compile to a a dynamically linked binary with a shared library for the VM runtime & OpenJDK. I already did an initial investigation for this and it doesn't look that hard. However the devil is in details, so I assume it to be not that easy.

To start with jdk8 support, I propose we first try to get the compact profile 1 to work. See http://www.oracle.com/technetwork/java/embedded/resources/tech/compact-profiles-overview-2157132.html Another thing is that having jdk8 support would also set us apart from any other robovm fork, and would give as probably also a lot more attention.

Dexdev08 commented 8 years ago

Do i remember there are apple store restrictions with the vm thats why everything was statically linked?

On Thu, 5 May 2016 at 02:30 Erik De Rijcke notifications@github.com wrote:

If we want to fully support Java 8, it would be wise to use openjdk as the runtime instead of the (old) android runtime classes. Even Google itself switched Android to use openjdk as a base and it was originally also the goal of the RoboVM team (but I assume lack of funding made them focus their efforts on android rt).

A prerequisite to this, however, is that we don't compile to statically linked one file binaries. As the openjdk license requires that anyone that statically links to it, must provide source code. A fix would be to compile to a a dynamically linked binary with a shared library for the VM runtime & OpenJDK.

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/FlexoVM/flexovm/issues/4#issuecomment-216958181

Dexdev08 commented 8 years ago

Ive googled a bit. You can refer to below.

http://ddeville.me/2014/04/dynamic-linking/ On Thu, 5 May 2016 at 17:08 Dexter Ang javadex@gmail.com wrote:

Do i remember there are apple store restrictions with the vm thats why everything was statically linked?

On Thu, 5 May 2016 at 02:30 Erik De Rijcke notifications@github.com wrote:

If we want to fully support Java 8, it would be wise to use openjdk as the runtime instead of the (old) android runtime classes. Even Google itself switched Android to use openjdk as a base and it was originally also the goal of the RoboVM team (but I assume lack of funding made them focus their efforts on android rt).

A prerequisite to this, however, is that we don't compile to statically linked one file binaries. As the openjdk license requires that anyone that statically links to it, must provide source code. A fix would be to compile to a a dynamically linked binary with a shared library for the VM runtime & OpenJDK.

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/FlexoVM/flexovm/issues/4#issuecomment-216958181