Removal of gradle stuff has been committed.
— Dale
> On Oct 30, 2017, at 10:53 AM, Dale LaBossiere wrote:
>
> Yes, that helps, thanks.
> I’ve got most of the gradle stuff removed in my workspace and verified
> everything built, etc. I’ll make those other gradle cleanups you mention and
> comm
Yes, that helps, thanks.
I’ve got most of the gradle stuff removed in my workspace and verified
everything built, etc. I’ll make those other gradle cleanups you mention and
commit it.
Sounds like we can skip the dry-run and just get to “develop” right away (after
I commit the gradle removal).
L
Hi Dale,
I guess I could do a „dry-run“-release to check things but I wouldn’t expect
any real problems with this. I could make a short demonstration of that. When
doing a real release, I think it would be a good idea for me to do that and to
create a video in which I explain what has to be don
> On Oct 29, 2017, at 6:28 AM, Christofer Dutz
> wrote:
> ...
> So, it seems the legal stuff has been sorted out, the errors in the output
> have been resolved and the problems with periodically failing tests have been
> resolved. From my point of view, we could start merging things back to
>
Hi all,
reviving this older thread :-)
So, it seems the legal stuff has been sorted out, the errors in the output have
been resolved and the problems with periodically failing tests have been
resolved. From my point of view, we could start merging things back to
origin/develop … what do you th
Thanks for digging into this Chris. Your efforts are appreciated.
Susan
> On Sep 20, 2017, at 4:55 AM, Christofer Dutz
> wrote:
>
> Hi all,
>
> ok so finding this little detail got me on the right path. I updated index.js
> to use “source” instead of “sourceIdx” and “target” instead of “targ
Hi Dale,
I’m sure that is the reason for this. I did investigate that problem a wile
yesterday and I found out that the MBean the ConsoleMetricsServlet->MetricsUtil
(line 105) is using to generate the output returns “long” instead of “counter”
… but I have to admit that I have no Idea why.
Wil
> On Sep 20, 2017, at 12:03 PM, Dale LaBossiere wrote:
>
> Yay, we have graphs!
>
> In briefly playing with the console I noticed a number of things that I’ll
> have to investigate to verify they’re not regressions (others chime in if you
> know them to be present on the master branch):
>
>
Yay, we have graphs!
In briefly playing with the console I noticed a number of things that I’ll have
to investigate to verify they’re not regressions (others chime in if you know
them to be present on the master branch):
- The Pause Graph button does pause graph info update (e.g., metrics on
h
Excellent! I had made some progress starting to track this down but hadn’t
gotten as far as you.
I’ll pull and git it a go.
— Dale
> On Sep 20, 2017, at 7:55 AM, Christofer Dutz
> wrote:
>
> Hi all,
>
> ok so finding this little detail got me on the right path. I updated index.js
> to use “
Hi all,
ok so finding this little detail got me on the right path. I updated index.js
to use “source” instead of “sourceIdx” and “target” instead of “targetIdx” and
now the console is working identically to the original gradle version.
Chris
Am 20.09.17, 13:30 schrieb "Christofer Dutz" :
Ok so today I investigated the problem a little more.
Seems to be one of those cool problems you get when operating with a type less
language ;-)
There is a difference between the original Sankey.js and the Edgent version.
The difference is that the original uses “source” and “target” while the
I did look at Chris’s pull request and don’t see any changes to the file that
is formatting the metrics.
I also looked at the java class that is sending the metrics to the console -
that code looks unchanged as well, so I am at a loss for what did change.
Perhaps some of the underlying java clas
Hmm… I’m not familiar with that code but will take a look.
Susan, any thoughts, including whether or not this sort of difference could
account for the graph not getting rendered but the console page otherwise
looking ok? (reminder this is pr309 and you can clone Chris’s fork to get all
the cha
Hi all,
well I did have a more detailed look at the original (Gradle) version and the
maven version. When running both examples, I could see two requests every 5
seconds. Both of them are answered by the server. The “jobs” request is
answered identically. The difference seems to be in the “metr
Hi Dale,
last weekend I addressed your open points regarding the source releases.
One thing I should mention is that the editor files shouldn’t be a problem as
when using the maven-release-plugin the tagged version of the sources are
checked out and built. So there shouldn’t be any leftover fi
Chris,
Simply stated: awesome progress while I’ve been out. Nice work!!!
I’m now starting to review all of the changes to bring myself up to date.
I completely agree with the desire to merge asap… with emphasis on “as
possible” / “as practical” :-)
Hopefully I’ll reach your conclusion that now i
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
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/E
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,
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 prob
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
Hi Dale,
thanks for the summary … highly appreciated ;-)
- I’ll add the console app to my highest priority todo.
- I already started completely re-writing the DEVELOMENT.md
- I’ll take care of Nexus, Jenkins as soon as the PR is merged or at least the
branch is moved to the core Edgent repo (no
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/
Sounds reasonable. Thanks!
— Dale
> On Aug 9, 2017, at 2:55 AM, Christofer Dutz wrote:
>
> Hi Dale,
>
> I guess it would be a lot easier to split. This way the work of splitting has
> to be done exactly once and from then on everything is super easy. The other
> way around it doesn’t cost an
Hi Dale,
I guess it would be a lot easier to split. This way the work of splitting has
to be done exactly once and from then on everything is super easy. The other
way around it doesn’t cost anything to setup, but the costs of releasing
increase dramatically due to the requirement to cherry pic
In the near term I was thinking/hoping that simply separating the samples and
the core *source release bundles* would be less disruptive than, though a
necessary precursor to, migrating the samples to a separate repo.
If it’s simply much easier, given maven and the release plugins, to have a
se
Hi Dale,
great you’re looking into this issue … I would have to work myself into the
topic a little more in order to address that.
Regarding the samples issues: I would strongly suggest to request a separate
GIT repo for the samples. While it is possible to keep them in there, there are
a lot
That explains the failure in the SVT test in travis. Ugh. :-(
I’ll look into it. By the end of the day I’ll either fix it or temporarily
disable the SVT test (and add a tracking item to the wiki page).
As I noted in the PR, the top-level pom.xml has comments (3?) related to the
handling of t
Hi all,
I just pulled in Dales changes to my forks branch. I like excluding the
examples from the core build. However there is one problem as the test/svt
project has a test dependency on the samples/apps project. If this is excluded,
the build will probably fail.
I would suggest to adjust the
Hi,
I just pushed a change that includes my improved jar-free version of the
maven-wrapper that should be 100% compliant with Apache Release rules.
It’s currently the exact same version I submitted as pull-request for the
maven-wrapper project, but as the scripts are duplicated and checked in an
By the way … my pull request for the maven-wrapper is currently being finalized
… hopefully this will be finished soon and then it will make things even easier
;-)
https://github.com/takari/maven-wrapper/pull/60
Chris
Am 17.07.17, 16:03 schrieb "Dale LaBossiere" :
Sorry for that confusion.
Sorry for that confusion. There are so many details to track / deal with.
The Issues / TODOs in [1] all need to be reviewed and need resolutions. Can we
just work from that? (marking done items as such, including the resolution, and
then just doing a strikethrough it the resolved item)
Right
Hi guys,
So right now, I sort of lost track of what’s still left to do on your wish list
for a successful maven migration.
If someone could compile a list of things to do, I would gladly work on those
issues. Must admit that I lost track a little on the confluence page.
Chris
34 matches
Mail list logo
