[GitHub] maven-enforcer pull request #24: MENFORCER-274 : Add check for version 9 in ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/maven-enforcer/pull/24


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Migration of remaining plugins to Git

[Paul Hammant]

So the alternate strategy (to what I tested 11 hrs ago) would be to change
the release plugin so that it can do its work on a sub-directory safely.

   cd 
   cd maven-changes-plugin
   mvn release:prepare
   mvn release:perform

We note after the event that the release was* tagged in SCM with something
strong like 'maven-changes-plugin-3.0.0'*.

We also silently lament that Git doesn't have branch mappings like
Perforce. Indeed, just one small aspect of branch mapping - the ability to
remove sections of the tree in the branch and* maintain that divergence
going forwards*. Of course tags are not branches, but you know what I
mean.  In Git given it's content based storage, there's no storage
downsides from a branch/tag for 'maven-changes-plugin-3.0.0' also
containing all other plugins. Well no storage downsides ignoring working
copy (the checkout).

- Paul

On Tue, Jun 27, 2017 at 8:14 PM, Paul Hammant  wrote:

> OK, I tried something new.
>
> *Goal*: all the plugins in one Git repo (less CI jobs to set up - just
> one recursive multi-module maven build).
> *Constraint*: Plugins must be independently releasable.
>
> *Test:* Take two modules from the Svn repo and check them in to master
> (the rest were deleted - test needs two and a parent pom in master).
>
> *Repository*: https://github.com/paul-hammant/ph_testplugins
>
> Of the two modules checked in, maven-changes-plugin is the one I attempted
> to release to my com/paulhammant/ group on 'Central. The workflow for the
> release of that single module is here https://github.com/paul-
> hammant/ph_testplugins/blob/master/CHANGES_PLUGIN_RELEASE_WORKFLOW.md
>
> *Result of Test:* failed, but in a surprising way and at a very late stage
>
> During the release:perform stage the maven tried to push to
> https://oss.sonatype.org/content/repositories/snapshots
> /com/paulhammant/testplugins-ph-chgs-pi/3.0.0-SNAPSHOT/
> testplugins-ph-chgs-pi-3.0.0-20170627.234743-1.jar which is nuts because
> I'm not trying to push to a SNAPSHOT, I'm trying to do a proper release of
> 3.0.0 (of my renamed to an obscure name plugin).
>
> The documentation for the  part of the pom says that it honors the
> name of the local branch for the sequence of commits that the release
> plugin does. Which is exactly what you'd want. I've already tested it a
> dozen times and it does the right thing by way of tags too.  It's only that
> SNAPSHOT weirdness during the upload that ends the experiment, and that's a
> fairly late stage piece. My plan was to go onto oss.sonatype.org and
> delete it from staging so it would ultimately go nowhere.
>
> Barring that bug, this would work for all of the Maven plugins in a single
> repo, meaning a lot less permutations for CI, albeit with a longer build
> per commit. I don't think that last is a big issue for this proposed
> repository.
>
> Any of you could clone the repo I have made, and do the same steps as
> CHANGES_PLUGIN_RELEASE_WORKFLOW.md document to get to the same place I
> got to (a 401 error from Sonatype's DAV infra). And one of you could tell
> me what I did wrong with the setup to encounter that snapshot issue :)
>
> - Paul
>
>
>
>
>

Fwd: [JENKINS] [IMPORTANT] - Jenkins Migration and Upgrade (And JDK7 deprecation)

[Anders Hammar]

See info below.
It looks as we're on the Maven project build type for some builds so that
this will affect us wrt JDK7 deprecation.

/Anders

-- Forwarded message --
From: Gavin McDonald 
Date: Tue, Jun 27, 2017 at 9:03 AM
Subject: [JENKINS] [IMPORTANT] - Jenkins Migration and Upgrade (And JDK7
deprecation)
To: bui...@apache.org
Cc: ASF Operations 


ASF Jenkins Master Migration and Upgrade on :-


