Re: What's left to do for Maven migration?

[Dale LaBossiere]

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 
> commit it.
> Sounds like we can skip the dry-run and just get to “develop” right away 
> (after I commit the gradle removal).
> Looking forward to the video! It will be very useful.
> — Dale
> 
>> On Oct 30, 2017, at 10:39 AM, Christofer Dutz  
>> wrote:
>> 
>> 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 done, how and why. 
>> 
>> Yes, I agree that splitting the examples into a separate repo is still a 
>> good thing to do. It makes things a lot simpler, I think. But we should 
>> merge back first and then ask Infra to do the split.
>> 
>> I would also like to remove all the Gradle stuff as in some of the last 
>> commits for example, you added exceptions to several projects to exclude 
>> Gradle stuff. I would like to remove both the Gradle as well as the Gradle 
>> exclusions ;-)
>> 
>> Well usually on “master” you have the code state of the last release. 
>> “develop” is where development is done. As soon as a new release is done, 
>> master is usually updated to the new release version. That’s why develop 
>> usually produces the “SNAPSHOT” and master the “RELEASE” versions. 
>> 
>> Hope that makes things a little clearer.
>> 
>> Chris
>> 
>> 
>> 
>> Am 30.10.17, 15:25 schrieb "Dale LaBossiere" :
>> 
>> 
>>> 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 
>>> origin/develop … what do you think?
>> 
>>   Any need/value in doing some “pre-merge” release process stuff to verify 
>> as much as is possible is in place ready to go after merging? Or will that 
>> just unnecessarily slow things down? See related question about “develop” 
>> below.
>> 
>>   This week I plan on working on the getting-started and downloads website 
>> pages.  I’ll also work on the RELEASE_NOTES.
>>   A reminder that the samples are to be split off into a separate repo 
>> post-merge - that’s still desired, right?  The main motivation was a 
>> separate samples source bundle as part of our overall release.
>> 
>>> Should we remove the Gradle stuff all together? I think right now the 
>>> project probably wouldn’t build with the old Gradle as we did change and 
>>> move around quite some stuff.
>> 
>>   Yeah, I’m sure it wouldn’t work :-)  Removing all of the gradle pieces in 
>> a single commit would be great.  Is that better left until after the merge? 
>> I think I could go either way.
>> 
>>> Would be super awesome if we had this finished in about 2 weeks as then I 
>>> would turn on the distribution of SNAPSHOT versions (ok … as soon as the 
>>> branch name is “develop” the Jenkinsfile will automatically do that). I 
>>> would be needing these SNAPSHOTS for the next sprint of my PLC library 
>>> project.
>> 
>>   That would be great!  FYI, I’m unavailable Nov 8th - 19th.
>> 
>>   What’s the relationship between this new “develop” branch and today’s 
>> “master”?  Is the "distribution of develop SNAPSHOTS" just to the ASF nexus 
>> snapshots repo?  So can creating “develop” and merging to it can be done 
>> immediately and then work on the actual release (including updating master) 
>> proceed afterwards?
>> 
>>   Thanks!
>>   — Dale
>> 
> 

Re: What's left to do for Maven migration?

[Dale LaBossiere]

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).
Looking forward to the video! It will be very useful.
— Dale

> On Oct 30, 2017, at 10:39 AM, Christofer Dutz  
> wrote:
> 
> 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 done, how and why. 
> 
> Yes, I agree that splitting the examples into a separate repo is still a good 
> thing to do. It makes things a lot simpler, I think. But we should merge back 
> first and then ask Infra to do the split.
> 
> I would also like to remove all the Gradle stuff as in some of the last 
> commits for example, you added exceptions to several projects to exclude 
> Gradle stuff. I would like to remove both the Gradle as well as the Gradle 
> exclusions ;-)
> 
> Well usually on “master” you have the code state of the last release. 
> “develop” is where development is done. As soon as a new release is done, 
> master is usually updated to the new release version. That’s why develop 
> usually produces the “SNAPSHOT” and master the “RELEASE” versions. 
> 
> Hope that makes things a little clearer.
> 
> Chris
> 
> 
> 
> Am 30.10.17, 15:25 schrieb "Dale LaBossiere" :
> 
> 
>> 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 
>> origin/develop … what do you think?
> 
>Any need/value in doing some “pre-merge” release process stuff to verify 
> as much as is possible is in place ready to go after merging? Or will that 
> just unnecessarily slow things down? See related question about “develop” 
> below.
> 
>This week I plan on working on the getting-started and downloads website 
> pages.  I’ll also work on the RELEASE_NOTES.
>A reminder that the samples are to be split off into a separate repo 
> post-merge - that’s still desired, right?  The main motivation was a separate 
> samples source bundle as part of our overall release.
> 
>> Should we remove the Gradle stuff all together? I think right now the 
>> project probably wouldn’t build with the old Gradle as we did change and 
>> move around quite some stuff.
> 
>Yeah, I’m sure it wouldn’t work :-)  Removing all of the gradle pieces in 
> a single commit would be great.  Is that better left until after the merge? I 
> think I could go either way.
> 
>> Would be super awesome if we had this finished in about 2 weeks as then I 
>> would turn on the distribution of SNAPSHOT versions (ok … as soon as the 
>> branch name is “develop” the Jenkinsfile will automatically do that). I 
>> would be needing these SNAPSHOTS for the next sprint of my PLC library 
>> project.
> 
>That would be great!  FYI, I’m unavailable Nov 8th - 19th.
> 
>What’s the relationship between this new “develop” branch and today’s 
> “master”?  Is the "distribution of develop SNAPSHOTS" just to the ASF nexus 
> snapshots repo?  So can creating “develop” and merging to it can be done 
> immediately and then work on the actual release (including updating master) 
> proceed afterwards?
> 
>Thanks!
>— Dale
> 

