Hi All,
Ok so I double checked the confluence Maven vs Gradle page and think I
addressed the remaining open issues.
The Site generation now works fine from my point of view.
So, what’s left to do? Do we need any final changes?
I think it would be good to do the merge back soon as I do think that it does
make it more difficult for others to contribute and/or makes it more difficult
for us to maintain the branch if others started contributing more.
Chris
Am 22.08.17, 15:01 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi,
so today I finally got Travis to be green again :-)
So, my next step was to setup a Jenkins build on the ASF Jenkins. That too
is now done:
https://builds.apache.org/view/E-G/view/Edgent/job/edgent-dev/5/console
All Edgent jobs will be located here:
https://builds.apache.org/view/E-G/view/Edgent/
Right now, it still references the branch in my fork, but as soon as the
changes get merged back, I’ll adjust that. I’m also not installing or
publishing any artifacts to Nexus yet. That too is a task I would do as soon as
we have merged things back.
I also requested Infra to allow us to use the Apache SonarQube instance (I
hope that was ok). As soon as that’s done, we’ll also be able to get code
analysis of our code as part of the build.
The difference of the Jenkins to the Travis build is that due to log file
size restrictions Travis can only build and test the Java 8 version. Jenkins
now builds Java 8, Java 7 and Android using the “toolchain” profile.
With this we now have a quick check for commits and pull requests from
Travis and have the full quality assurance on Apache Jenkins.
So far, the update …
Chris
Am 16.08.17, 09:32 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Ok …
so yesterday, while watching the latest game of thrones episode, I
updated all poms and now Eclipse doesn’t complain about anything anymore.
I even fixed some minor issues Eclipse was reporting.
So, you guys satisfied with this?
Next Stop: Repots and Site generation …
Chris
Am 15.08.17, 22:19 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi all,
today I managed to spare some time to work on the Maven migration
topic.
Here a short summary on what I fixed:
1) The console/server now bundles the servlets.war as a resource
inside the jar. So now all you need to so is reference the server jar and start
the server. It did fix all problems with the samples I tried it with.
2) Fix a problem with the JDBC Tests. In my case I couldn’t run the
tests, because my username contained a special char (“christofer.dutz”),
additionally I made the tests generate output only inside the target directory.
3) Did some additional cleaning up in the maven build (removed some
unneeded configuration options, fine-tuned the code coverage report generation)
Today I did a lot of full builds:
- Java8
- Java8, Java7
- Java8, Java7, Android (without toolchain – java7 built with java8
VM)
- Java8, Java7, Android (with toolchain – java7 built with java7 VM)
What I have on my to-do list next:
1) Optimize the Eclipse support
2) Finish the site-generation (Generation of API Docs, Test
Reports, Coverage Reports, …)
And it did show a problem I had as I was embedding a java8
servlets.war in the server and the build didn’t fail without toolchain, but
with toolchain it did fail. So, it’s a good thing to have that in place as an
additional measure of security :-)
So far, the update … looking into Eclipse next.
Chris
Am 14.08.17, 15:41 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi Dale,
I think I found out what’s going on:
In general all is setup correctly. The generated console
application is also build correctly and seems to be functional.
The only problem is that the example uses the HttpServer class
in the server module to start the server. In the old build this referenced the
war file in the servlets module relative to the server module. I cleaned that
up. Unfortunately now whenever you run the HttpServer, this expects a
target/war-resources directory containing a servlets.war file inside.
Eventually we should think of a way to do this bundling of the servlet.war
differently.
I committed a change to the pom, that ensures all is in place
for the edgent-sampes-topology example.
All examples I tested seemed to work with that.
I also added code to throw an exception in case the war file
isn’t found at all (which was the real problem)
Chris
Am 09.08.17, 21:46 schrieb "Dale LaBossiere"
<dlab...@apache.org>:
Hi Chris/team,
Since I’m going to be on vacation for the next two weeks I
wanted to send out an update, etc.
I’ve committed a lot of things to the PR over the last
couple of days and I've updated the wiki so hopefully the TODOs are
accurate/complete
https://cwiki.apache.org/confluence/display/EDGENT/Maven+vs+Gradle
<https://cwiki.apache.org/confluence/display/EDGENT/Maven+vs+Gradle>
To restate, IMO we’re working towards getting the PR in a
good enough state so that we can merge it and then pretty quickly work on
making a real release (if for no other reason as a forcing function since after
the merge the old build tooling is broken).
A couple of higher priority TODOs that come to mind:
- Item 15.h getting the Edgent console working
(HttpServer,war,get-edgent-jars.sh)
- Item 12.d DEVELOPMENT.md
- Item 10.c setup Nexus for receiving Edgent jars?
- Item 18 build requires Java7
- Item 8 Errors importing info Eclipse
- How much of a dry run of a release can be done before
merging the PR - in order to really assess the state of things?
Can we get as far as creating and actually staging
fake-RC source bundles and jars… that can then be evaluated?
As another near-term sanity/progress check it would be
great if another contributor/user could clone your repo
(https://github.com/chrisdutz/incubator-edgent
<https://github.com/chrisdutz/incubator-edgent>) and then:
- git checkout feature/maven
- follow the info in the README in the top of the repo (not
README.md) to build the Edgent SDK and then build and run some samples and
report how it went.
It would then be double great if someone could start
working on an new version of Getting Started
(https://edgent.apache.org/docs/edgent-getting-started
<https://edgent.apache.org/docs/edgent-getting-started>) appropriate for the
new environment :-) … retaining the current version as is.
— Dale
