search

eclipse-kura / kura

Eclipse Kura™ is a versatile framework to supercharge your edge devices, streamlining the process of configuring your gateway, connecting sensors, and IoT devices to seamlessly collect, process, and send data to the cloud.
https://eclipse.dev/kura/
Eclipse Public License 2.0
499 stars 306 forks source link

Camel Examples: review #265

Closed cdealti closed 7 years ago

cdealti commented 8 years ago

@hekonsek A few notes:

ctron commented 8 years ago

I just thought about the last bullet point ... I don't think we can add the Camel logo since this belongs to Apache.

ctron commented 8 years ago

@cdealti In order to provide a proper, self contained, quickstart with a manifest first approach it would be necessary to point to a publicly available P2 repository. Is there already one on the Eclipse download servers?

If not should we enhance to build in order to provide one? Or should we simply us the Package Drone instance at Eclipse [1]?

[1] https://packagedrone.eclipse.org/

dwoodard1 commented 8 years ago

@cdealti @ctron Are we good to close this now?

cdealti commented 8 years ago

@ctron the kura-release Hudson build of Kura 2.0.1 release failed yesterday on the Camel quickstart:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project org.eclipse.kura.example.camel.quickstart: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project org.eclipse.kura.example.camel.quickstart: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter
    at org.apache.maven.plugin.deploy.DeployMojo.getDeploymentRepository(DeployMojo.java:343)
    at org.apache.maven.plugin.deploy.DeployMojo.deployProject(DeployMojo.java:206)
    at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:169)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    ... 19 more
[ERROR]

Can you please take a look to the first build failed? Note that due to the failure we had to poke the release build configuration so it currently does not match the one of the above build anymore.

We will reenable the kura-develop build ASAP to recreate the issue

ctron commented 8 years ago

The cause for this was the fact that those quickstarts, since they are standalone now, don't inherit the distribution repositories from "manifest_pom.xml" anymore. Same as the Tycho version conflict.

Now I see a few options here:

1) We split off those quickstarts from the main build 2) We make them "less standalone" and again inherit "manifest_pom.xml"

There are pros and cons for both ways. Splitting them off from the main build will fix all of those issues, and provide a cleaner experience to the end user. The end user simply does not need to dive down the Kura build process, those bundles are standalone.

On the other hand this means adding an additional build step after the main build if you want to provide and host those quickstarts in the binary form.

cdealti commented 8 years ago

My preference goes to option 2) since the same argument applies to all the examples.

ctron commented 8 years ago

True. But applying all those special things from the Kura build to someone who is completely new and wants to learn how to get things done doesn't really help IMHO. But technically we can do it that way.

dwoodard1 commented 8 years ago

Not to muddy the water, but I think I would prefer option 1. We already created a separate repository for hosting examples and demos: https://github.com/eclipse/kura-apps. The idea was to move all the examples here and have a build that produced DPs for each. We could then add relevant examples and demos to the Eclipse Marketplace.

I also think this would be a good opportunity to try and tie the examples to a hosted P2 repository instead of having to include the target platform with example/demo code. I think this would be more aligned with how developers (who are not using Kura source code) would use the framework.

cdealti commented 8 years ago

I've realized I've been too conservative. I think I understand the intention now. I just want to make sure we have a consistent way of building things and the current kura build is already complex/messy. If there's an advantage let's extend the method to all the examples then

Da: dwoodard1 notifications@github.com Inviato: giovedì 1 settembre 2016 19.18.00 A: eclipse/kura Cc: De Alti, Cristiano; Mention Oggetto: Re: [eclipse/kura] Camel Examples: review (#265)

Not to muddy the water, but I think I would prefer option 1. We already created a separate repository for hosting examples and demos: https://github.com/eclipse/kura-apps. The idea was to move all the examples here and have a build that produced DPs for each. We could then add relevant examples and demos to the Eclipse Marketplace.

I also think this would be a good opportunity to try and tie the examples to a hosted P2 repository instead of having to include the target platform with example/demo code. I think this would be more aligned with how developers (who are not using Kura source code) would use the framework.

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/eclipse/kura/issues/265#issuecomment-244148494, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABK0axr23YhSa2XG6Nx2KlDYQbAJlyHmks5qlwjIgaJpZM4Iu1cF.

ctron commented 8 years ago

@dwoodard1 So that would mean I should migrate the examples over to that repository?!

dwoodard1 commented 8 years ago

That is what we discussed a few months back. Moving everything in kura/examples to the new repository. The top reasons were:

1.) Separate Kura "application" code from the framework source code, as this is likely how many users are interacting with Kura 2.) This may encourage the community to contribute interesting projects/bundles they have created

I guess the question is, is there a reason not to do this?

ctron commented 8 years ago

@mcarrer This would also include the Camel examples, so finding a solution for the emulator would be a good idea.