Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [smarthome-dev] Requirements

Note that I had an Equinox distro in the repo at the start.
But maintaining it simply meant too much effort - I had to do everything twice; the IDE support, the packaging, build, downloads, demo files, etc.
It is much easier to have people using ESH either directly from the Eclipse IDE or to have them using openHAB 2.

So unless there is any additional benefit by having a showcase for Concierge, Kura or any other project, having to maintain yet another ESH distro simply does not make much sense.


Am 01.04.2016 um 13:36 schrieb Benjamin Cabé <benjamin@xxxxxxxxxxx>:

Alright, so I have quickly tried to put together a ESH standalone distro (it's basically as easy as creating a product from the "SmartHome Runtime" launch configuration, and exporting it ;-) And then of course no native launcher on ARM means having to launch the Equinox launcher jar by hand). I got bitten by Quartz, which is depending on java.beans, therefore a full SE runtime. The plan with https://github.com/eclipse/smarthome/pull/869 is however to move away from Quartz, correct? Is there any code available in a branch that does just that?

Thanks,
Benjamin – 



Benjamin Cabé – IoT Evangelist

Eclipse Foundation
+33 (0) 619196101
@kartben

De : <smarthome-dev-bounces@xxxxxxxxxxx> on behalf of Kai Kreuzer <kai@xxxxxxxxxxx>
Répondre à : Eclipse SmartHome development mailing list <smarthome-dev@xxxxxxxxxxx>
Date : jeudi 31 mars 2016 18:34
À : Eclipse SmartHome development mailing list <smarthome-dev@xxxxxxxxxxx>
Objet : Re: [smarthome-dev] Requirements

Hi Benjamin,

Yes, such a lightweight demo distro would definitely be desirable and we have already an issue for it since a while: https://github.com/eclipse/smarthome/issues/602 (Concierge would arguably be a nicer OSGi fw than Equinox as it would be a showcase for Concierge at the same time).

Another nice combination for a demo packaging would be with Kura, see here https://www.eclipse.org/forums/index.php?t=msg&th=1075704&goto=1727102&#msg_1727102.

I would love to see both to happen, but personally do not have the resources to work on it - so we are dependent on contributions from the community on this (unless you might consider to help on it as well :-)).

Best regards,
Kai

Am 31.03.2016 um 17:45 schrieb Benjamin Cabé <benjamin@xxxxxxxxxxx>:

Hi,

+1 for Compact 2 profile. This actually brings me to a question: OpenHAB, which I see (rightly or no, you tell me), as sort of a reference integration of SmartHome, uses Apache Karaf, which requires compact3, AFAICT. Would it make sense to maintain a lightweight, Eclipse Equinox-based, minimal SmartHome “distro” as part of ESH repo, that would be very similar to the openHAB demo setup, only it would be meant to show “pure” Eclipse SmartHome stuff?
Unless I’m mistaken, although ESH "is not a product itself, but a framework to build solutions on top”, it still has all the bits one needs to run a fully functional (yet limited) smarthome box, right?

Benjamin –


Hi Markus,

The PMC, the "big playersâ / users of the framework?

Neither the PMC nor the users. It is clearly the committers of the project who decide on such things.

I think it has to be discussed on a case by case basis.
R4.2 and Java 7 were the requirements of the initial contribution. Any change to this will need a discussion, where every committer has veto rights.

In general, we should strive to make ESH as easily usable as possible on different platforms, but not having to do too big compromises on the code.

So when looking into Java 8, we clearly should go for a compact profile to keep the âembedded useâ in focus, see e.g. discussions like https://www.eclipse.org/forums/index.php?t=msg&th=1065860&goto=1692889&#msg_1692889. Compact profile 2 seems to be a good choice.

Regards,
Kai


On 22 Mar 2016, at 10:45, Markus Rathgeb <maggu2810@xxxxxxxxx> wrote:

Hello dear SmartHome developers,

the question has been triggered by the latest PRs and the comments of that PRs:
* https://github.com/eclipse/smarthome/issues/1191
* https://github.com/eclipse/smarthome/pull/1201

Currently the requirements of the ESH software is (IIRC):
* OSGI R4
* Java 7
* Java 5 for org.eclipse.smarthome.protocols.enocean.*
* Java 5 for org.eclipse.smarthome.automation.*

It seems by #1201 at all and the comment
https://github.com/eclipse/smarthome/pull/1201#issuecomment-199696040
that there is some motiviation to move forward to use Java 8 CP2
compliant code (some time).

So my questions:
* Who defines the minimum requirements? The PMC, the "big players" /
users of the framework?
* How do we handle a requirement change in this project? Votes?
Internal discussions between the "big players"?
* What are the blockers for a requirement change (related to the
question above).

I myself have no needs to support an "old" platform so I am fine with
Java 8 and R6 ;)
It is clear to me that this bump will not happen the next time, but I
am interested about the procedure (the answered questions) in general.

Best regards,
Markus
_______________________________________________
smarthome-dev mailing list
smarthome-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/smarthome-dev

_______________________________________________
smarthome-dev mailing list
smarthome-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/smarthome-dev

_______________________________________________ smarthome-dev mailing list smarthome-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/smarthome-dev
_______________________________________________
smarthome-dev mailing list
smarthome-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/smarthome-dev


Back to the top