Re: What's left to do for Maven migration?

[Dale LaBossiere]

> 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 
> origin/develop … what do you think?

Any need/value in doing some “pre-merge” release process stuff to verify as 
much as is possible is in place ready to go after merging? Or will that just 
unnecessarily slow things down? See related question about “develop” below.

This week I plan on working on the getting-started and downloads website pages. 
 I’ll also work on the RELEASE_NOTES.
A reminder that the samples are to be split off into a separate repo post-merge 
- that’s still desired, right?  The main motivation was a separate samples 
source bundle as part of our overall release.

> Should we remove the Gradle stuff all together? I think right now the project 
> probably wouldn’t build with the old Gradle as we did change and move around 
> quite some stuff.

Yeah, I’m sure it wouldn’t work :-)  Removing all of the gradle pieces in a 
single commit would be great.  Is that better left until after the merge? I 
think I could go either way.

> Would be super awesome if we had this finished in about 2 weeks as then I 
> would turn on the distribution of SNAPSHOT versions (ok … as soon as the 
> branch name is “develop” the Jenkinsfile will automatically do that). I would 
> be needing these SNAPSHOTS for the next sprint of my PLC library project.

That would be great!  FYI, I’m unavailable Nov 8th - 19th.

What’s the relationship between this new “develop” branch and today’s “master”? 
 Is the "distribution of develop SNAPSHOTS" just to the ASF nexus snapshots 
repo?  So can creating “develop” and merging to it can be done immediately and 
then work on the actual release (including updating master) proceed afterwards?

Thanks!
— Dale

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 think?

Should we remove the Gradle stuff all together? I think right now the project 
probably wouldn’t build with the old Gradle as we did change and move around 
quite some stuff.

Would be super awesome if we had this finished in about 2 weeks as then I would 
turn on the distribution of SNAPSHOT versions (ok … as soon as the branch name 
is “develop” the Jenkinsfile will automatically do that). I would be needing 
these SNAPSHOTS for the next sprint of my PLC library project.

Chris


Am 20.09.17, 19:32 schrieb "Christofer Dutz" :

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.

Will investigate tomorrow ;-)

Chris



Am 20.09.17, 18:33 schrieb "Dale LaBossiere" :


> 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):
> 
> - The Pause Graph button does pause graph info update (e.g., metrics 
on hovers), however the metrics charts continue to update.
> - Hover on a Counter or StreamScope oplet doesn’t report streams or 
tuples info like on “normal” oplets.  However that info for them is cleanly 
visible in the All Oplet Properties table
> - The All Oplet Properties table doesn’t refresh.  There’s a Pause 
refresh button on it that doesn’t yield any observable behavior.

Those behaviors are the same / no regression  :-/

But here’s a regression:

When you hover on a stream, in 1.1.0 the bottom of the hover reports a 
tuple count.  On the maven branch the bottom of the hover reports “No value - 
counter not present”

That’s emitted by index.js/1164/renderGraph based on d.derived being 
true.  Not yet sure how that comes to be.  Chris, maybe related to your earlier 
observation:

The working version of the Gradle version produces this:

{
   "jobId": "JOB_0",
   "ops": [
   {
   "opId": "OP_2",
   "metrics": [
   {
   "type": "counter",
   "name": "Count",
   "value": "219"
   }
   ]
   }
   ]
}

The Maven version however produces this:

{
   "jobId": "JOB_0",
   "ops": [
   {
   "opId": "OP_2",
   "metrics": [
   {
   "type": "long",
   "name": "Count",
   "value": "436"
   }
   ]
   }
   ]
}
> 

Re: What's left to do for Maven migration?

[Christofer Dutz]

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.

Will investigate tomorrow ;-)

Chris



Am 20.09.17, 18:33 schrieb "Dale LaBossiere" :


