edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: reproducible release process
Date Thu, 01 Feb 2018 16:10:25 GMT
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".


Am 01.02.18, 11:03 schrieb "Christofer Dutz" <christofer.dutz@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
    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?
    Am 28.01.18, 17:58 schrieb "Christofer Dutz" <christofer.dutz@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)
        Outlook for Android<https://aka.ms/ghei36> herunterladen
        From: Dale LaBossiere <dml.apache@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,
        — Dale
        > On Jan 16, 2018, at 12:53 AM, Christofer Dutz <christofer.dutz@c-ware.de>
        > 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

View raw message