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" <christofer.d...@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" <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
        >
        
        
    
    

Reply via email to