> 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):
> 
> - The Pause Graph button does pause graph info update (e.g., metrics on 
hovers), however the metrics charts continue to update.
> - Hover on a Counter or StreamScope oplet doesn’t report streams or 
tuples info like on “normal” oplets.  However that info for them is cleanly 
visible in the All Oplet Properties table
> - The All Oplet Properties table doesn’t refresh.  There’s a Pause 
refresh button on it that doesn’t yield any observable behavior.

Those behaviors are the same / no regression  :-/

But here’s a regression:

When you hover on a stream, in 1.1.0 the bottom of the hover reports a 
tuple count.  On the maven branch the bottom of the hover reports “No value - 
counter not present”

That’s emitted by index.js/1164/renderGraph based on d.derived being true.  
Not yet sure how that comes to be.  Chris, maybe related to your earlier 
observation:

The working version of the Gradle version produces this:

{
   "jobId": "JOB_0",
   "ops": [
   {
   "opId": "OP_2",
   "metrics": [
   {
   "type": "counter",
   "name": "Count",
   "value": "219"
   }
   ]
   }
   ]
}

The Maven version however produces this:

{
   "jobId": "JOB_0",
   "ops": [
   {
   "opId": "OP_2",
   "metrics": [
   {
   "type": "long",
   "name": "Count",
   "value": "436"
   }
   ]
   }
   ]
}
> 

Re: What's left to do for Maven migration?

[Dale LaBossiere]

> 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):
> 
> - The Pause Graph button does pause graph info update (e.g., metrics on 
> hovers), however the metrics charts continue to update.
> - Hover on a Counter or StreamScope oplet doesn’t report streams or tuples 
> info like on “normal” oplets.  However that info for them is cleanly visible 
> in the All Oplet Properties table
> - The All Oplet Properties table doesn’t refresh.  There’s a Pause refresh 
> button on it that doesn’t yield any observable behavior.

Those behaviors are the same / no regression  :-/

But here’s a regression:

When you hover on a stream, in 1.1.0 the bottom of the hover reports a tuple 
count.  On the maven branch the bottom of the hover reports “No value - counter 
not present”

That’s emitted by index.js/1164/renderGraph based on d.derived being true.  Not 
yet sure how that comes to be.  Chris, maybe related to your earlier 
observation:

The working version of the Gradle version produces this:

{
   "jobId": "JOB_0",
   "ops": [
   {
   "opId": "OP_2",
   "metrics": [
   {
   "type": "counter",
   "name": "Count",
   "value": "219"
   }
   ]
   }
   ]
}

The Maven version however produces this:

{
   "jobId": "JOB_0",
   "ops": [
   {
   "opId": "OP_2",
   "metrics": [
   {
   "type": "long",
   "name": "Count",
   "value": "436"
   }
   ]
   }
   ]
}
> 

Re: What's left to do for Maven migration?

[Dale LaBossiere]

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 
hovers), however the metrics charts continue to update.
- Hover on a Counter or StreamScope oplet doesn’t report streams or tuples info 
like on “normal” oplets.  However that info for them is cleanly visible in the 
All Oplet Properties table
- The All Oplet Properties table doesn’t refresh.  There’s a Pause refresh 
button on it that doesn’t yield any observable behavior.

— Dale

> On Sep 20, 2017, at 11:05 AM, Dale LaBossiere  wrote:
> 
> 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 “source” instead of “sourceIdx” and “target” instead of 
>> “targetIdx” and now the console is working identically to the original 
>> gradle version.
>> 
>> Chris

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 Edgent version uses “sourceIdx” and “targetIdx” so I am getting JavaScript 
errors in the browser. 
I think I should try and find a solution for this and then see if the 
charts come back. If that doesn’t help I can still get my hands dirty by 
digging in the depths of the system.

Chris



Am 19.09.17, 17:59 schrieb "Susan Cline" :

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 classes the servlets or utility 
classes accessed changed?

Susan


> On Sep 18, 2017, at 8:02 AM, Dale LaBossiere  
wrote:
> 
> 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 changes)
> 
> — Dale
> 
>> On Sep 18, 2017, at 8:54 AM, Christofer Dutz 
 wrote:
>> 
>> 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 “metrics” 
response:
>> 
>> The working version of the Gradle version produces this:
>> 
>> {
>>   "jobId": "JOB_0",
>>   "ops": [
>>   {
>>   "opId": "OP_2",
>>   "metrics": [
>>   {
>>   "type": "counter",
>>   "name": "Count",
>>   "value": "219"
>>   }
>>   ]
>>   }
>>   ]
>> }
>> 
>> The Maven version however produces this:
>> 
>> {
>>   "jobId": "JOB_0",
>>   "ops": [
>>   {
>>   "opId": "OP_2",
>>   "metrics": [
>>   {
>>   "type": "long",
>>   "name": "Count",
>>   "value": "436"
>>   }
>>   ]
>>   }
>>   ]
>> }
>> 
>> The difference seems to be that the “type” is “counter” in the 
working version and “long” in the not working version. I tried debugging this, 
but I couldn’t really understand why this is different.
>> 
>> Any ideas what could be wrong? I guess in general things should be 
working, all we have to do is fix some final mini-quirks.
>> 
>> Chris
> 


