Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [technology-pmc] Workswith dependency for Kura

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:

Am 26.02.2014 um 22:25 schrieb Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx>:

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

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx







_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc



Back to the top