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