.

Re: What's left to do for Maven migration?

[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 Edgent 
version uses “sourceIdx” and “targetIdx” so I am getting JavaScript errors in 
the browser. 
I think I should try and find a solution for this and then see if the charts 
come back. If that doesn’t help I can still get my hands dirty by digging in 
the depths of the system.

Chris



Am 19.09.17, 17:59 schrieb "Susan Cline" :

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 classes the servlets or utility classes 
accessed changed?

Susan


> On Sep 18, 2017, at 8:02 AM, Dale LaBossiere  wrote:
> 
> 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 changes)
> 
> — Dale
> 
>> On Sep 18, 2017, at 8:54 AM, Christofer Dutz  
wrote:
>> 
>> 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 “metrics” response:
>> 
>> The working version of the Gradle version produces this:
>> 
>> {
>>   "jobId": "JOB_0",
>>   "ops": [
>>   {
>>   "opId": "OP_2",
>>   "metrics": [
>>   {
>>   "type": "counter",
>>   "name": "Count",
>>   "value": "219"
>>   }
>>   ]
>>   }
>>   ]
>> }
>> 
>> The Maven version however produces this:
>> 
>> {
>>   "jobId": "JOB_0",
>>   "ops": [
>>   {
>>   "opId": "OP_2",
>>   "metrics": [
>>   {
>>   "type": "long",
>>   "name": "Count",
>>   "value": "436"
>>   }
>>   ]
>>   }
>>   ]
>> }
>> 
>> The difference seems to be that the “type” is “counter” in the working 
version and “long” in the not working version. I tried debugging this, but I 
couldn’t really understand why this is different.
>> 
>> Any ideas what could be wrong? I guess in general things should be 
working, all we have to do is fix some final mini-quirks.
>> 
>> Chris
> 


.

Re: What's left to do for Maven migration?

[Susan Cline]

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 classes the servlets or utility classes 
accessed changed?

Susan


> On Sep 18, 2017, at 8:02 AM, Dale LaBossiere  wrote:
> 
> 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 changes)
> 
> — Dale
> 
>> On Sep 18, 2017, at 8:54 AM, Christofer Dutz  
>> wrote:
>> 
>> 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 “metrics” 
>> response:
>> 
>> The working version of the Gradle version produces this:
>> 
>> {
>>   "jobId": "JOB_0",
>>   "ops": [
>>   {
>>   "opId": "OP_2",
>>   "metrics": [
>>   {
>>   "type": "counter",
>>   "name": "Count",
>>   "value": "219"
>>   }
>>   ]
>>   }
>>   ]
>> }
>> 
>> The Maven version however produces this:
>> 
>> {
>>   "jobId": "JOB_0",
>>   "ops": [
>>   {
>>   "opId": "OP_2",
>>   "metrics": [
>>   {
>>   "type": "long",
>>   "name": "Count",
>>   "value": "436"
>>   }
>>   ]
>>   }
>>   ]
>> }
>> 
>> The difference seems to be that the “type” is “counter” in the working 
>> version and “long” in the not working version. I tried debugging this, but I 
>> couldn’t really understand why this is different.
>> 
>> Any ideas what could be wrong? I guess in general things should be working, 
>> all we have to do is fix some final mini-quirks.
>> 
>> Chris
> 


.

Re: What's left to do for Maven migration?

[Dale LaBossiere]

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 changes)

— Dale

> On Sep 18, 2017, at 8:54 AM, Christofer Dutz  
> wrote:
> 
> 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 “metrics” response:
> 
> The working version of the Gradle version produces this:
> 
> {
>"jobId": "JOB_0",
>"ops": [
>{
>"opId": "OP_2",
>"metrics": [
>{
>"type": "counter",
>"name": "Count",
>"value": "219"
>}
>]
>}
>]
> }
> 
> The Maven version however produces this:
> 
> {
>"jobId": "JOB_0",
>"ops": [
>{
>"opId": "OP_2",
>"metrics": [
>{
>"type": "long",
>"name": "Count",
>"value": "436"
>}
>]
>}
>]
> }
> 
> The difference seems to be that the “type” is “counter” in the working 
> version and “long” in the not working version. I tried debugging this, but I 
> couldn’t really understand why this is different.
> 
> Any ideas what could be wrong? I guess in general things should be working, 
> all we have to do is fix some final mini-quirks.
> 
> Chris

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 “metrics” response:

