Re: Updating the apache parent to automatically clean before performing a release?

[Hervé BOUTEMY]

an issue has been found in Apache Parent POM 22, regarding scm-publish to Git: 
see MPOM-236 [1]
it does not affect Maven project itself, since we're publishing our site html 
to svn instead of Git, but many Apache projects with small sites publish to 
Git
Then we'll need to release version 23 soon

Is there any chance that a solution for your clean idea is added in this 
release?

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MPOM-236

Le dimanche 5 janvier 2020, 18:39:50 CET Christofer Dutz a écrit :
> Hi Herve,
> 
> he'll only get the same content if everything is done right ...
> unfortunately for example the IoTDB project had to re-do quite a number of
> RCs as they were still not 100% doing things the maven way.
 In PLC4X we
> just had to cancel a release of a sub-project due to the maven-wrapper.jar
> being packaged in. 
> There were tests writing things outside the target directory, which they
> were manually excluding. The maven-wrapper.jar keeps on being packaged by
> the default apache source assembly.
 Sometimes GIT excluded temp files are
> packaged. Only by running the release in the target/checkout directory you
> can be 100% sure it's a clean structure you're packaging. 
> I know that most problems are due to people not doing things the official
> "maven way" (TM) ... but I have to admit being involved in a lot of
> projects,
 if we could ensure some of the common pitfalls don't have such a
> severe impact, we could help a lot of projects. 
> 
> Chris
> 
> 
> 
> Am 05.01.20, 18:33 schrieb "Hervé BOUTEMY" :
> 
> notice that with Reproducible Builds being active by default, the source
> 
 archive is reproducible and RM will get the same content in both
> locations 
> There is only the .asc signature file that contains a different
> timestamp
 
> I'm just launching the long overdue Apache Parent 22 vote that will
> enable 
 Reproducible Builds by default, we'll see if a new release will be
> ready soon 
> Regards,
> 
> Hervé
> 
> Le dimanche 5 janvier 2020, 14:41:37 CET Christofer Dutz a écrit :
> 
> > Hi Robert,
> > 
> > I would be more than happy to assist with making releases with maven
> > easier
 for Apache projects ...
> 
>  So if you give me a little update on what needs to
> 
> > be done, I might be able to spare some time and work on this. 
> > But using the files from the prepare is the issue I'm trying to
> > address ...
 the perform build is a clean checkout of the tagged
> > version.
> 
>  The clean
> 
> > checkout ensures the build is 100% clean ... things like packing in
> > test-results, packing in maven-wrapper jars etc. only happens because
> > the
> > source distribution is not built in a clean environment. 
> > I would love if it was possible to extend questions the
> > release-prepare
> > plugin asks for ... so if it would ask for a RC number, 
> 
>  we could add a
> 
> > call to the scm:checkin goal in the deploy phase of a release-perform
> > build
 as part of the "apache-release" profile. The only piece of
> > information that’s missing, would be the release-candidate number.
> > 
> > Chris
> > 
> > 
> > 
> > Am 05.01.20, 14:07 schrieb "Robert Scholte" :
> > 
> > 
> > ASF deserves a customized release strategy, which is now possible
> > with
> > 
> > MRELEASE-956
> 
>  My idea is that during "prepare" the plugin should upload
> 
> > several files to the ASF dist folder besides the tagging. During
> > "perform"
> > it should use these files instead of the tag in SCM (because these
> > files
> > are the official releases, not the tag). 
> > 
> > Just waiting for someone to pick it up.
> > 
> > thanks,
> > Robert
> > 
> > 
> > [1] https://jira.apache.org/jira/browse/MRELEASE-956
> > On 5-1-2020 11:28:22, Christofer Dutz 
> > 
> > wrote:
> 
>  Hi all,
> 
> > 
> > I just wanted to suggest something I have noticed a lot of Apache
> > 
> > projects were doing wrong. Especially when unexperienced RMs are doing
> > the
> > releases.
> 
>  
> 
> > Several times now after doing a release, the RMs have uploaded
> > the
> > 
> > source bundles from “target” to the SVN. However they should have
> > uploaded
> > the “target/checkout/target”.
> 
>  It is just too tempting to upload the
> 
> > versions left over from the release:prepare step as they too have the
> > release version. 
> > 
> > Usually this wouldn’t be a problem and I guess this has happened
> > quite
> > 
> > often in the past. The thing is with the adoption of the maven-wrapper
> > we
> > can unfortunately see when something’s going wrong.
> 
>  In this case there is
> 
> > a difference. The source bundles from 

Re: [maven-shade-plugin] 3.2.2 status and open PRs

[Falko Modler]

Hi Karl Heinz,

thanks for this clarification.

So now there is only one last ticket left for 3.2.2 and the PR for it
looks good to be merged:
https://github.com/apache/maven-shade-plugin/pull/33
https://issues.apache.org/jira/browse/MSHADE-339

Looking forward to 3.2.2.

Thank you very much!

Best regards,
Falko

