That's a very important issue for contribution. Up to now, I used Maven
for setup IntelliJ (and it works just fine). If we remove the pom.xml,
we have to support Eclipse and IntelliJ "smoothly".
Let me try in IntelliJ.
Regards
JB
On 10/04/2018 15:21, Romain Manni-Bucau wrote:
You dont have issue due to the build setup with that option. I get:
avr. 10, 2018 3:20:10 PM
org.apache.beam.runners.direct.DirectTransformExecutor run
GRAVE: Error occurred within
org.apache.beam.runners.direct.DirectTransformExecutor@66761b7a
com.google.common.util.concurrent.ExecutionError:
java.lang.NoClassDefFoundError: net/bytebuddy/NamingStrategy
?
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
2018-04-10 15:13 GMT+02:00 Lukasz Cwik <[email protected]>:
I have found that the simplest setup is to delegate the build/test actions
to Gradle. This allows you to run unit tests very easily and since its in
the same manner that Gradle would have, you know that if its passing it will
pass on the command line and on Jenkins. Here is one site that discusses how
to set this up:
http://mrhaki.blogspot.com/2016/11/gradle-goodness-delegate-build-and-run.html
On Tue, Apr 10, 2018 at 8:45 AM Romain Manni-Bucau <[email protected]>
wrote:
What's the plan to make idea supporting gradle on beam project? Do we
import the workaround mentionned in
https://youtrack.jetbrains.com/issue/IDEA-175172?
For the ones who didn't see this issue in action: idea will compile in
out/ instead of build/ and you will just miss all the resources you
need like some SPI registration which are used by all our registrar =>
no way to run tests in idea without hacking the configuration quite
deeply :(
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
2018-04-10 10:08 GMT+02:00 Etienne Chauchot <[email protected]>:
As a gradle beginner, I could not agree more !
+1
Etienne
Le lundi 09 avril 2018 à 18:47 +0200, Jean-Baptiste Onofré a écrit :
Hi all,
I did multiple gradle build since last week and I would like to share
one of my concern: it's about the communities.
If I think our users won't see any change for them due to Gradle build
(I think that most of our users will still use Maven with artifacts
provided by Gradle), I'm more concerned by the dev community and the
contribution.
Maven is well known and straight forward for a large part of potential
contributors. I think we have to keep in mind that we still have to grow
up our contributors community.
Today, maybe I'm wrong, but I have the feeling that gradle build is not
straight forward (build.gradle includes build_rules.gradle, gathering
all taks all together).
I would like to add a task in the gradle "migration" process: simplify
the gradle structure and files, and document this.
I know we already have a Jira about the documentation part, but I would
like to "polish" and use a clean structure for the Gradle resources. As
already quickly discussed, I think that having one gradle file per tasks
in the .gradle directory would be helpful.
The goal is really to simplify the contribution.
Do you agree if I add a Jira about "Gradle polish" ?
Thoughts ?
Regards
JB
On 07/04/2018 04:52, Scott Wegner wrote:
Here's an end-of-day update on migration work:
* Snapshot unsigned dailies and signed release builds are working (!!).
PR/5048 [1] merges changes from Luke's branch
* python precommit failing... will investigate python precommit
Monday
* All Precommits are gradle only
* All Postcommits except performance tests and Java_JDK_Versions_Test
use gradle (after PR/5047 [2] merged)
* Nightly snapshot release using gradle is ready; needs PR/5048 to be
merged before switching
* ValidatesRunner_Spark failing consistently; investigating
Thanks for another productive day of hacking. I'll pick up again on
Monday.
[1] https://github.com/apache/beam/pull/5048
[2] https://github.com/apache/beam/pull/5047
On Fri, Apr 6, 2018 at 11:24 AM Romain Manni-Bucau
<[email protected] <mailto:[email protected]>> wrote:
Why building a zip per runner which its stack and just pointing out
on that zip and let beam lazy load the runner:
--runner=LazyRunner --lazyRunnerDir=... --lazyRunnerOptions=... (or
the fromSystemProperties() if it gets merged a day ;))
Le 6 avr. 2018 20:21, "Kenneth Knowles" <[email protected]
<mailto:[email protected]>> a écrit :
I'm working on finding a solution for launching the Nexmark
suite with each runner. This doesn't have to be done via Gradle,
but we anyhow need built artifacts that don't require user
classpath intervention.
It looks to me like the examples are also missing this - they
have separate configuration e.g. sparkRunnerPreCommit but that
is overspecified compared to a free-form launching of a main()
program with a runner profile.
On Fri, Apr 6, 2018 at 11:09 AM Lukasz Cwik <[email protected]
<mailto:[email protected]>> wrote:
Romain, are you talking about the profiles that exist as
part of the archetype examples?
If so, then those still exist and haven't been changed. If
not, can you provide a link to the profile in a pom file to
be clearer?
On Fri, Apr 6, 2018 at 12:40 PM Romain Manni-Bucau
<[email protected] <mailto:[email protected]>>
wrote:
Hi Scott,
is it right that 2 doesn't handle the hierachy anymore
and that it doesn't handle profiles for runners as it is
currently with maven?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
2018-04-06 18:32 GMT+02:00 Scott Wegner
<[email protected] <mailto:[email protected]>>:
I wanted to start a thread to summarize the current
state of Gradle migration. We've made lots of good
progress so far this week. Here's the status from
what I can tell-- please add or correct anything I
missed:
* Release artifacts can be built and published for
Snapshot and officlal releases [1]
* Gradle-generated releases have been validated with
the the Apache Beam archetype generation quickstart;
still needs additional validation.
* Generated release pom files have correct project
metadata [2]
* The python pre-commits are now working in Gradle
[3]
* Ismaël has started a collaborative doc of Gradle
tips [4] as we all learn the new system-- please add
your own. This will eventually feed into official
documentation on the website.
* Łukasz Gajowy is working on migrating performance
testing framework [5]
* Daniel is working on updating documentation to
refer to Gradle instead of maven
If I missed anything, please add it to this thread.
The general roadmap we're working towards is:
(a) Publish release artifacts with Gradle (SNAPSHOT
and signed releases)
(b) Postcommits migrated to Gradle
(c) Migrate documentation from maven to Gradle
(d) Migrate perfkit suites to use Gradle
For those of you that are hacking: thanks for your
help so far! Progress is being roughly tracked on
the Kanban [6]; please make sure the issues assigned
to you are up-to-date. Many of the changes are
staged on lukecwik's local branch [7]; we'll work on
merging them back soon.
[1]
https://github.com/lukecwik/incubator-beam/pull/7
[2]
https://github.com/lukecwik/incubator-beam/pull/3
[3] https://github.com/apache/beam/pull/5032
[4]
https://docs.google.com/document/d/1wR56Jef3XIPwj4DFzQKznuGPM3JDfRDVkxzeDlbdVSQ/edit
[5] https://github.com/apache/beam/pull/5003
[6]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=242
[7]
https://github.com/lukecwik/incubator-beam/tree/gradle
--
Got feedback? http://go/swegner-feedback