The working version of the Gradle version produces this:

{
"jobId": "JOB_0",
"ops": [
{
"opId": "OP_2",
"metrics": [
{
"type": "counter",
"name": "Count",
"value": "219"
}
]
}
]
}

The Maven version however produces this:

{
"jobId": "JOB_0",
"ops": [
{
"opId": "OP_2",
"metrics": [
{
"type": "long",
"name": "Count",
"value": "436"
}
]
}
]
}

The difference seems to be that the “type” is “counter” in the working version 
and “long” in the not working version. I tried debugging this, but I couldn’t 
really understand why this is different.

Any ideas what could be wrong? I guess in general things should be working, all 
we have to do is fix some final mini-quirks.

Chris



Am 18.09.17, 11:02 schrieb "Christofer Dutz" :

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 files. This should 
only be a problem when manually activating the “apache-release” profile.

I also I filled one of the two TODOs in the DEVELOPMENT.md file.

Added inline comments in the confluence page … will have a look at the 
samples next.

Chris


Am 30.08.17, 18:44 schrieb "Dale LaBossiere" :

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 is the time.

— Dale

> On Aug 28, 2017, at 4:58 AM, Christofer Dutz 
 wrote:
> 
> 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
> 

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 files. This should 
only be a problem when manually activating the “apache-release” profile.

I also I filled one of the two TODOs in the DEVELOPMENT.md file.

Added inline comments in the confluence page … will have a look at the samples 
next.

Chris


Am 30.08.17, 18:44 schrieb "Dale LaBossiere" :

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 is the time.

— Dale

> On Aug 28, 2017, at 4:58 AM, Christofer Dutz  
wrote:
> 
> 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
> 

Re: What's left to do for Maven migration?

[Dale LaBossiere]

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 is the time.

— Dale

> On Aug 28, 2017, at 4:58 AM, Christofer Dutz  
> wrote:
> 
> 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
> 

Re: What's left to do for Maven migration?

[Christofer Dutz]

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" :

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" :

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" 
:

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" 
:

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.

Re: What's left to do for Maven migration?

[Christofer Dutz]

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" :

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" :

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" 
:

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" :

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 


 

Re: What's left to do for Maven migration?

[Christofer Dutz]

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" :

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" :

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" :

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 


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 
) 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 

Re: What's left to do for Maven migration?

[Christofer Dutz]

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" :

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" :

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 


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 
) 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 
) appropriate for the 
new environment :-) … retaining the current version as is.

— Dale

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 longer my fork)
- Java 7 should no longer be a requirement (It’s now optional and only needed 
if the “toolchains” Maven profile is enabled)
- Will re-install Eclipse on my new Mac and see what I can do about the errors
- The maven-release-plugin has a built in dry-run option so we could do such a 
check immediately. If I simply branch off my branch again and change the remote 
maven repo address to my private Artifactory instance, I could even to a full 
release without any issues. We could do that in form of a video conference, if 
you like … then I could demonstrate everything super-easy.

Chris



Am 09.08.17, 21:46 schrieb "Dale LaBossiere" :

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 


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 
) 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 
) appropriate for the 
new environment :-) … retaining the current version as is.

— Dale

Re: What's left to do for Maven migration?