Am 04.01.2020 um 11:57 schrieb Karl Heinz Marbaise:

Hi,

On 03.01.20 17:11, Falko Modler wrote:

Hi everyone,

it has been over a year since the last release 3.2.1 and two weeks ago
there have been some activities to release 3.2.2 but it seems those
commits were (partially) reverted.

See: https://github.com/apache/maven-shade-plugin/commits/master

I cannot see 3.2.2 on Maven Central either. Does anyone know the status?


Of course you don't see it on Maven Central, cause there had no VOTE
thread about the plugin which ended positive which in consequence means
no release announcement ...

There had come issues related to Javadoc etc. which I have fixed
afterwards...




I also do ask this because I've just created a PR which I'd love to see
included in 3.2.2 or a near-term 3.2.3:
https://github.com/apache/maven-shade-plugin/pull/35


Testing in CI...

Kind regards
Karl Heinz Marbaise


Apart from older PRs, there are two recent PRs created by other users
for issues that are assigned to 3.2.2, but both are still open:

- https://issues.apache.org/jira/browse/MSHADE-340

- https://issues.apache.org/jira/browse/MSHADE-339


Thanks for your attention/help!


Best regards and happy 2020,

Falko Modler



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




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

Re: Maven Ant Tasks - cannot connect to Maven Central anymore

[Vladimir Sitnikov]

Cristi>Is there any place to contribute the change?

Here:
https://github.com/apache/maven-ant-tasks/blob/ed4d9a3bd1a41613791f2466f19c225898d45519/src/main/java/org/apache/maven/artifact/ant/AbstractArtifactWithRepositoryTask.java#L55

PS. https://issues.apache.org/jira/browse/MANTTASKS-206 seems to specify
the way to override the URL.

Vladimir

Maven Ant Tasks - cannot connect to Maven Central anymore

[Cristian Caprar]

Hi everyone,

I know this component is retired, but some projects still use it (we are using 
SAP Commerce and it makes use if it…).

As of 15 January 2020, the only way to access Maven Central is by https. This 
starts the issue.

The problem: Maven Ant Task throws an error that it cannot connect to 
http://repo1.maven.org/maven2 ) and all our 
builds fail.

Details:
- in Maven Ant Tasks, the mvn task (Mvn class) is being called in our case 
without a mavenHome (because we are running the build in a Docker container and 
it does not have Maven in it)
- this task tries to resolve the Maven dependency by itself 
(downloadAndConfigureMaven method)
- it creates a DependenciesTask without without any configured remote 
repository and executes it
- the DependenciesTask will create a default remote repository configuration, 
in base class AbstractArtifactWithRepositoryTask#getDefaultRemoteRepository
- this default remote repo is unfortunately hardcoded to 
“http://repo1.maven.org/maven2”

We tried to pass 
-DremoteRepositories=central::default::http://nexus.ourdomain.com/repository/maven-central/
  as a command line 
argument to the Mvn task, but this is ignored by the task as described above.

What I plan to do is to use this command line argument to setup a correct 
remote repo in the dependencies task when resolving Maven.

Is there any place to contribute the change?

If someone has the same problem, feel free to contact me.

Thank you and all the best,
Cristi C.

Re: https://stackoverflow.com/questions/59746954/failed-to-execute-goal-org-apache-maven-pluginsmaven-surefire-plugin2-22-0tes

[Robert Scholte]

Hi Rory,

I'm pretty sure it is unrelated to the JDK version.
A simple search in Jira returns enough hits[1]
I don't know a lot about Surefire, there are others that have full focus on it 
and can give better details.
If I understand correctly now they're using one of the output streams to 
communicate with the plugin. 
If for some reason another process conflict with this stream you can get this 
error.
There are plans to rewrite it (3.0.0-M5? [2])

thanks,
Robert

[1] 
https://issues.apache.org/jira/browse/SUREFIRE-910?jql=project%20%3D%20SUREFIRE%20AND%20text%20~%20goodbye
[2] https://maven.apache.org/surefire/maven-surefire-plugin/


On 16-1-2020 16:46:23, Rory O'Donnell  wrote:

Hi Robert,

We have see an issue flagged on stackoverflow:

https://stackoverflow.com/questions/59746954/failed-to-execute-goal-org-apache-maven-pluginsmaven-surefire-plugin2-22-0tes

Do you know if this issue is specific to JDK 8u241 or have you seen it
on earlier versions as well?

Rgds,Rory

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

https://stackoverflow.com/questions/59746954/failed-to-execute-goal-org-apache-maven-pluginsmaven-surefire-plugin2-22-0tes

