Re: [VOTE] Release Apache Portals Pluto 3.0.1
Neil Griffin <[email protected]> Mon, 14 May 2018 18:27:28 -0400
| Newsgroups | gmane.comp.jakarta.pluto.devel,gmane.comp.jakarta.pluto.user |
|---|---|
| Message-ID | <[email protected]> |
Hi Woonsan,
I tried adding this to portals-pluto/pom.xml and it didn't work:
<profile>
<id>apache-release</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot>
</configuration>
</plugin>
</plugins>
</build>
</profile>
I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't work.
In other words, when I run the release procedure from the top (portals-pluto/) the maven-assembly-plugin will only generate a "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else.
Since that the only source-release ZIP that has been released in the past, shouldn't that be adequate for this 3.0.1 release?
Thank you,
Neil
On 5/14/18 4:51 PM, Neil Griffin wrote:
> Hi Woonsan,
>
> Thank you for your efforts to make sure the release process is correct.
>
> 1) Regarding the "source-release" bundles:
>
> I *think* I found the problem as to why they are missing -- it is likely due to the following config of the maven-assembly-plugin in the apache-16 parent-most pom descriptor:
>
> <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>
> See: https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom
>
> Since we ran the Maven release plugin from the portals-pluto root, none of the jars like pluto-container-api.jar, etc. had the companion "source-release" bundle.
>
> The reason why the archetypes worked, is because I released them individually from their respective "root" directories.
>
> BTW, as far as I can determine, the "source-release" problem is not new. It has been there for many years. For example, see:
> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22
>
> Anyway, I'll fix it before re-releasing.
>
> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits* for the vote, but _not_ the *tags* until the vote was final. That worked well because he actually had to roll-back the release. I recommend we do it that way again.
>
>
> -- Neil
>
> On 5/14/18 11:53 AM, Woonsan Ko wrote:
>> By the way, I'm not trying to block the way. ;-) I'm just trying to
>> make a right release (process) this time.
>> Please let me know if I can help with anything. I'll help to fix the
>> (minimal) things to make a release as soon as possible. :-)
>>
>> Regards,
>>
>> Woonsan
>>
>>
>> On Mon, May 14, 2018 at 11:39 AM, Woonsan Ko <[email protected]> wrote:
>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>> <[email protected]> wrote:
>>>> Hi Woonsan,
>>>>
>>>> We followed the same process as we did for the 3.0.0 release.
>>>>
>>>> The "building from source" requirement would be accomplished by building
>>>> source from a Git tag.
>>>
>>> I don't think a Git tag can replace the requirement of a "valid
>>> release package".
>>> Pluto 3.0.0 release also contains a valid release package:
>>> - https://dist.apache.org/repos/dist/release/portals/pluto/pluto-3.0.0-source-release.zip
>>>
>>> From this voting email, I want to check if the release source package
>>> is valid as an Apache release.
>>> I cannot find the candidate source package we want to release. There
>>> are binary links only in your voting e-mail for the Pluto 3.0.1.
>>> What's the point of this voting if I cannot verify the candidate
>>> source packages by building, unit-testing, checking signatures,
>>> checking license headers, ...?
>>> Please give me the links to download all the *source packages* as
>>> release candidate this time, which I can build, test, verify things.
>>> Otherwise, I cannot proceed.
>>>
>>>>
>>>> However, the Git commits and tags have not been pushed to the Git repository
>>>> yet, because of the following line:
>>>> https://github.com/apache/portals-pluto/blob/master/pom.xml#L649
>>>>
>>>> This was intentional, because it would allow us to roll back the release
>>>> process if the voting process were to fail.
>>>
>>> That might be okay, but again please upload the source packages you
>>> built and staged somewhere. I cannot verify nor vote against binaries.
>>>
>>> If possible, I recommend you to upload to
>>> https://dist.apache.org/repos/dist/dev/portals/pluto/... for voting,
>>> and later move to /release/ folder after voting passed.
>>> The source packages for which we vote should become the actual
>>> releases in the end if vote passed. Neither files you have locally nor
>>> a git tag.
>>>
>>>>
>>>> This approach also mirrors the concept of the "staging" repository which
>>>> will not be released to Maven Central if the voting process were to fail.
>>>
>>> Another approach is just to bump up the version to 3.0.2 if 3.0.1
>>> voting failed and so 3.0.1 tag is not for a release. I don't see any
>>> problem by having 3.0.1 tag exists as long as it's not published to
>>> both maven repository and distribution site.
>>>
>>>>
>>>> I can provide evidence of the tags and git commits in my local Git
>>>> repository if that would help.
>>>
>>> Git commits or local files cannot help in our release voting and process, IMO.
>>> It's better and safer to upload all the source packages and let people
>>> verify them before casting a vote.
>>>
>>> Regards,
>>>
>>> Woonsan
>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Neil
>>>>
>>>>
>>>> On 5/14/18 10:29 AM, Woonsan Ko wrote:
>>>>>
>>>>> -1
>>>>>
>>>>> I couldn't find pluto-3.0.1 tag in
>>>>> https://git-wip-us.apache.org/repos/asf/portals-pluto.git. I wonder
>>>>> how the release candidate artifacts were made. The master branch's
>>>>> version was not bumped up to 3.0.2-SNAPSHOT either.
>>>>> Even worse, there's a stopper in the root pom.xml [1]:
>>>>>
>>>>> <profile>
>>>>> <id>liferay</id>
>>>>> <dependencyManagement>
>>>>> <dependencies>
>>>>> <dependency>
>>>>> <groupId>com.liferay.portal</groupId>
>>>>>
>>>>> <artifactId>com.liferay.cdi.bean.portlet.extension</artifactId>
>>>>> <version>1.0.0-SNAPSHOT</version>
>>>>> </dependency>
>>>>> </dependencies>
>>>>> </dependencyManagement>
>>>>> <repositories>
>>>>> <repository>
>>>>> <id>liferay-snapshots</id>
>>>>> <name>Liferay Snapshots</name>
>>>>>
>>>>> <url>https://oss.sonatype.org/content/repositories/snapshots</url>
>>>>> <releases>
>>>>> <enabled>false</enabled>
>>>>> </releases>
>>>>> <snapshots>
>>>>> <enabled>true</enabled>
>>>>> </snapshots>
>>>>> </repository>
>>>>> </repositories>
>>>>> </profile>
>>>>>
>>>>> Releases must not depend on a SNAPSHOT dependency. And the
>>>>> com.liferay.cdi.bean.portlet.extension artifact has no clear copyright
>>>>> notice. So this is not acceptable.
>>>>> If the 'liferay' profile is necessary for Liferay specific TCK
>>>>> testing, I'd recommend you to move it out to a special documentation
>>>>> explaining how to run Liferay specific TCK testing by configuring
>>>>> those in user's settings.xml instead, not in the source distribution.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Woonsan
>>>>>
>>>>> [1]
>>>>> https://git-wip-us.apache.org/repos/asf?p=portals-pluto.git;a=blob;f=pom.xml;h=1fb14997be03c4911ce97ebf0826f59f599a2198;hb=HEAD#l739
>>>>>
>>>>>
>>>>> On Fri, May 11, 2018 at 3:06 PM, Neil Griffin
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> Dear Apache Portals Pluto Team and community,
>>>>>>
>>>>>> I've staged a release candidate for the new Apache Portals Pluto 3.0.1
>>>>>> release.
>>>>>>
>>>>>> This release candidate includes:
>>>>>>
>>>>>> * Fully compliant Reference Implementation of the new Portlet 3.0
>>>>>> Specification per JCR-362
>>>>>> https://www.jcp.org/en/jsr/detail?id=362
>>>>>> * Fully completed (and corrected) TCK (Test Compatibility Kit) for
>>>>>> Portlet
>>>>>> Spec 3.0
>>>>>> * Updated portlet-api with associated Javadoc improvements
>>>>>> * General bugfixes
>>>>>> * Updated archetypes
>>>>>>
>>>>>> Please review the release candidate for this project which is spread
>>>>>> across the following THREE maven staging repositories:
>>>>>>
>>>>>> 1) portlet-api and pluto-portal components and dependencies:
>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1018
>>>>>>
>>>>>> 2) pluto+tomcat bundle:
>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1019
>>>>>>
>>>>>> (The bundle can be tested by unzipping it,
>>>>>> and running start.sh from the bin directory,
>>>>>> then navigating to http://localhost:8080/pluto
>>>>>> and login as pluto/pluto.)
>>>>>>
>>>>>> 3) maven archetypes:
>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1020
>>>>>>
>>>>>> The Release Notes are available here:
>>>>>>
>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10560&version=12338908
>>>>>>
>>>>>> The KEYS file to verify the release artifacts signature can be found
>>>>>> here:
>>>>>>
>>>>>> https://dist.apache.org/repos/dist/release/portals/pluto/KEYS
>>>>>>
>>>>>> Please review the release candidates and vote on releasing Apache Portals
>>>>>> Pluto 3.0.1
>>>>>>
>>>>>> Seeing as how I am sending this on a Friday, the normal vote of 72 hours
>>>>>> seems unreasonable. Therefore I would like to extend the vote to 96
>>>>>> hours.
>>>>>>
>>>>>> Please cast your vote:
>>>>>>
>>>>>> [ ] +1 for Release
>>>>>> [ ] 0 for Don't care
>>>>>> [ ] -1 Don't release (do provide a reason then)
>>>>>>
>>>>>>
>>>>>> Best Regards to all,
>>>>>>
>>>>>> Neil
>>>>>
>>>>>
>>>>
>>>
>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>> <[email protected]> wrote:
>>>> Hi Woonsan,
>>>>
>>>> We followed the same process as we did for the 3.0.0 release.
>>>>
>>>> The "building from source" requirement would be accomplished by building
>>>> source from a Git tag.
>>>>
>>>> However, the Git commits and tags have not been pushed to the Git repository
>>>> yet, because of the following line:
>>>> https://github.com/apache/portals-pluto/blob/master/pom.xml#L649
>>>>
>>>> This was intentional, because it would allow us to roll back the release
>>>> process if the voting process were to fail.
>>>>
>>>> This approach also mirrors the concept of the "staging" repository which
>>>> will not be released to Maven Central if the voting process were to fail.
>>>>
>>>> I can provide evidence of the tags and git commits in my local Git
>>>> repository if that would help.
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Neil
>>>>
>>>>
>>>> On 5/14/18 10:29 AM, Woonsan Ko wrote:
>>>>>
>>>>> -1
>>>>>
>>>>> I couldn't find pluto-3.0.1 tag in
>>>>> https://git-wip-us.apache.org/repos/asf/portals-pluto.git. I wonder
>>>>> how the release candidate artifacts were made. The master branch's
>>>>> version was not bumped up to 3.0.2-SNAPSHOT either.
>>>>> Even worse, there's a stopper in the root pom.xml [1]:
>>>>>
>>>>> <profile>
>>>>> <id>liferay</id>
>>>>> <dependencyManagement>
>>>>> <dependencies>
>>>>> <dependency>
>>>>> <groupId>com.liferay.portal</groupId>
>>>>>
>>>>> <artifactId>com.liferay.cdi.bean.portlet.extension</artifactId>
>>>>> <version>1.0.0-SNAPSHOT</version>
>>>>> </dependency>
>>>>> </dependencies>
>>>>> </dependencyManagement>
>>>>> <repositories>
>>>>> <repository>
>>>>> <id>liferay-snapshots</id>
>>>>> <name>Liferay Snapshots</name>
>>>>>
>>>>> <url>https://oss.sonatype.org/content/repositories/snapshots</url>
>>>>> <releases>
>>>>> <enabled>false</enabled>
>>>>> </releases>
>>>>> <snapshots>
>>>>> <enabled>true</enabled>
>>>>> </snapshots>
>>>>> </repository>
>>>>> </repositories>
>>>>> </profile>
>>>>>
>>>>> Releases must not depend on a SNAPSHOT dependency. And the
>>>>> com.liferay.cdi.bean.portlet.extension artifact has no clear copyright
>>>>> notice. So this is not acceptable.
>>>>> If the 'liferay' profile is necessary for Liferay specific TCK
>>>>> testing, I'd recommend you to move it out to a special documentation
>>>>> explaining how to run Liferay specific TCK testing by configuring
>>>>> those in user's settings.xml instead, not in the source distribution.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Woonsan
>>>>>
>>>>> [1]
>>>>> https://git-wip-us.apache.org/repos/asf?p=portals-pluto.git;a=blob;f=pom.xml;h=1fb14997be03c4911ce97ebf0826f59f599a2198;hb=HEAD#l739
>>>>>
>>>>>
>>>>> On Fri, May 11, 2018 at 3:06 PM, Neil Griffin
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> Dear Apache Portals Pluto Team and community,
>>>>>>
>>>>>> I've staged a release candidate for the new Apache Portals Pluto 3.0.1
>>>>>> release.
>>>>>>
>>>>>> This release candidate includes:
>>>>>>
>>>>>> * Fully compliant Reference Implementation of the new Portlet 3.0
>>>>>> Specification per JCR-362
>>>>>> https://www.jcp.org/en/jsr/detail?id=362
>>>>>> * Fully completed (and corrected) TCK (Test Compatibility Kit) for
>>>>>> Portlet
>>>>>> Spec 3.0
>>>>>> * Updated portlet-api with associated Javadoc improvements
>>>>>> * General bugfixes
>>>>>> * Updated archetypes
>>>>>>
>>>>>> Please review the release candidate for this project which is spread
>>>>>> across the following THREE maven staging repositories:
>>>>>>
>>>>>> 1) portlet-api and pluto-portal components and dependencies:
>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1018
>>>>>>
>>>>>> 2) pluto+tomcat bundle:
>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1019
>>>>>>
>>>>>> (The bundle can be tested by unzipping it,
>>>>>> and running start.sh from the bin directory,
>>>>>> then navigating to http://localhost:8080/pluto
>>>>>> and login as pluto/pluto.)
>>>>>>
>>>>>> 3) maven archetypes:
>>>>>> https://repository.apache.org/content/repositories/orgapacheportals-1020
>>>>>>
>>>>>> The Release Notes are available here:
>>>>>>
>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10560&version=12338908
>>>>>>
>>>>>> The KEYS file to verify the release artifacts signature can be found
>>>>>> here:
>>>>>>
>>>>>> https://dist.apache.org/repos/dist/release/portals/pluto/KEYS
>>>>>>
>>>>>> Please review the release candidates and vote on releasing Apache Portals
>>>>>> Pluto 3.0.1
>>>>>>
>>>>>> Seeing as how I am sending this on a Friday, the normal vote of 72 hours
>>>>>> seems unreasonable. Therefore I would like to extend the vote to 96
>>>>>> hours.
>>>>>>
>>>>>> Please cast your vote:
>>>>>>
>>>>>> [ ] +1 for Release
>>>>>> [ ] 0 for Don't care
>>>>>> [ ] -1 Don't release (do provide a reason then)
>>>>>>
>>>>>>
>>>>>> Best Regards to all,
>>>>>>
>>>>>> Neil
>>>>>
>>>>>
>>>>
>>