AdoptOpenJDK / IcedTea-Web

The new home for IcedTea-Web
Other
225 stars 87 forks source link

split project to logical parts #21

Closed hendrikebbers closed 5 years ago

hendrikebbers commented 5 years ago

In future this project should contain only the Java based core of IcedTeaWeb (as a Maven project - see #20 ). Therefore we will remove all native parts in a first step.

judovana commented 5 years ago

I would still vote for singlerepo-multiproject structure over multirepo-singleproject. I think it is much better for guidance. The glueing of all it together is not simple. Currently the launchers are inseparable part of ITW. Different wording, TIW is useless without launchers.

Under remove Dobry den! Dve dulezite poznamky. Nedorucit PRED 15:30 kdykoliv po .... Idealne 15:45 :)) Ale vim ze si vymyslim... Prosim vas, duelzita vec - vy jste mivaly takovy uzasny salat s krevetkama a prosutem. V nabidce jiz neni :((( Ale 14 dni zpet se mi jej z vas podarilo vymamit. Nemohl by se zase vratit do nabidky? Idealne ve trech variantach - salat s prosutem, salat s krvetkami, a kralovsky nejdrazsi, s krevetkami a prosutem ... zase si vymyslim. Pokud by tedy nesel ten 2x krevety a prosuto, tak zustaneme u toho naklikaneho lososa s mozzarellou. Nevahejte kdyztak volat! 775 39 01 09 Zdravie a moc dekujeme za nejlpesi pizzu a salt ve

hendrikebbers commented 5 years ago

@judovana I have no idea, you are the only expert ;) Let's start with a clean maven based project and than see how we can put its together

judovana commented 5 years ago

So from that view, it seems like creating directory.... javaws (or java or whatever) and put all desired java sources (former netx, likely without plugin already, and unittests, in maven like structure) in , and include pom. Imho extraction from makefile is not necessary, that will burn anyway. Does it sounds correct?

hendrikebbers commented 5 years ago

more or less. I think the PR will be ready in 30 min :)

hendrikebbers commented 5 years ago

@judovana see #23

hendrikebbers commented 5 years ago

In #23 this topic was already discussed. Since the PR will be merged / closed the next days I love to continue the discussion in this issue :) //cc @judovana

From my point of view there are benefits when doping the split but on the other side some benefits will get lost when splitting Java (core) and native part.

@judovana described a split in the repository that might look like this:

java (top module for all shared java classes)

launchers (top module for launchers)

In such case the repo would have 2 main folders (java & launchers) and some subfolders (modules). I will try to list the pros and cons (from my point of view) for such a structure to have a better discussion base:

PRO

CONS

judovana commented 5 years ago
* Everything is hosted at one place and easy to find.

This is very important pros. The community patches ar 50/50 between java and launchers. The final jar is useless without launchers. I'm still unable to think about ITW as java-only. If the launchers gone to separate repo, you need to tell erybody where to search for them and how to integrate them. Move to github was already gigantic leap. Maybe with itw 1.10 the launchers will really move to separate repo. But community needs some time to soak in.

* Release can be made quite easy since only one repo needs to be released

Many people are doing theirs custom builds. ITW should be as friendly as possible to all of them.

CONS

* While Maven is used in the java folder the launchers folder needs a complete different build & project management. Based on this it will not make sense to have a pom.xml in the root folder of the repo. Therefore users do not see directly that this is a maven based project

You can still have top level pom. In additional, there can be magical target, which will do a build together with non-java parts. Actually this was one of mine most hart-joying moments when you mentioned mavenization. It would be sad to not have it.

* When using a repo you normally try to understand it in total. For a new developer that is not possible in a short period of time for the old IcedTeaWeb setup. The suggested structure is better but still not perfect.

As I keep repeating, the launchers and javaws.jar are useles (for distribution) without each other. Also integration tests can be dropped (or follow launchers to new home) if you remove it. So when hacking the javaws.jar, it is good to know that there are some other parts. And as java developer, already fter launching mvn clean install, you will discover that you do not need to mingle with them (at least for now)

* Everyone that will use IcedTeaWeb will use the Java Core but I can assume that companies / group won't use the launchers and provide custom launchers on their own. We at Karakun will go that way for example. There you do not need all the content of the project (To be true I would even move FX based control panel to an additional repo)

icedtea-web should be able to be standalone and usefull project, with dirct simple build. Otherwise will be mocking to keep it opensourced. Anybody can of course create new launcher. I personally would be mor happy if more people would do one launchers better, then to have several separate launchers, each with different powers. Eg to make itw properly integrateable into JRE, is oneliner hack, or three linner proepr fix. Not sure what can motivate anybody to write his own launcher, Similarly the fx - you are going to create something amazing. I would be sad to not be abe to observe it.

* The build of the project will get complicated (instead of a simple Maven build). A lot of developers will only take care of the Java based core Burt need to understand native builds to work with the repo

Nope. top level pom and mvn clean install will do its simple job (as you, we all, wish) . mvn native:terror will eg create javaws.jar and rust laucnhers, mvn shell_terror wil sed the bats and shs.

Thanx for this brainstroming.

hendrikebbers commented 5 years ago

ok, can understand your points. I will try to work on the given PR and reintroduce the launchers

ebourg commented 5 years ago

+1 for keeping everything in the same repository

sclassen commented 5 years ago

Native code will stay in this repo. Closing the issue