Re: [maven-scm-api] Looking to perform svn remote move

[Hervé BOUTEMY]

Le vendredi 18 mai 2018, 22:36:20 CEST Rob Tompkins a écrit :
> > On May 18, 2018, at 3:30 PM, Michael Osipov  wrote:
> > 
> > Am 2018-05-17 um 15:12 schrieb Rob Tompkins:
> > > Hello maven guys,
> > > 
> > > Over on commons we’ve been writing our own release-plugin
> > 
> > What is wrong with the current Maven Release Plugin and why are you
> > writing your own whereas we could improve the current one, can't we?
> We are trying to fit the Apache release paradigm where we are dealing with
> assemblies that we don’t want to deliver to Nexus. Further we are
> publishing the site up to our dev dist area for comparison with RC
> validation. We could contribute it back to the release plugin, but I’m not
> sure if it’s sufficiently general. Thoughts?

IIUC, the "release plugin" from Commons provides 3 mojos to prepare 3 
assemblies: it does not replace "release plugin" from Maven, which modifies 
pom.xml to switch from -SNAPSHOT to release version then to next SNAPSHOT

How is Commons release plugin used during a Commons release vs Maven release 
plugin? Do Commons use "mvn release:prepare" then "mvn release:perform", and 
the build in the release profile runs the 3 mojos to get the 3 assemblies?

Because what I see in this Commons release plugin look like custom steps to 
add to Maven release plugin, in addition to currently provided ones: as Robert 
wrote, there is a WIP in Maven release plugin to document how to add new 
steps. The Maven release plugin is already organized in steps, to be flexible, 
but just has not documented how to add new steps.

Regards,

Hervé

> 
> -Rob
> 
> > Michael
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org





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

Re: Questions regarding improving the Apache Commons release process.

[Hervé BOUTEMY]

Hi Rob,

one additional point: currently, for Maven itself, instead of adding new 
Maven-specific ReleasePhase(s) to the default configuration, or configure them 
in 
our parent pom (I'm not sure documentation on how to do that is available: I 
could not find it), we chose first to create a separate "dist-tool" to check 
consistency of what is currently published in misc places and provide some 
commands to fix when an inconsistency is found.

This happens through daily reports done by a Jenkins job [1]:
- distribution area vs Maven Central [2] 
- version from Maven site vs Maven Central [3]

We did not produce any release nor made it really configurable for conventions 
different from Maven ones (like Common's -src & -bin), but at least there is a 
configuration file to define artifacts to check [4]

HTH

Hervé


[1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/

[2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool-check-source-release.html

[3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool-check-index-page.html

[4] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool.conf.html

Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
> Stephen,
> 
> I can’t thank you enough for your reply. I’ll take your suggestions and
> continue to sandbox around using the maven-release-plugin as a guideline.
> 
> All the best and happy holidays,
> -Rob
> 
> > On Dec 26, 2017, at 5:27 AM, Stephen Connolly
> >  wrote:> 
> > On Tue 26 Dec 2017 at 03:10, Rob Tompkins > wrote:
> >> Hello all,
> >> 
> >> Pardon, maybe this should have gone to your @user list, but why not ping
> >> the dev crew. I’ve been playing around the ideas surrounding our fairly
> >> manual release process for the components in Commons, and I was hoping
> >> for
> >> some insights.
> >> 
> >> Scripting the version changes isn’t really that big of a deal for us, and
> >> that I can manage. But, when it comes to publishing our artifacts to the
> >> apache nexus repository, and then separately publishing our -src and -bin
> >> assemblies to the dev dist subversion repository (and consequently
> >> deleting
> >> those artifacts from nexus as they’re “attached” for the purpose of gpg
> >> signing), I feel it a tad cumbersome.
> >> 
> >> I’ve fiddled around a little with the idea of detaching the -src and -bin
> >> assemblies after gpg signing with some success, but then I have to delve
> >> into the mechanics of publishing those up to the subversion repository,
> >> and
> >> clearly that problem has already been solved.
> > 
> > Is your problem you don’t want those going to Nexus staging but only to
> > dist? Or is it that you want them *also* going to dist.
> > 
> > Personally... I see no reason to remove them from going to Nexus staging
> > (in fact I have a background plan to add secondary signing support to
> > staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
> > though. That would mean that the PMC would be able to *add* their GPG
> > signature to the staged artifacts as part of the voting... in which case
> > you’d want to hold off uploading to dist until *after* the vote so you get
> > the full set of signatures)
> > 
> > If you want to upload a subset of attached artifacts to dist as part of
> > the
> > release, that seems much more tenable... just a derivative of the
> > scm-publish plugin from what I can see.
> > 
> > So I find myself in the space of trying to shoehorn our process into its
> > 
> >> the main maven-release-plugin, which I’ve found a tad difficult, versus
> >> writing our own release plugin, which feels like I would be duplicating
> >> tons of code (which I don’t want to do).
> > 
> > So the release plugin is really two parts:
> > 
> > 1. A toolkit for writing release plugins
> > 
> > 2. An example that does the job for the requirements of the Maven TLP and
> > has seemed “sufficient” for a lot of other people.
> > 
> > As such, if you have different needs, do not feel bad about having to
> > encode differently... hopefully the toolkit half of the codebase is
> > sufficient for you.
> > 
> >> I’m curious if you guys have any thoughts on the matter as I’ve been
> >> playing around in the space for a little while now.
> >> 
> >> Cheers and happy holidays from UTC-5,
> >> -Rob
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>  For additional commands,
> >> e-mail: dev-h...@maven.apache.org 
> >> 
> >> --
> > 
> > Sent from my phone



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

[IO-162] add Xml(Stream)Reader/Writer from ROME

[Hervé Boutemy]

Hi,

XmlReader is a class written by Alejandro Abdelnur in the ROME project 
(http://rome.dev.java.net) to detect encoding from a stream containing an XML 
document.
It has been integrated into Maven 2.0.8, via XmlStreamReader in plexus-utils, 
and I added XmlStreamWriter.

commons-io seems the right library to distribute these utilities. I proposed 
it to Alejandro, who is ok.

I attached the code to https://issues.apache.org/jira/browse/IO-162 Jira 
issue.

Can someone take a look at it and tell if it is ok for inclusion?

regards,

Hervé

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[IO-162] add Xml(Stream)Reader/Writer from ROME

[Hervé Boutemy]

Hi,

XmlReader is a class written by Alejandro Abdelnur in the ROME project 
(http://rome.dev.java.net) to detect encoding from a stream containing an XML 
document.
It has been integrated into Maven 2.0.8, via XmlStreamReader in plexus-utils, 
and I added XmlStreamWriter.

commons-io seems the right library to distribute these utilities. I proposed 
it to Alejandro, who is ok.

I attached the code to https://issues.apache.org/jira/browse/IO-162 Jira 
issue.

Can someone take a look at it and tell if it is ok for inclusion?

regards,

Hervé

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]