[GitHub] incubator-edgent pull request #308: [Edgent-417] cleanup old ant-build cruft

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/308


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Understanding the snapshot and release process

[Dale LaBossiere]

Awaiting others to chime in on this “switch to mvn” subject.
A “don’t care” (+/- 0) response is preferred over silence.

In the mean time...

> On May 24, 2017, at 11:41 AM, Christofer Dutz  
> wrote:
> ...
> I just checked out everything and managed to get things imported in IntelliJ 
> after a little struggle … this is a good job you did :-)
Can’t take all the credit (or blame :-)
> 
> Right now, it seems as if there were Ant+Gradle+Eclipse build files in there. 
> While it might seem ... 
gradle is the only CLI way to build edgent.  Any ant build.xml files are either 
(a) residual cruft that should be removed (my bad) or (b) needed to leverage 
the ant machinery for invoking retrolambda in building java7/android compatible 
versions of the jars (machinery that wasn’t converted to pure gradle due to 
time/effort/value at the time).  Attempting to use ant at the top level tells 
you it doesn’t work :-)  As for Eclipse .project/.classpath, yup those are live 
and haven’t been a maintenance issue.

fwiw, I just removed all build.xml except the top level one and those under 
platform and “gradle release” worked fine so I’ll create a PR to clean them up 
as a first step.

> ...JavaDoc is generated automatically when running a release build together 
> with the usual Maven project reports (is even configured in the apache parent 
> POM together with rat, deployment etc.)
Javadoc was complicated by creating groupings as well as excluding it for 
non-API classes.

> ...I didn’t quite understand the “Manifest” thing, but the jar plugin does 
> generate this with reasonable defaults, and can be extended to also export 
> the dependencies into that (even if I don’t recommend that). 
An edgent jar’s manifest class-path includes references to its immediate 
dependent edgent jars (not transitive) as well as references to its external 
jar dependencies (transitively).  I agree that "compiled in" references to 
specific versions of external dependencies may not be a great idea / is perhaps 
best eliminated.

My recollection is that by default gradle did not generate any manifest 
class-path.

e.g., just to make this a bit more concrete, this is from 
edgent.connectors.kafka.jar/MANIFEST.MF (see connectors/kafka/build.gradle for 
more info)

Class-Path: ../../../lib/edgent.api.topology.jar ../../../ext/gson-2.2
 .4.jar ../../../ext/slf4j-api-1.7.12.jar ../../../ext/metrics-core-3.
 1.2.jar ../ext/kafka_2.10-0.8.2.2.jar ../ext/kafka-clients-0.8.2.2.ja
 r ../ext/log4j-1.2.16.jar ../ext/metrics-core-2.2.0.jar ../ext/scala-
 library-2.10.4.jar ../ext/zkclient-0.3.jar ../ext/zookeeper-3.4.6.jar

edgent.api.topology.jar itself has lots of edgent jar dependencies (captured in 
its manifest) but that’s of no concern to the kafka connector.  I’m not sure 
maintaining this is a requirement and, at least for gradle, eliminating it 
would have greatly simplified things.

Test execution environment was also an issue.  perhaps more a result of 
structural issues.  i.e., the gradle config treated a component’s tests as unit 
tests, run against the associated component’s .class files.  The ant system 
treated them more like integration tests, run against the jar files that would 
be bundled into a binary-release bundle; more like the environment that 
Edgent-based applications would use.  That was very important.  And due to some 
manual setup requirements for some connector tests are excluded from execution 
by default.

> …
> In the Flex project, I also setup the build to run SonarQube analysis and 
> automatically generate the documentation from markdown and/or asciidoctor 
> (which I think is very convenient) even automatically update and deploy the 
> project website. 

We include use of jacoco
We have travis integration for auto-PR validation.
It would be nice to have some periodic build/regression testing run on the main 
(master) branch.

> I could offer to create a fork on GitHub, create a feature branch there and 
> try to whip up a set of poms that add Maven as fourth build system to the 
> list … you could check it out and play around with it. But I’d only do this, 
> if there is any interest in it.

I don’t blame you!

One worry I have is that it ends up like the gradle effort… it was ~trivial to 
get started but there was then a lot of effort required identify and flesh out 
equivalence with the ant based build result artifacts.
If you’re on board for the long haul in doing a conversion then that lessens my 
concern.

I’m on board to help but don’t want to inherit a “now finish it” task :-)

A full switch to a ~simple mvn-based build system would be the goal IMO — we’d 
want to toss gradle. The effort ultimately also entails updating a bunch of 
doc.  Not a killer, just not to be overlooked.

It’s unclear to me how the Edgent-based app developers will be affected by all 
of this.  OK, they build their Edgent-based app with some tool that can utilize 
a maven repo.  Then what?

Today the story is