Let’s use Ivy (properly!) and drop Maven Ant tasks + Commons OpenPGP #54
Conversation
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
I don't have any problem with you replacing stuff that works with other stuff that works as well. But before you put too much effort into it, maybe you should look through https://github.com/apache/ant/blob/master/ReleaseInstructions to see what is and what is not used during a release at all. As I've managed a few releases myself let me start by telling you that I have run I have never used As I usually am not an Ivy user I'd prefer my everyday build of Ant to not require me to place Ivy on the CLASSPATH, I'm totally content with not integrating upload with the normal build process as uploading is a very rare exceptional use case only ever performed by a single person. But that's just my preference, YMMV. |
|
I would like to point out one distinction: I would like to replace the stuff that works (sort of) with less stuff that does the same job, and hopefully more. Besides, my beef with Maven Ant tasks was that they morphed into Aether Ant tasks, and then Maven Resolver Ant tasks and changed syntax along the way, and I couldn't add Bintray using Maven Ant tasks (at least not in a trivial way).
The point with I can change |
|
I didn't suggest to remove the As I said, I don't use |
|
BTW, Ivy
I'd rather add another ivy.xml for distributions that would use filesystem resolver to publish signed distributions into the svn repo... svn resolver for Ivy seems a bit of an overkill. |
|
Re password input: isn't there a task with SecureInputHandler for that? |
|
For the changes you plan to introduce to the release process I urge you to not change things just because they look better to you. As it stands I'd be your main user and I'm fine with the process as it is and am completely happy with signing artifacts manually (which happens whenever I cut a release, so twice every few months at best). Our Nexus is going to create extraneous checksums anyway, no matter what Ivy does. Not sure about your second point (I don't declare anything anywhere). You are completely losing me when you talk about the svn resolver, I don't see any reason to use Ivy in order to publish artifacts to dist.apache.org at all. |
|
I am very well aware of your role. I hope we agree about KISS or continuous improvement, though. In particular, regarding the second point, please compare It is my understanding of the release process that distributions are manually copied and checked into Subversion. My point was that the process could be better documented by creating an extra ivy.xml which would be used by upload (or upload-like) process and thus be semi-automated. |
|
Sorry if I sounds bossy here, this is not at all what I'm trying to be. It's more like your user asking you to verify your product improvements are actually improvements for them. :-) I'm certainly not against improvements, neither continuous nor as bigger bangs. TBH I don't really care for the content of a write-once Ivy file much, but that may be just me. Maybe I'm (a bit) old-fashioned, I actually really want to upload files to Nexus and svn manually rather than automate this, as this is the step where I personally verify all artifacts one more time before calling for a vote. We probably should move the upload discussion to the dev list and really focus on the fetch part here. |
|
|
Good idea. Meanwhile, I'd like commit the pkg-distribution target sans python to avoid distraction. |
twogee
changed the title
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
I revised the documentation as suggested and added correct entries for Groovy in the process. |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
twogee
force-pushed
the
dog-food-ivy
branch
2 times, most recently
from
b8e03d9 to
8a546db
Compare
The implementation is incomplete, please comment.
I put the extraneous stuff in
atticsubdirectory for reference.release/upload.xmlcould very well be integrated in build.xml (because ofproject.version).fetch.xmldoes not implement all targets nor updating of Ant distribution(could be done by restricting ivy:resolve to a particular conf). 🎅