[Rory O'Donnell]

Hi Robert,

We have see an issue flagged on stackoverflow:

https://stackoverflow.com/questions/59746954/failed-to-execute-goal-org-apache-maven-pluginsmaven-surefire-plugin2-22-0tes

Do you know if this issue is specific to JDK 8u241 or have you seen it 
on earlier versions as well?


Rgds,Rory

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: Skip project when generating archetypes

[Lukasz Lenart]

czw., 12 gru 2019 o 08:04 Lukasz Lenart  napisał(a):
>
> wt., 12 lis 2019 o 07:36 Lukasz Lenart  napisał(a):
> >
> > Done, JIRA ticket is here 
> > https://issues.apache.org/jira/browse/ARCHETYPE-583
> > >
> > > https://github.com/apache/maven-archetype/pull/33
>
> Could you review the PR? I have been testing those changes locally
> with Struts Archetypes and everything went well.

I don't see a SNAPSHOT in ASF Nexus, do you have a Jenkins job to do
so? I tried to do it manually but I don't have access to deploy a new
SNAPSHOT. Should I prepare a Jenkinsfile to implement such a job?


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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

Re: Paypal Declares Latest Release Pom in Maven Central

[Elliotte Rusty Harold]

That's up to paypal. There's nothing Maven can do about it.

On Thu, Jan 16, 2020 at 4:33 AM Petar Tahchiev  wrote:
>
> Hi devs,
>
> the official paypal merchantsdk-java pom.xml here:
> https://repo1.maven.org/maven2/com/paypal/sdk/merchantsdk/2.15.122/merchantsdk-2.15.122.pom
> declares the following dependency:
>
> 
> 
> com.paypal.sdk
> paypal-core
> LATEST
> 
> 
>
> It also lists this repository:
> 
> 
> sonatype-nexus-staging
> Nexus Release Repository
> 
> https://oss.sonatype.org/service/local/staging/deploy/maven2/
> 
> 
> 
>
> which is password protected. As a result every time I build a project with
> the merchantsdk dependency I get the following super  annoying warnings:
> ---
> Downloading from sonatype-nexus-staging:
> https://oss.sonatype.org/service/local/staging/deploy/maven2/com/paypal/sdk/paypal-core/maven-metadata.xml
> [WARNING] Could not transfer metadata
> com.paypal.sdk:paypal-core/maven-metadata.xml from/to
> sonatype-nexus-staging (
> https://oss.sonatype.org/service/local/staging/deploy/maven2/): Not
> authorized
> [WARNING] Failure to transfer com.paypal.sdk:paypal-core/maven-metadata.xml
> from https://oss.sonatype.org/service/local/staging/deploy/maven2/ was
> cached in the local repository, resolution will not be reattempted until
> the update interval of sonatype-nexus-staging has elapsed or updates are
> forced. Original error: Could not transfer metadata
> com.paypal.sdk:paypal-core/maven-metadata.xml from/to
> sonatype-nexus-staging (
> https://oss.sonatype.org/service/local/staging/deploy/maven2/): Not
> authorized
> 
> Moreover when my network is down the build takes eternity before it fails
> with exception. And then I have to tell all my colleagues to build it with
> -o
>
> Is there any way to tell Paypal to update their pom.xml and upload a new
> version?
> There's a 2-year old issue here:
> https://github.com/paypal/merchant-sdk-java/issues/46
> but nobody seems to take a notice.
> Is there any official way to contact Paypal and ask them to fix it?
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Paypal Declares Latest Release Pom in Maven Central

[Petar Tahchiev]

Hi devs,

the official paypal merchantsdk-java pom.xml here:
https://repo1.maven.org/maven2/com/paypal/sdk/merchantsdk/2.15.122/merchantsdk-2.15.122.pom
declares the following dependency:



com.paypal.sdk
paypal-core
LATEST



It also lists this repository:


sonatype-nexus-staging
Nexus Release Repository

https://oss.sonatype.org/service/local/staging/deploy/maven2/




which is password protected. As a result every time I build a project with
the merchantsdk dependency I get the following super  annoying warnings:
---
Downloading from sonatype-nexus-staging:
https://oss.sonatype.org/service/local/staging/deploy/maven2/com/paypal/sdk/paypal-core/maven-metadata.xml
[WARNING] Could not transfer metadata
com.paypal.sdk:paypal-core/maven-metadata.xml from/to
sonatype-nexus-staging (
https://oss.sonatype.org/service/local/staging/deploy/maven2/): Not
authorized
[WARNING] Failure to transfer com.paypal.sdk:paypal-core/maven-metadata.xml
from https://oss.sonatype.org/service/local/staging/deploy/maven2/ was
cached in the local repository, resolution will not be reattempted until
the update interval of sonatype-nexus-staging has elapsed or updates are
forced. Original error: Could not transfer metadata
com.paypal.sdk:paypal-core/maven-metadata.xml from/to
sonatype-nexus-staging (
https://oss.sonatype.org/service/local/staging/deploy/maven2/): Not
authorized

Moreover when my network is down the build takes eternity before it fails
with exception. And then I have to tell all my colleagues to build it with
-o

Is there any way to tell Paypal to update their pom.xml and upload a new
version?
There's a 2-year old issue here:
https://github.com/paypal/merchant-sdk-java/issues/46
but nobody seems to take a notice.
Is there any official way to contact Paypal and ask them to fix it?

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611