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 2018/02/01 10:02:25 UTC
Re: reproducible release process
Hi all,
digging myself out of my PLC4X duties for a little while __
I did take this issue to the Maven users list and there were several suggestions:
1) Don't use the test-jar and copy the resources from a relative path outside the module
2) Live with the test-jars
3) Create a new maven plugin to strip the test-jars out
I did think about option 3 but never mentioned it before as it's challenging to have a maven plugin be part of the build it's used in (Maven absolutely doesn't like this). But I have to agree with Roberts opinion on the list, that this is the cleanest option.
1) Has the drawback of pointing to parts outside a module itself. I have always regretted relying on resources outside a Module whenever I used that. This sort of solution always had the habit of biting you when you at least suspect it.
2) Well we discussed that and it was the overall opinion that we don't want that.
So I implemented a maven plugin to strip out the test-jars and added that in the utils directory but didn't include it in the main reactor. The pom also references the apache-parent directly and is completely separate from the rest of the Edgent build. I also gave it a separate groupId (org.apache.edgent.plugins) and a version number 1.0.0. We would have to release that once as a 1.0.0 and probably never have to touch that again. We would have to do that before the next release as we are not able to release as long as we reference SNAPSHOT versions at all.
I manually deployed the SNAPSHOT of the plugin so you should be fine with building without building the plugin yourself. I also wouldn't suggest setting up a CI job for the plugin itself as this will probably never change.
With this solution the test-jar artifacts are installed in the maven local repo but are never deployed to any remote repo.
Would this option be ok?
Chris
Am 28.01.18, 17:58 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi Dale,
I took the question over to the maven users list. Hopefully they'll come up with a different solution. Still not that comfortable with the deletion (manual or not).
Also I bumped the Apache parent version, as a new version was released a few days ago. Feel free to merge the pull request (just starting to get used to that workflow)
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Dale LaBossiere <dm...@gmail.com>
Sent: Tuesday, January 23, 2018 4:11:32 PM
To: dev@edgent.apache.org
Subject: Re: reproducible release process
Hi Chris,
Regarding EDGENT-440 and the numerous undesired staged artifacts,
When you manually deleted some staged artifacts (presumably via the browser UI?), did you also have to update the metadata files or such?
A while ago you mentioned creating a script/tool to automate this cleanup (in preference to trying to do more pom/config wacking). What were your thoughts on that? Any pointers, etc?
Thanks,
— Dale
> On Jan 16, 2018, at 12:53 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> Sorry für the late response.
> Yes you are correct. Naveen doesn't provide any means for the merging. I did use the simple commands you did without any fast forward. Don't know if Apache's git would have accepted that anyway.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
>
>
> Von: Dale LaBossiere
> Gesendet: Mittwoch, 10. Januar, 19:50
> Betreff: Re: reproducible release process
> An: dev@edgent.apache.org
>
>
> Now that release:perform worked… Assuming the RC vote passes and the nexus staging repository is “closed”... It looks like the maven-release-plugin doesn’t provide any merging of the release to appropriate locations. What were the exact cmds you used to merge the release to master, to create: commit 1832130 Merge tag ‘edgent-1.2.0’ git checkout master git pull # ensure master is up to date git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # did you use —ff-only? should we / not? — Dale
>
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Geee ... creating a testsuite for a maven plugin that has an effect on deployment is ... le's say: Challenging __
But now I think the plugin should have the necessary test-coverage we need :-)
So right now I would treat this task as "TACKLED".
Chris
Am 01.02.18, 11:03 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi all,
digging myself out of my PLC4X duties for a little while __
I did take this issue to the Maven users list and there were several suggestions:
1) Don't use the test-jar and copy the resources from a relative path outside the module
2) Live with the test-jars
3) Create a new maven plugin to strip the test-jars out
I did think about option 3 but never mentioned it before as it's challenging to have a maven plugin be part of the build it's used in (Maven absolutely doesn't like this). But I have to agree with Roberts opinion on the list, that this is the cleanest option.
1) Has the drawback of pointing to parts outside a module itself. I have always regretted relying on resources outside a Module whenever I used that. This sort of solution always had the habit of biting you when you at least suspect it.
2) Well we discussed that and it was the overall opinion that we don't want that.
So I implemented a maven plugin to strip out the test-jars and added that in the utils directory but didn't include it in the main reactor. The pom also references the apache-parent directly and is completely separate from the rest of the Edgent build. I also gave it a separate groupId (org.apache.edgent.plugins) and a version number 1.0.0. We would have to release that once as a 1.0.0 and probably never have to touch that again. We would have to do that before the next release as we are not able to release as long as we reference SNAPSHOT versions at all.
I manually deployed the SNAPSHOT of the plugin so you should be fine with building without building the plugin yourself. I also wouldn't suggest setting up a CI job for the plugin itself as this will probably never change.
With this solution the test-jar artifacts are installed in the maven local repo but are never deployed to any remote repo.
Would this option be ok?
Chris
Am 28.01.18, 17:58 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi Dale,
I took the question over to the maven users list. Hopefully they'll come up with a different solution. Still not that comfortable with the deletion (manual or not).
Also I bumped the Apache parent version, as a new version was released a few days ago. Feel free to merge the pull request (just starting to get used to that workflow)
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Dale LaBossiere <dm...@gmail.com>
Sent: Tuesday, January 23, 2018 4:11:32 PM
To: dev@edgent.apache.org
Subject: Re: reproducible release process
Hi Chris,
Regarding EDGENT-440 and the numerous undesired staged artifacts,
When you manually deleted some staged artifacts (presumably via the browser UI?), did you also have to update the metadata files or such?
A while ago you mentioned creating a script/tool to automate this cleanup (in preference to trying to do more pom/config wacking). What were your thoughts on that? Any pointers, etc?
Thanks,
— Dale
> On Jan 16, 2018, at 12:53 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> Sorry für the late response.
> Yes you are correct. Naveen doesn't provide any means for the merging. I did use the simple commands you did without any fast forward. Don't know if Apache's git would have accepted that anyway.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
>
>
> Von: Dale LaBossiere
> Gesendet: Mittwoch, 10. Januar, 19:50
> Betreff: Re: reproducible release process
> An: dev@edgent.apache.org
>
>
> Now that release:perform worked… Assuming the RC vote passes and the nexus staging repository is “closed”... It looks like the maven-release-plugin doesn’t provide any merging of the release to appropriate locations. What were the exact cmds you used to merge the release to master, to create: commit 1832130 Merge tag ‘edgent-1.2.0’ git checkout master git pull # ensure master is up to date git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # did you use —ff-only? should we / not? — Dale
>