[infrastructure] Mavenized openHAB and integrated mavenized ESH repository #467
Conversation
|
I had to amend an additional change, so we can use the openHAB Oomph setup file after the merge has been done immediately (I hope I did not miss a change of it -- otherwise we can create additional PRs to fix it). |
|
For the naming fixes (I assume we will find a lot others) can (one of the alternatives)
otherwise it depends when I will find time to do it myself |
|
Sure, I'd suggest we do it as with any other PRs - comment on the PR and creating PRs against your branch with suggested changes until it is ready to be merged. |
|
Which one resolves a conversation in that project, the one that starts it or the one that "thinks" it has been fixed or one of the reviewer / committer? |
|
Anyone who "thinks" it is solved :-) |
|
Thanks for your huge efforts @maggu2810! 👍 I had a bit of trouble to build your branch but after wiping my local Maven repository the build succeeded. It kept throwing the following compilation error: Any reasons for downgrading Karaf to 4.2.1 (instead of 4.2.2)? We just upgraded to Karaf 4.2.2 with #458. Because there are so many changes, the normal GitHub review UI seems unusable for adding comments. |
Hi @wborn, openHAB Core has been moved to a framework and I don't see any reason why org.openhab.core.karaf shouldn't compile against Karaf 4.2.1. Or do you use any feature that has not been present before? You should differ between version that we compile against and the version that will be used in the product. I don't think that any usage of Karaf 4.2.1 for the framework will break your Karaf 4.2.2 usage in the product. But to answer your question: No, there has not been any reason. I assume it has been set by me on the migration path and I don't bumped it because I have not identified a problem. |
|
@maggu2810 Two quick questions:
|
|
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/the-road-ahead-reintegrating-esh/64670/15 |
|
|
|
|
After that we also need to merge the Karaf feature repositories. After the work has been done there will be two feature repos:
|
It's OK to have the framework on another version as long as there is another way (like Kai already suggested) to manage the Karaf/Jetty versions that are used in the distro. Without the proper Karaf/Jetty ending up in the distro we'll have regressions like the Karaf SSH Console new line bug and Jetty ThreadPoolBudget warnings. |
|
That's a very important point, the framework must not dictate the exact version of Karaf and Jetty that needs to be used by a product. |
I am wondering whether we should maybe even use
Sounds right. |
I already think about it, but I did not yet know which is the best approach. If you have a look at the whole Karaf features, you don't care which one provides it. The name should state what will be provided by the feature. I start thinking about the whole thing as it has been about the group ID. So, I am not against the suggested feature prefix, but if we agree, we have to change the group ID, too. Otherwise our argumentation is not really consistent. |
|
The current openHAB Core bundles depend on the models, too. |
It imho makes sense to be able to differentiate between framework and add-on through the group ids. In ESH we had "esh.extension.*" for the addons, but I think using "org.openhab.core" for all framework parts is the better choice.
You mean the Xtext bundles? Yes, they are an integral part of the framework, just like the config/io/automation bundles as well. |
|
Another try... It seems my question has been not clear enough, so let me add more details: There is a bundle with the name "openHAB Core" that uses the group ID There is a bundle with the name "Eclipse SmartHome Core" that uses the group ID If we merge the core bundles of openHAB and Eclipse Smarthome and replace "Eclipse SmartHome" with "openHAB" and "org.openhab.core" with "org.eclipse.smarthome.core", the bundles collide. The esh.core bundle contains the real core and is referenced (transitive) by the most of the other bundles. The oh.core bundle (correct me if I am wrong) is not really a core part of the whole smarthome framework. A product works perfect without it. But okay, we change a lot of things now so perhaps both bundles should be merged into one. If all can coexist why should we care about. The oh.core bundle imports model stuff (see ` ) I don't think this will result in a cycle or don't esh.model depend on esh.core itself.
Sure, like config, IO and automation, it is part of the core but we can also create a product without the automation stuff. I would veto if the most core bundle (what should be named "openHAB Core" similar to "Eclipse SmartHome Core" before) adds a hard dependency to the Xtext bundles. |
|
About the group and artifact IDs to use, can you please give me a example? The current approach has been to replace |
Ok, sorry, I didn't see you were talking about those - yes, indeed, they are a collision (hopefully the only one).
That's clearly not wanted by anybody. The Xtext functionality is kept separate and must be kept this way.
... while it would be the most logical name. It is the core part of the core framework. I wouldn't mind that group id. |
Sleeping over it and noticing that this will mean on the long run that those are also the package names, I question this statement myself. |
|
So you suggest to use the group ID Should we place all bundles directly in the directory without any further subdirectory between? Do we really need a directory Please could you provide the group and artifact ID + directory layout for some bundles, so we could not misunderstand each other? |
No, I thought we will have group ids
I quite like the hierarchy instead of a very long flat list as it makes browsing a bit easier. So I wouldn't mind keeping it exactly as it is in your repo right now. If you think things get easier by having just the "bundles" folder and all bundles in it, it would be fine for me as well. Just three examples, which should clarify be transferable to all the rest:
Does that make sense? |
It would be good to carve out stuff that is not version-specific. openhab/infrastructure is designed to be a component that really contains only version-unrelated infrastructure informations, because it is (on purpose!) not versioned and tagged together with openHAB. This could be the information e.g. where the base Git repository url is located or which Maven repositories openHAB is currently using. Use case: If openHAB decides one day to move to another SCM provider or to another artifact repository, this would affect all versions (also the older ones), so it's a not version-related change. In this case, of course it would be beneficial if the effort to make an older build work with the new environment is as low as possible. If we have the version-unrelated information at one place together, this effort would be minimal. But, what would be a very bad smell is to put version-specific information there (e.g. which versions of maven plugins are currently used). This would make it very hard to get older builds running on new environments, because the newer plugins would break the older builds. So, you'd have to manually go over everything and find yourself what's version-related and what isn't.
Sorry, I don't understand the whole point. Where the parent POM is located has IMO nothing to do with the question whether a developer has to inherit his addon from this parent POM or not.
I think it is intended to be used also by non-openHAB owned bundles. At least I'm not aware of compelling reasons why it shouldn't. And if other people don't want to use it, they can just do their own parent POM and inherit from there (or even don't use any parent POM at all). And yes, it would be easier for them if we carve out the pure version-unrelated infrastructure parts, as mentioned above 👍 |
I don't understand how this will affect "older builds".
So, I assume the openHAB release "m" depends on the released infra version "x". |
|
What about the still open points, like maven archetype and SAT? Or merge first and fix later? |
That would be my plan. |
I didn't test it yet because of the lack of time. But I don't think it is a blocker and can be integrated also later. |
|
@kaikreuzer As long as there is no solution for #467 (comment), should we remove the |
|
Can you do a PR? |
|
Yes, I will do. FYI: Without the index projects I still realized an interesting behavior of the IDE. I don't know if the specific Java distribution is really the root cause of it but we should remember, if someone complains. |
|
@maggu2810 I did 'complain' about this already twice, see pure maven thread. So finally I don't feel alone anymore 🙂 I run: It makes development completely impossible, and why I, kind of, postponed looking into maven-only-build until some time later in the hope it was just because something temporary due to the wip status and nobody else seem to have that problem. So it looks like specific Java distribution problem... |
Hm, isn't one of the pros of the maven only build that you don't rely on the Eclipse IDE (sure, for the formatter you still need to use the Eclipse IDE) but for "looking into" you could use every IDE that can handle Maven projects.
Please try again using the Oracle JDK 8 (202 should be the recent one). |
| <artifactId>org.openhab.core.bom.compile</artifactId> | ||
| <version>${project.version}</version> | ||
| <type>pom</type> | ||
| <scope>provided</scope> |
There was a problem hiding this comment.
I needed to change the scope to compile to be able to build it with maven on the command line. Same for provided below on compile-model
There was a problem hiding this comment.
Really?
I build the whole repository multiple times now and it works.
If the build does not work for you (using the current master), it would perhaps make sense to create an issue with the whole log.
provided should be present on compile time (similar to compile) but can be missing at runtime (different to compile).
| <url>http://eclipse.github.io/smarthome/third-party/m2-repo/</url> | ||
| </repository> | ||
| <repository> | ||
| <id>bintray-maggu2810-maven</id> |
There was a problem hiding this comment.
The url to the maggu2810 repository should be removed. Is something like that still needed?
There was a problem hiding this comment.
It can be removed if you know about a repository that provides the dbus and unix bundle of matthw.
See:
openhab-core/bundles/org.openhab.core.io.transport.dbus/pom.xml
Lines 16 to 27 in c0ef794
Related to: #467 (comment) Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
|
I manually installed openjdk 8 version 201 and that seem to solve the continuous build problem. |
cweitkamp
added
enhancement
cweitkamp
changed the title
* mavenize openHAB and integrate mavenized ESH repository Signed-off-by: Markus Rathgeb <maggu2810@gmail.com> GitOrigin-RevId: a37ccea
This commit integrates the whole mavenized ESH repository ATM.
I would prefer to drop the ESH extensions later, because IIRC there are some openHAB bundles that depends on an extrension.
Perhaps we could drop the ESH extensions as soon as we moved some openHAB non framework bundles to the addons repository.