| Re: [websocket-dev] Progress towards first release |
I've reached the end of my limited Maven / Jenkins / Eclipse knowledge.
Any idea where to get some help / advice from to move this forward? I
would just copy from one of the other projects I am involved in but they
are all on the new Jenkins infrastructure whereas WebSocket is on an
older Jenkins setup.
Mark
On 24/10/2018 21:14, Mark Thomas wrote:
> Grr.
>
> I just realised that the builds created in Jenkins were hard-coded to
> use Java 8 so the JDK setting was ignored.
>
> I removed the hard-coded JDK only to discover that the build fails with
> Java 6 as at least one of the configured plug-ins requires Java 7.
>
> I've switched the jdk-6 build to jdk-7 for now.
>
> I currently working on the release build as there are still a few jsonp
> references we need to fix.
>
> Mark
>
>
> On 24/10/2018 20:11, Mark Thomas wrote:
>> On 24/10/2018 17:54, Joakim Erdfelt wrote:
>>> On Sat, Oct 20, 2018 at 5:02 AM Mark Thomas <markt@xxxxxxxxxx
>>> <mailto:markt@xxxxxxxxxx>> wrote:
>>
>> <snip/>
>>
>>> My working assumptions are:
>>> - the release will be performed by the Jenkins release job from the
>>> EE4J_8 branch
>>>
>>>
>>> The initial release yes.
>>> The branch name is one of the inputs in the release process.
>>> Future releases will probably be from other branches.
>>
>> Ack.
>>
>>> - it is very preferable to keep master and EE4J_8 in sync
>>>
>>>
>>> Can you explain why you think this is necessary?
>>> After the initial release, I don't envision EE4J_8 having much more
>>> activity.
>>> The future after the initial release will be in a new branch, right?
>>
>> I meant only until we did the first release. My main concern (more for
>> other projects than this) is that any changes in EE4J_8 need to be in
>> master. We don't have that problem.
>>
>> As soon as this first release is out my expectation is that we'll
>> switch to development on master and tag/branch master for the next
>> release.
>>
>>> - CI should test minimum required Java version (6) and latest
>>>
>>>
>>> Unfortunately we don't have much control over the CI environment.
>>> There are a number of Java VM's we can use that are considered "pre
>>> installed".
>>> These are hinted at by Mikaël Barbero in his email to ee4j-build ...
>>> https://www.eclipse.org/lists/ee4j-build/msg00217.html
>>>
>>> The filesystem locations for them are still a mystery to me (currently).
>>> If we have a specific jdk we want to build against, I can track it
>>> down for updating the release scripts.
>>
>> I put in a bugzilla issue and the Eclipse infrastructure folks have
>> added the latest JDKs for Java 6 up to Jenkins. Our builds should be
>> set up to use them.
>>
>>> - changes that alter the API and/or documented behaviour are not
>>> acceptable in this release
>>>
>>> Yeah, that's unfortunate.
>>
>> It would have been nice but I understand the reasoning for this
>> limitation.
>>
>>> - clean-up is desirable but not essential
>>>
>>>
>>> I see general javadoc syntax cleanup being important (as the newer
>>> javadoc doclint is FAR more strict to the W3C HTML 4.01 HTML standard)
>>>
>>> - we need to follow the various Eclipse policies and PMC directives
>>>
>>>
>>> I think we have most of the policies and PMC directives already covered.
>>> The only one I haven't verified is the LICENSE and NOTICE file within
>>> the META-INF directory of the archives.
>>> Can you think of any others we've missed?
>>
>> Nope. I think we are good.
>>
>>> So, on the progress summary.
>>>
>>> Complete for master and EE4J:
>>> - correct min java version
>>> - No automatic module name is defined (NB this requirement might
>>> change)
>>>
>>> Complete for master:
>>> - groupId/artifactId
>>> - required legal docs (NOTICE, LICENSE, CONTIBUTING) are present
>>> - copyright notices updated where required
>>> - CI running and passing for min Java version
>>> - CI running and passing for latest Java version
>>> - CI copyright check passes
>>> - .gitignore has been added
>>> - Fixed Javadoc warnings
>>> - Fixed IDE warnings
>>>
>>> Things we have to do before we can release:
>>> - version is correct (3.0.2-SNAPSHOT) (PR #276)
>>> - latest parent POM (1.0.2) is being used (PR #276)
>>> - CI release build running and passing (PR #276)
>>>
>>> Things that would be nice to have in the release:
>>> - Re-check formatting against provided Eclipse formatter
>>>
>>> In short, we need to apply PR #267 (an approval is required) and
>>> then
>>> merge all the changes from master to EE4J and we should be ready
>>> for the
>>> release.
>>>
>>>
>>> Did you mean https://github.com/eclipse-ee4j/websocket-api/pull/276 ?
>>> If so, it's approved.
>>
>> Thanks. I've applied it.
>>
>>> (we should either fix or remove the travis build on websocket-api, to
>>> get rid of those PR errors)
>>
>> I looked into it. It is failing because the EE4J parent POM is not in
>> Maven Central. I assume that will happen at some point. I'm therefore
>> intending to leave Travis as is for now.
>>
>> I have just created PR #277. That applies every change made on master
>> to EE4J_8. Once that is approved and applied I think we will be ready
>> to release.
>>
>> Mark
>> _______________________________________________
>> websocket-dev mailing list
>> websocket-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/websocket-dev
> _______________________________________________
> websocket-dev mailing list
> websocket-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/websocket-dev
_______________________________________________
websocket-dev mailing list
websocket-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/websocket-dev