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" <dml.apa...@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 <christofer.d...@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" <dml.apa...@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 <christofer.d...@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" <christofer.d...@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"
<christofer.d...@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"
<dml.apa...@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
<christofer.d...@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
>>
>>
>>
>>
>>
>>
>>
>
>
>