[Dale LaBossiere]

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 anything to setup, but the costs of releasing 
> increase dramatically due to the requirement to cherry pick commits.
> 
> Sure, I could request the things needed and handle the execution. But I quess 
> that would be a runner-up task after merging back the maven changes first.
> 
> Chris
> 
> 
> Am 08.08.17, 22:11 schrieb "Dale LaBossiere" :
> 
>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 
> separate repos to achieve separate core / samples source release bundles, 
> then maybe that needs to be considered now.  Chris, would you be able to set 
> that up?  Maybe give it a thought while I’m out. 
> 
>Thanks!
>— Dale
> 
>> On Aug 8, 2017, at 10:14 AM, Christofer Dutz  
>> wrote:
>> 
>> 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 of issues that have to be dealt with this way.
>> First of all you have to exclude stuff from rat (as you have seen), then you 
>> have to exclude stuff from the releases (as you have seen too), but probably 
>> the most annoying thing is dealing with releasing in GIT.
>> Having mixed repos, we would have several tags in one repo reflecting 
>> releases of Edgent and the samples. While I would treat this fact as 
>> “annoying” at most, the main problem will be merging the parts that are part 
>> of the release back to the master branch.
>> 
>> If the repos are separate, all you have to do is merge the tagged release 
>> revision back to master and all is good. In case of a mixed repo, you will 
>> have to do a lot of manual merging and cherry picking.
>> 
>> So I would opt for splitting up the repos and creating nicely separated 
>> build configs for both.
>> 
>> Repos are cheap at the ASF :-)
>> 
>> Chris
>> 
>> 
>> 
>> 
>> Am 08.08.17, 15:59 schrieb "Dale LaBossiere" :
>> 
>>   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 the samples project.  When you get a chance could you look 
>> at those and perhaps identify what needs to be done to address them?  Thanks!
>> 
>>   — Dale
>> 
>> 
>>> On Aug 8, 2017, at 9:36 AM, Christofer Dutz  
>>> wrote:
>>> 
>>> 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 test to not rely on a sample. Hereby I could 
>>> remove the top most issue in the “problems” document.
>>> 
>>> Should we leave everything the way it currently is, or should I create a 
>>> feature/maven branch in the Edgent repo? I’m fine with both options. If 
>>> anyone else needs write access to my fork, just send me an email. 
>>> 
>>> Chris
>>> 
>>> 
>>> Am 23.07.17, 20:05 schrieb "Christofer Dutz" :
>>> 
>>>  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 
>>> anyway, I thought I’d just go ahead and add them to Edgent.
>>>  My first tests were perfect :-)
>>> 
>>>  So now, if you checked out Edgent and have JAVA_HOME set all you need to 
>>> do, is run: 
>>> 
>>>  ./mvnw clean install
>>> 
>>>  and it will download the maven version, install it and use it. So you can 
>>> now reduce the requirements to having Java 8 Installed.
>>> 
>>>  One thing I noticed today – as I’m currently setting up my new laptop – is 
>>> that it’s no longer trivial to get a Java 7 JDK. 
>>>  I will try to figure out how to setup the toolchain to support building 
>>> Java 7 with only Java 8 in the next few days … 

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 pick commits.

Sure, I could request the things needed and handle the execution. But I quess 
that would be a runner-up task after merging back the maven changes first.

Chris


Am 08.08.17, 22:11 schrieb "Dale LaBossiere" :

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 
separate repos to achieve separate core / samples source release bundles, then 
maybe that needs to be considered now.  Chris, would you be able to set that 
up?  Maybe give it a thought while I’m out. 

Thanks!
— Dale

> On Aug 8, 2017, at 10:14 AM, Christofer Dutz  
wrote:
> 
> 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 of issues that have to be dealt with this way.
> First of all you have to exclude stuff from rat (as you have seen), then 
you have to exclude stuff from the releases (as you have seen too), but 
probably the most annoying thing is dealing with releasing in GIT.
> Having mixed repos, we would have several tags in one repo reflecting 
releases of Edgent and the samples. While I would treat this fact as “annoying” 
at most, the main problem will be merging the parts that are part of the 
release back to the master branch.
> 
> If the repos are separate, all you have to do is merge the tagged release 
revision back to master and all is good. In case of a mixed repo, you will have 
to do a lot of manual merging and cherry picking.
> 
> So I would opt for splitting up the repos and creating nicely separated 
build configs for both.
> 
> Repos are cheap at the ASF :-)
> 
> Chris
> 
> 
> 
> 
> Am 08.08.17, 15:59 schrieb "Dale LaBossiere" :
> 
>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 the samples project.  When you get a chance could you look 
at those and perhaps identify what needs to be done to address them?  Thanks!
> 
>— Dale
> 
> 
>> On Aug 8, 2017, at 9:36 AM, Christofer Dutz  
wrote:
>> 
>> 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 test to not rely on a sample. Hereby I 
could remove the top most issue in the “problems” document.
>> 
>> Should we leave everything the way it currently is, or should I create a 
feature/maven branch in the Edgent repo? I’m fine with both options. If anyone 
else needs write access to my fork, just send me an email. 
>> 
>> Chris
>> 
>> 
>> Am 23.07.17, 20:05 schrieb "Christofer Dutz" :
>> 
>>   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 
anyway, I thought I’d just go ahead and add them to Edgent.
>>   My first tests were perfect :-)
>> 
>>   So now, if you checked out Edgent and have JAVA_HOME set all you need 
to do, is run: 
>> 
>>   ./mvnw clean install
>> 
>>   and it will download the maven version, install it and use it. So you 
can now reduce the requirements to having Java 8 Installed.
>> 
>>   One thing I noticed today – as I’m currently setting up my new laptop 
– is that it’s no longer trivial to get a Java 7 JDK. 
>>   I will try to figure out how to setup the toolchain to support 
building Java 7 with only Java 8 in the next few days … hopefully it will be as 
easy as defining a java 7 JDK which 

Re: What's left to do for Maven migration?

[Dale LaBossiere]

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 
separate repos to achieve separate core / samples source release bundles, then 
maybe that needs to be considered now.  Chris, would you be able to set that 
up?  Maybe give it a thought while I’m out. 

Thanks!
— Dale

