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 10:02:25 GMT
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" <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)
    
    Chris
    
    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,
etc?
    
    Thanks,
    — Dale
    
    > On Jan 16, 2018, at 12:53 AM, Christofer Dutz <christofer.dutz@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
    >
    
    

Mime
View raw message