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