One thing to be wary of - Most, if not all, of the other Commons projects are not multi-module projects. I remember specifically having to do “interesting” things in the VFS pom to fix things that didn’t work correctly in commons-parent. I am sure over the course of time a lot of that has changed. But you will probably have some trial and error, which is why I would build first by manually activating the profiles and not starting with the release plugin as it is much easier to just blow away the target directory and start over than it is to revert stuff from scm.
Ralph > On Apr 27, 2016, at 8:31 AM, Josh Elser <josh.el...@gmail.com> wrote: > > Thanks, Sebb and Ralph. > > I can dig through the parent poms. I wouldn't have initially realized that > there was a "commons" parent pom. Thanks for pointing that out. > > sebb wrote: >> On 27 April 2016 at 05:58, Ralph Goers<ralph.go...@dslextreme.com> wrote: >>> As I recall, I performed the VFS 2.0 release. I did use the Maven release >>> plugin. It has been so long that I have forgotten the details of what had >>> to be done, but I know I ended up using it as the model for setting up >>> Log4j 2’s build. >>> >>> As I recall I would sort of test “pre-releasing” by running a build with -P >>> apache-release as that profile enables a bunch of stuff in the ASF parent >>> pom. >> >> Commons Parent has a -P release profile which is different. >> I'm not sure CP works all that well with apache-release which does not >> support everything we expect. >> >> You can use -Ptest-deploy to change the deploy target to target/deploy >> and compare the two. >> >> You may need to use 'mvn package deploy' rather than plain 'mvn >> deploy' if the VFS pom creates any jars in the package phase. >> >>> Ralph >>> >>>> On Apr 26, 2016, at 3:27 PM, Bernd Eckenfels<e...@zusammenkunft.net> >>>> wrote: >>>> >>>> Hello, >>>> >>>> see inline. >>>> >>>> Am Tue, 26 Apr 2016 18:05:01 -0400 >>>> schrieb Josh Elser<els...@apache.org<mailto:els...@apache.org>>: >>>> >>>>> Thanks for the great details, Bernd. Some questions/comments: >>>>> >>>>> I hadn't even stumbled across VFS-570 due to its lack of >>>>> fixVersion=2.1. Are there more that need to be correctly tagged which >>>>> could potentially block the release of 2.1? >>>> I did not waste much time in setting/unsetting the fixversion. I >>>> modified some severities and closed some. But the blocker bugs (the >>>> ones I considered) are all closed. >>>> >>>> You could do a mass change on the existing bugs, but I am sure that >>>> causes some discussion and especially people setting the fields back to >>>> their preferences (at least that happend a few times in the past). >>>> >>>>> I'm not sure I follow you about the concern of using >>>>> maven-release-plugin with a multi-module maven project. This works >>>>> just fine (@see other Apache maven projects I'm involved in). If >>>>> there are demons laying in wait, I can knock them out as I find them. >>>> Well yes, I use the release plugin aswell (in fact I did a company >>>> internal release of VFS 2.1 with it already). I think it was also used >>>> for the 2.0 release. But there are some things (especially the tagging >>>> of the SVN and the tag in the POM) which is currently not very >>>> preferable in apache commons I think. I would not use it for a release >>>> (especially as rolling back and revovering would be painful). But I >>>> agreee with you, it should work. >>>> >>>>> Are there instructions on running clirr? I'm not familiar with the >>>>> tool (and I don't see any configuration in the top-level pom.xml). >>>> You can run the "mvn -Psandbox clean site" build (possibly follwoed by >>>> a site tst deploy). The clirr report is part of it. I had a site build >>>> from the snapshot on people.apache.org<http://people.apache.org/>, but I >>>> havent checked if/how the >>>> new server would look like. So currently you need to run it locally. >>>> >>>>> Do you have the karma to make a 2.2 version on JIRA? That'd be a nice >>>>> help to start moving stuff out of 2.1 (as well as make sure things >>>>> sitting in Patch Available don't get forgotten). >>>> Yes, seems like I can do it. I created 2.2. >>>> >>>>> I would lean towards >>>>> the side of only putting bug-fixes into a 2.1.1 and preferring >>>>> towards any new features/changes into a 2.2 (to closer follow the >>>>> definition of semver). We presently have 3 major and 1 minor version >>>>> unresolved for fixVersion=2.1 -- these where the issues I previously >>>>> referred to that I felt OK bumping out as well. >>>>> Gary -- "BC breakage" == base-class breakage? As in: the common >>>>> base-class for all of the VFS Providers has changed (and would >>>>> require changes from anyone downstream that has built their own)? >>>> It refers to (binary) backward compatibility. For a client a new method >>>> in an interface is a compatible change which fits into a minor update. >>>> However when you have to implement a interface as a VFS provider you >>>> wont be binary and source compatible. For most classes it is not a >>>> problem since the mehtod is provided by the AbstractBaseClass for an >>>> interface (but not all Interfaces have that and it was never mandatory >>>> for an provider to use them). >>>> >>>>> I can try to start pounding on an initial RC in the evenings this >>>>> week. I'll be sure to reach out as I need some more help/karma ;) >>>> Anything more needed from me? >>>> >>>> Gruss >>>> Bernd >>>> >>>> >>>>> Gary Gregory wrote: >>>>>> Yes, there is a BC breakage for providers, is that grounds for a >>>>>> package and Maven coordinate rename to vfs3? >>>>>> >>>>>> Gary >>>>>> >>>>>> On Tue, Apr 26, 2016 at 12:31 PM, Bernd >>>>>> Eckenfels<e...@zusammenkunft.net> wrote: >>>>>> >>>>>>> Hello Josh, >>>>>>> >>>>>>> I think a VFS 2.1 release would be cool and it is good that you >>>>>>> volunteer, so I dont object. My latest todo list is here: >>>>>>> >>>>>>> https://wiki.apache.org/commons/VfsReleaseState >>>>>>> >>>>>>> As you can see, I did plan to do the release and did quite some >>>>>>> work to get VFS into a releaseable state. But I am quite happy >>>>>>> that you want to step in as I havent had the time to do the >>>>>>> procedure yet. >>>>>>> >>>>>>> And this is not the actual release procedure (which should be >>>>>>> doable as long as you do not try to use the release-plugin and be >>>>>>> careful about the multi-module+sandbox nature of VFS (as opposed >>>>>>> to other commons projects)). Also be carefull about branch and tag >>>>>>> namings (the SVN is a bit messy in this regard). >>>>>>> >>>>>>> My main concern I am afraid I would not have enough capacity is >>>>>>> because of the Clirr report and a lot of partially incompatible >>>>>>> changes. Most of them only affect providers if they do not >>>>>>> properly use abstract base classes, but still the list of Clirr >>>>>>> violations is long and developers here have not yet voiced if they >>>>>>> would accept a RC with this situation (or not). >>>>>>> >>>>>>> Anyway, I do agree that the current critical and blocker bugs are >>>>>>> important but should not stop the 2.1 release (especially if a >>>>>>> 2.1.1 release aferwards is much faster to do.) It would be cool to >>>>>>> have VFS-570 (write suport for VFS, but even that could be >>>>>>> delivered with 2.1.1 - it might annoy the HDFS folks a bit) >>>>>>> >>>>>>> So I can help you in case you need me to sponsor some changes (I >>>>>>> hope I have enough karma now). >>>>>>> >>>>>>> We could even make a joined RC1, I am just not sure it wont open a >>>>>>> big chunk of additional work. >>>>>>> >>>>>>> Gruss >>>>>>> Bernd >>>>>>> >>>>>>> Am Tue, 26 Apr 2016 09:40:01 -0400 >>>>>>> schrieb Josh Elser<els...@apache.org>: >>>>>>> >>>>>>>> Thanks Matt and Gary. >>>>>>>> >>>>>>>> I do recall seeing the asf-wide note that my commit-bit also >>>>>>>> applies to commons-*. Thanks for bringing that up. Specifically >>>>>>>> though, I am only interested in cutting a release -- if we can >>>>>>>> get a new release cut that we can use downstream, that increases >>>>>>>> the likelihood that I will have more things to contribute back :) >>>>>>>> >>>>>>>> I'll pull up the thread in the archives and get back to ya'll with >>>>>>>> any questions I have after that. >>>>>>>> >>>>>>>> - Josh >>>>>>>> >>>>>>>> Matt Sicker wrote: >>>>>>>>> It's from the thread called "Whatever happened to commons-io >>>>>>>>> 2.5?" A few people stepped up to give the necessary permissions >>>>>>>>> and committed his GPG key. >>>>>>>>> >>>>>>>>> On 25 April 2016 at 17:10, Gary Gregory<garydgreg...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Agreed, VFS 2.1 has been too long in the making. We can release >>>>>>>>>> ASAP without fixing more bugs IMO. RERO and all. >>>>>>>>>> >>>>>>>>>> As an Apache committer, your are also an Apache Commons >>>>>>>>>> committer, so feel free to create JIRAs, fix bugs and so on. >>>>>>>>>> >>>>>>>>>> There might be some karma issues with a non-PMC member >>>>>>>>>> performing a release, and I think we just went through this >>>>>>>>>> (sorry, I'm in settling in a new house, not much time to dig in >>>>>>>>>> the ML archives). >>>>>>>>>> >>>>>>>>>> Does anyone recall? >>>>>>>>>> >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<els...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> There are presently 171 resolved issues sitting in commons-vfs2 >>>>>>>>>>> 2.1-SNAPSHOT, with 4 outstanding (none of which look like >>>>>>>>>>> blockers to >>>>>>>>>> me). >>>>>>>>>>> The lack of any release of commons-vfs2 in years has been a big >>>>>>>>>>> problem downstream. This past weekend, I was again annoyed by >>>>>>>>>>> bugs that have been fixed (but not release) which is spurring >>>>>>>>>>> me to take some action. There have been emails reaching back >>>>>>>>>>> as far as 2014 asking when the next >>>>>>>>>> release >>>>>>>>>>> might be, not to mention the fact that vfs-2.0 was released in >>>>>>>>>>> 2011 (!). >>>>>>>>>>> >>>>>>>>>>> History aside, I'm reaching out today to: >>>>>>>>>>> >>>>>>>>>>> 1) See if anyone on the PMC has the cycles to volunteer as RM. >>>>>>>>>>> 1a) If not, how can you empower me (or others) to make the >>>>>>>>>>> release on your behalf. >>>>>>>>>>> 2) Understand, specifically, what (if any) roadblocks exist to >>>>>>>>>>> release this version. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> - Josh >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>> <http://www.manning.com/bauer3/> >>>>>>>>>> JUnit in Action, Second >>>>>>>>>> Edition<http://www.manning.com/tahchiev/> Spring Batch in >>>>>>>>>> Action<http://www.manning.com/templier/> Blog: >>>>>>>>>> http://garygregory.wordpress.com Home: http://garygregory.com/ >>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: >>>> dev-unsubscr...@commons.apache.org<mailto:dev-unsubscr...@commons.apache.org> >>>> For additional commands, e-mail: >>>> dev-h...@commons.apache.org<mailto:dev-h...@commons.apache.org> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