LocationLocal Time
Time Zone   UTC Offset
Melbourne (Australia - Victoria)Sunday, 16 July 2017 at 10:00:00
am AESTUTC+10 hours
New York (USA - New York)   Saturday, 15 July 2017 at 8:00:00
pmEDT UTC-4 hours
Corresponding UTC (GMT) Sunday, 16 July 2017 at 00:00:00


Hi All,

A few things are going to happen in just over 2 weeks.

1. Migration of Jenkins to a new host. A Jenkins Master module and yaml
have been puppetized and ready to go.
What we need to do to migrate the Master away from its current host is
turn off the old service. Perform a final
rsync of data and perform the migration tasks.

As we intend to preserve history for jobs this will take some time.
At the same time as doing this migration to a new host, all slave
connections will be updated (see below.)
I have no current estimate of downtime, but it will run into several
hours. We do plan to run this migration on a
Sunday at the lowest part of Jenkins usual usage.

2. Upgrade of Jenkins - Jenkins project released a new LTS release, version
2.60.1. This is a major release and breaks
Jenkins in terms of Maven jobs for JDK 7 in the same way that it
happened for Maven and JDK 6 a few months back.

The infra team (mainly myself) got quite some feedback on not supplying
advance notice of this breakage. That upgrade
however was necessary due to security fixes that required our upgrade.
This email serves as advance warning of the
upcoming upgrade of Jenkins, the downtime due to the migration of the
service to a new host; and notice of the breakage
to JDK 7 that the upgrade brings.

Please familiarise yourself with the Jenkins LTS upgrade notes at [1].
In particular please note:-

“…2.60.1 is the first Jenkins LTS release that requires Java 8 to run.
If you're using the Maven Project type, please note that it needs to use a
JDK capable of running Jenkins, i.e. JDK 8 or up. If you configure an older
JDK in a Maven Project, Jenkins will attempt to find a newer JDK and use
that automatically. If your SSH Slaves fail to start and you have the
plugin install the JRE to run them, make sure to update SSH Slaves Plugin
to at least version 1.17 (1.20 recommended).
Changes since 2.60:
Fix for NullPointerException while initiating some SSH connections
(regression in 2.59). (issue 44120 )
Notable changes since 2.46.3:
Jenkins (master and agents) now requires Java 8 to run. (issue 27624 <
https://issues.jenkins-ci.org/browse/JENKINS-27624> <>, issue 42709 <
https://issues.jenkins-ci.org/browse/JENKINS-42709> <>, pull 2802 <
https://github.com/jenkinsci/jenkins/pull/2802>, announcement blog post <
https://jenkins.io/blog/2017/04/10/jenkins-has-upgraded-to-java-8/>)

…”

There are over 30 other enhancements/fixes since 2.46.2 which we currently
run so please do take a note of those.

Recap: In just over 2 weeks, downtime for a migration AND upgrade is
planned.

Please do not rely on Jenkins at all for that weekend if you use it in your
release workflow.

Please do take this notice back to your dev lists.

Any questions or concerns please email back to bui...@apache.org  only.

Thanks

Gav…

[1] - https://jenkins.io/changelog-stable/

[GitHub] maven-enforcer pull request #24: MENFORCER-274 : Add check for version 9 in ...

[ansell]

GitHub user ansell opened a pull request:

https://github.com/apache/maven-enforcer/pull/24

MENFORCER-274 : Add check for version 9 in RequireJavaVersion

Adds an explicit regression check for Java-9 in the RequireJavaVersion test.

Note, the test already succeeds, this is just ensuring that it will keep 
succeeding in future.

Signed-off-by: Peter Ansell 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ansell/maven-enforcer MENFORCER-274

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-enforcer/pull/24.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #24


commit 096c2e42169b7f5375fb1b73d6cbf9d987b21bf5
Author: Peter Ansell 
Date:   2017-06-28T06:46:45Z

MENFORCER-274 : Add check for version 9 in RequireJavaVersion

Signed-off-by: Peter Ansell 




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org