> On Aug 8, 2017, at 10:14 AM, Christofer Dutz  
> wrote:
> 
> 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 of issues that have to be dealt with this way.
> First of all you have to exclude stuff from rat (as you have seen), then you 
> have to exclude stuff from the releases (as you have seen too), but probably 
> the most annoying thing is dealing with releasing in GIT.
> Having mixed repos, we would have several tags in one repo reflecting 
> releases of Edgent and the samples. While I would treat this fact as 
> “annoying” at most, the main problem will be merging the parts that are part 
> of the release back to the master branch.
> 
> If the repos are separate, all you have to do is merge the tagged release 
> revision back to master and all is good. In case of a mixed repo, you will 
> have to do a lot of manual merging and cherry picking.
> 
> So I would opt for splitting up the repos and creating nicely separated build 
> configs for both.
> 
> Repos are cheap at the ASF :-)
> 
> Chris
> 
> 
> 
> 
> Am 08.08.17, 15:59 schrieb "Dale LaBossiere" :
> 
>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 the samples project.  When you get a chance could you look at 
> those and perhaps identify what needs to be done to address them?  Thanks!
> 
>— Dale
> 
> 
>> On Aug 8, 2017, at 9:36 AM, Christofer Dutz  
>> wrote:
>> 
>> 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 test to not rely on a sample. Hereby I could 
>> remove the top most issue in the “problems” document.
>> 
>> Should we leave everything the way it currently is, or should I create a 
>> feature/maven branch in the Edgent repo? I’m fine with both options. If 
>> anyone else needs write access to my fork, just send me an email. 
>> 
>> Chris
>> 
>> 
>> Am 23.07.17, 20:05 schrieb "Christofer Dutz" :
>> 
>>   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 
>> anyway, I thought I’d just go ahead and add them to Edgent.
>>   My first tests were perfect :-)
>> 
>>   So now, if you checked out Edgent and have JAVA_HOME set all you need to 
>> do, is run: 
>> 
>>   ./mvnw clean install
>> 
>>   and it will download the maven version, install it and use it. So you can 
>> now reduce the requirements to having Java 8 Installed.
>> 
>>   One thing I noticed today – as I’m currently setting up my new laptop – is 
>> that it’s no longer trivial to get a Java 7 JDK. 
>>   I will try to figure out how to setup the toolchain to support building 
>> Java 7 with only Java 8 in the next few days … hopefully it will be as easy 
>> as defining a java 7 JDK which points to the Java 8 version.
>> 
>>   Chris
>> 
>> 
>> 
>>   Am 19.07.17, 11:13 schrieb "Christofer Dutz" :
>> 
>>   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.  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 

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 of issues that have to be dealt with this way.
First of all you have to exclude stuff from rat (as you have seen), then you 
have to exclude stuff from the releases (as you have seen too), but probably 
the most annoying thing is dealing with releasing in GIT.
Having mixed repos, we would have several tags in one repo reflecting releases 
of Edgent and the samples. While I would treat this fact as “annoying” at most, 
the main problem will be merging the parts that are part of the release back to 
the master branch.

If the repos are separate, all you have to do is merge the tagged release 
revision back to master and all is good. In case of a mixed repo, you will have 
to do a lot of manual merging and cherry picking.

So I would opt for splitting up the repos and creating nicely separated build 
configs for both.

Repos are cheap at the ASF :-)

Chris




Am 08.08.17, 15:59 schrieb "Dale LaBossiere" :

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 the samples project.  When you get a chance could you look at 
those and perhaps identify what needs to be done to address them?  Thanks!

— Dale


> On Aug 8, 2017, at 9:36 AM, Christofer Dutz  
wrote:
> 
> 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 test to not rely on a sample. Hereby I 
could remove the top most issue in the “problems” document.
> 
> Should we leave everything the way it currently is, or should I create a 
feature/maven branch in the Edgent repo? I’m fine with both options. If anyone 
else needs write access to my fork, just send me an email. 
> 
> Chris
> 
> 
> Am 23.07.17, 20:05 schrieb "Christofer Dutz" :
> 
>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 
anyway, I thought I’d just go ahead and add them to Edgent.
>My first tests were perfect :-)
> 
>So now, if you checked out Edgent and have JAVA_HOME set all you need 
to do, is run: 
> 
>./mvnw clean install
> 
>and it will download the maven version, install it and use it. So you 
can now reduce the requirements to having Java 8 Installed.
> 
>One thing I noticed today – as I’m currently setting up my new laptop 
– is that it’s no longer trivial to get a Java 7 JDK. 
>I will try to figure out how to setup the toolchain to support 
building Java 7 with only Java 8 in the next few days … hopefully it will be as 
easy as defining a java 7 JDK which points to the Java 8 version.
> 
>Chris
> 
> 
> 
>Am 19.07.17, 11:13 schrieb "Christofer Dutz" 
:
> 
>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.  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 now, I think dealing with the binary release bundle and 
samples are the highest priority / largest unknowns.
> 
>Thanks for all your continued diligence!
> 
>— Dale
> 
>> On Jul 17, 2017, at 2:43 AM, Christofer Dutz  
wrote:
>> 
>> 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 

