You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@edgent.apache.org by Christofer Dutz <ch...@c-ware.de> on 2017/07/17 06:43:32 UTC
What's left to do for Maven migration?
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?
Posted by Dale LaBossiere <dm...@gmail.com>.
Sounds reasonable. Thanks!
— Dale
> On Aug 9, 2017, at 2:55 AM, Christofer Dutz <ch...@c-ware.de> 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" <dm...@gmail.com>:
>
> 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 <ch...@c-ware.de> 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" <dm...@gmail.com>:
>>
>> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>>
>>> 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" <ch...@c-ware.de>:
>>>
>>> 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" <dm...@gmail.com>:
>>>
>>> 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 <ch...@c-ware.de> 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?
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <dm...@gmail.com>:
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 <ch...@c-ware.de> 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" <dm...@gmail.com>:
>
> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>
>> 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" <ch...@c-ware.de>:
>>
>> 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" <dm...@gmail.com>:
>>
>> 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 <ch...@c-ware.de> 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?
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@c-ware.de> 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" <dm...@gmail.com>:
>
> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>
>> 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" <ch...@c-ware.de>:
>>
>> 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" <dm...@gmail.com>:
>>
>> 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 <ch...@c-ware.de> 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?
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <dm...@gmail.com>:
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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>
> 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" <ch...@c-ware.de>:
>
> 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" <dm...@gmail.com>:
>
> 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 <ch...@c-ware.de> 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?
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>
> 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" <ch...@c-ware.de>:
>
> 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" <dm...@gmail.com>:
>
> 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 <ch...@c-ware.de> 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?
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ch...@c-ware.de>:
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" <ch...@c-ware.de>:
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" <dm...@gmail.com>:
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 <ch...@c-ware.de> 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?
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ch...@c-ware.de>:
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" <dm...@gmail.com>:
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 <ch...@c-ware.de> 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?
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <dm...@gmail.com>:
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 <ch...@c-ware.de> 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?
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@c-ware.de> 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