Gunnar,
Yes - this is correct as far as complexity of building this
piece would be. But, this goes back to my question about 'what can
be where' in terms of the build process. Please correct any
statements that may be wrong.
For background, we use maven to build. From a user perspective
if they wanted the optional web ui bundle, they would have to build
it themselves. This is because we can not distribute a binary Kura
web ui bundle that includes the GXT binary as well as code generated
by GXT. But, if we had the project source (written by Eclipse
commiters and code that will be under EPL) as well as the maven pom
file that referenced GXT as a dep (which would get pulled in from a
public - non Eclipse hosted - maven repo) this would allow the build
to be performed by a user. This would result in a bundle which the
user could install and use on a target platform.
The caveat would be that we could not build this component on
the build servers at Eclipse since GXT and resulting components
dependent on GXT could not be redistributed. So, in the source tree
of what is hosted at Eclipse, we would leave the building of the
Kura web ui component depending on GXT disabled. If a user wanted
it, they pull in the source, toggle the 'enable web ui flag' in the
maven config, build it - which pulls in GXT as a maven dep from a
maven repo that is not eclipse, and outputs a web ui bundle that
they can transfer to their system. Is this acceptable? From a user
perspective, they only have to toggle that flag and do a 'mvn clean
install'. So, the effort is not huge for those that want the
benefit. Since the flag is disabled by default, it would not be
part of the regular Kura builds at Eclipse - so binary builds to be
distributed at Eclipse would not include this piece. I should note
our tycho/maven based build is already this flexible and working
today.
On a final note, we understand this is not a viable long term
option. We are looking into others but as noted, it will take some
time. But, this is what we have today. Also, this will not gate
Kura from getting released. We have a few CQs to wrap up first but
this is truly optional and can be left out. But, it greatly
enhances the user experience so we'd like to keep it if at all
possible, even it it has be built by users.
Thanks,
Wes
On 2/26/14, 1:39 PM, Gunnar Wagenknecht
wrote:
On
26/02/2014 4:21 PM, Gunnar Wagenknecht wrote:
After
reading through the CQ I don’t see an easy possibility for
making this a works-with dependency.
Gunnar, can you explain that? Wes
started going down this path at my suggestion, and as it was
described it seems to fit the definition in the policy
http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
Well, it is possible but it’s just not easy. GXT works like
GWT. Thus, I think that it isn’t enough to just download GXT
separately and install/deploy it somewhere. The GXT jar files
need to be identified. They possibly need to be enhanced with
OSGi metadata (for proper loading in the framework). Then the
Kura Web UI source code needs to be cloned and compiled with
GXT into _javascript_/HTML. That must then also be deployed
somewhere. The generated _javascript_/HTML should contain code
from GXT libraries. Therefore it’s not possible to distribute
pre-compiled _javascript_ as part of the downloads.
Users/adopters would have to compile it themselves.
[..] But there is clearly a lot of work
that's gone into this UI, so switching will take some time.
Unfortunately, I haven’t seen a demo yet. Building web/admin
UIs myself, I certainly believe that and I’m not suggesting this
as an immediate option. But I think Kura should look at a more
license friendly technology in the future.
-Gunnar
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