Re: What's left to do for Maven migration?

[Dale LaBossiere]

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 the samples project.  When you get a chance could you look at those 
and perhaps identify what needs to be done to address them?  Thanks!

— Dale


> On Aug 8, 2017, at 9:36 AM, Christofer Dutz  wrote:
> 
> 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 test to not rely on a sample. Hereby I could 
> remove the top most issue in the “problems” document.
> 
> Should we leave everything the way it currently is, or should I create a 
> feature/maven branch in the Edgent repo? I’m fine with both options. If 
> anyone else needs write access to my fork, just send me an email. 
> 
> Chris
> 
> 
> Am 23.07.17, 20:05 schrieb "Christofer Dutz" :
> 
>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 
> anyway, I thought I’d just go ahead and add them to Edgent.
>My first tests were perfect :-)
> 
>So now, if you checked out Edgent and have JAVA_HOME set all you need to 
> do, is run: 
> 
>./mvnw clean install
> 
>and it will download the maven version, install it and use it. So you can 
> now reduce the requirements to having Java 8 Installed.
> 
>One thing I noticed today – as I’m currently setting up my new laptop – is 
> that it’s no longer trivial to get a Java 7 JDK. 
>I will try to figure out how to setup the toolchain to support building 
> Java 7 with only Java 8 in the next few days … hopefully it will be as easy 
> as defining a java 7 JDK which points to the Java 8 version.
> 
>Chris
> 
> 
> 
>Am 19.07.17, 11:13 schrieb "Christofer Dutz" :
> 
>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.  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 now, I think dealing with the binary release bundle and 
> samples are the highest priority / largest unknowns.
> 
>Thanks for all your continued diligence!
> 
>— Dale
> 
>> On Jul 17, 2017, at 2:43 AM, Christofer Dutz  
>> wrote:
>> 
>> 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
> 
> 
> 
> 
> 
> 
> 

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 test to not rely on a sample. Hereby I could 
remove the top most issue in the “problems” document.

Should we leave everything the way it currently is, or should I create a 
feature/maven branch in the Edgent repo? I’m fine with both options. If anyone 
else needs write access to my fork, just send me an email. 

Chris


Am 23.07.17, 20:05 schrieb "Christofer Dutz" :

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 anyway, 
I thought I’d just go ahead and add them to Edgent.
My first tests were perfect :-)

So now, if you checked out Edgent and have JAVA_HOME set all you need to 
do, is run: 

./mvnw clean install

and it will download the maven version, install it and use it. So you can 
now reduce the requirements to having Java 8 Installed.

One thing I noticed today – as I’m currently setting up my new laptop – is 
that it’s no longer trivial to get a Java 7 JDK. 
I will try to figure out how to setup the toolchain to support building 
Java 7 with only Java 8 in the next few days … hopefully it will be as easy as 
defining a java 7 JDK which points to the Java 8 version.

Chris



Am 19.07.17, 11:13 schrieb "Christofer Dutz" :

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.  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 now, I think dealing with the binary release bundle and 
samples are the highest priority / largest unknowns.

Thanks for all your continued diligence!

— Dale

> On Jul 17, 2017, at 2:43 AM, Christofer Dutz 
 wrote:
> 
> 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

Re: What's left to do for Maven migration?

[Christofer Dutz]

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 anyway, 
I thought I’d just go ahead and add them to Edgent.
My first tests were perfect :-)

So now, if you checked out Edgent and have JAVA_HOME set all you need to do, is 
run: 

./mvnw clean install

and it will download the maven version, install it and use it. So you can now 
reduce the requirements to having Java 8 Installed.

One thing I noticed today – as I’m currently setting up my new laptop – is that 
it’s no longer trivial to get a Java 7 JDK. 
I will try to figure out how to setup the toolchain to support building Java 7 
with only Java 8 in the next few days … hopefully it will be as easy as 
defining a java 7 JDK which points to the Java 8 version.

Chris



Am 19.07.17, 11:13 schrieb "Christofer Dutz" :

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.  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 now, I think dealing with the binary release bundle and samples 
are the highest priority / largest unknowns.

Thanks for all your continued diligence!

— Dale

> On Jul 17, 2017, at 2:43 AM, Christofer Dutz 
 wrote:
> 
> 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

Re: What's left to do for Maven migration?

[Christofer Dutz]

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.  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 now, I think dealing with the binary release bundle and samples are 
the highest priority / largest unknowns.

Thanks for all your continued diligence!

— Dale

> On Jul 17, 2017, at 2:43 AM, Christofer Dutz  
wrote:
> 
> 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