Re: release of depends-maven-plugin?

[Julian Reschke]

On 10.05.2023 13:44, Konrad Windszus wrote:

Hi Julian, you would probably have to ask the ServiceMix team as it is their 
plug-in.
Maven committers in general cannot trigger releases there.

Konrad


Indeed. Will do. Thanks for the pointer.

Best regards, Julian


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

release of depends-maven-plugin?

[Julian Reschke]

Hi there,

we'd like to update Jackrabbit Oak to reproducable builds, and it seems
we need a version of the depends-maven-plugin containing the fix for
https://issues.apache.org/jira/browse/SM-5021. Any chance this might
come out anytime soon?

(And yes, I'm aware of the potential workaround)

Best regards, Julian

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

Weird Javadoc issue after updating project to Java 11

[Julian Reschke]

Hi there,

context: https://issues.apache.org/jira/browse/OAK-10144

We recently updated Jackrabbit Oak to require Java 11, and since then,
one subproject fails to build Javadocs, but depending on how the goal is
invoked (I discovered this when trying to do a release and the javadoc
jar generation failed)

It seems that (in oak-run)

> mvn clean javadoc:javadoc

works, but

> mvn clean install -DskipTests javadoc:javadoc

fails. I have figured out that in these cases, the passed command line
options are different, see
.

To repro:

1. git clone g...@github.com:apache/jackrabbit-oak.git
2. mvn clean install -DskipTests
3. cd oak-run ; mcn clean install -DskipTests javadoc:javadoc

Any pointers appreciated!

Best regards, Julian


(More details are in the ticket above)




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

Re: How to specify the character set / encoding for user credentials in basic authentication

[Julian Reschke]

Am 05.05.2021 um 16:10 schrieb Frank Schwab:

Hi, Julian,

sorry for not being precise.

RfC 7617 says that the encoding is unspecified. I know.

What I meant is that UTF-8 is (sort of) standard for the repo servers. They 
are mostly written in Java and the standard encoding for Java is UTF-8 in Basic 
Authentication.


"the standard encoding for Java is UTF-8 in Basic Authentication" - says
who?

I'd really like to know, because I plan to revise the RFC in the
not-so-distant future.


FWIW, our repo server (which is Artifactory) expects UTF-8.


Best regards, Julian

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

Re: How to specify the character set / encoding for user credentials in basic authentication

[Julian Reschke]

Am 05.05.2021 um 14:36 schrieb Frank Schwab:

Hello, everybody,

I have a problem with passwords for the server. I found the reason why this 
happens but I am unable to find the correct setting.

Here is the description:

   We want to publish some artifacts to a repository, so we set up a 
settings.xml file which looks like this


   
 some-repo
   testuser
   {U8jAeLVPH88HRYGnDpbAmAXPtUPSqbrtxxuZoR513V4=}
 



   some-repo
   
 
   some repo
   Some repository
   https://our.url.com/artifactory/list/some-repo/
 
   


When I run a mvn deploy:deploy-file command this works fine, except when the 
user testuser has a password that contains non-ASCII characters. In that case 
the non-ASCII characters in the password are replaced by the maven client with 
question marks when maven authenticates to the repo server.

I searched the internet up and down and since I could not find a fix I traced 
this down to the following code in Maven:

The class 
org.apache.maven.wagon.providers.http.httpclient.impl.auth.RFC2617Scheme has 
two methods which look like this:

 public Charset getCredentialsCharset() {
 return credentialsCharset != null ? credentialsCharset : Consts.ASCII;
 }

 String getCredentialsCharset(final HttpRequest request) {
 String charset = (String) 
request.getParams().getParameter(AuthPNames.CREDENTIAL_CHARSET);
 if (charset == null) {
 charset = getCredentialsCharset().name();
 }
 return charset;
 }

The call request.getParams().getParameter(AuthPNames.CREDENTIAL_CHARSET)returns null 
so the default character set is used which is US-ASCII. So the password is converted to 
US-ASCII and all non-ASCII characters are replaced by a "?".

However, the character encoding should be UTF-8. The repo server expects 
UTF-8. This is standard with http servers. I tried to figure out if this maven 
client phenomenon is a bug or a feature but I could not resolve this.
...


FWIW, this is not "standard". It should be, but isn't.

Best regards, Julian (as author of the Basic Auth RFC)


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

Re: Problem with use of enforcer-plugin after upgrading the Apache parent POM (18->21)

[Julian Reschke]

On 24.06.2019 14:49, Thomas Broyer wrote:

One of the POMs might need to use `combine.children="append"` on the
 element: https://maven.apache.org/pom.html#Plugins
No idea why that would only manifest during releases thoguh… have you
compared "mvn help:effective-pom" vs "mvn help:effective-pom
-Papache-release,release"?


I don't see any differences with respect to the enforcer, but show:



  
maven-enforcer-plugin
3.0.0-M2

  
enforce-maven-version

  enforce


  

  3.0.5

  

  
  
enforce-file-size
package

  enforce


  

  5100
  

C:\tmp\jackrabbit-oak\oak-run\target/oak-run-1.16-SNAPSHOT.jar
  

  

  

  


Best regards, Julian

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

Problem with use of enforcer-plugin after upgrading the Apache parent POM (18->21)

[Julian Reschke]

Hi there,

I've found a strange issue (well, strange to me) when I tried to upgrade
Oak's parent POM from 18 to 21 (details at
).

The actual change that triggers the issue for us was between version 18
and 19, which introduces the use of the enforcer plugin to check the
Maven version
(,
).

In Oak, we use the enforcer plugin to check the size of a generated JAR
file. After updating the parent POM, this check fails (or does not
happen?) - if and only if when done using "release:prepare".

To reproduce:

- clone https://github.com/apache/jackrabbit-oak
- update oak-parent/pom.xml to use version 21 instead of 18 of parent pom
- run mvn:release-prepare -DdryRun=true -Darguments="-DskipTests"


is the place in oak-run's POM where we use the enforcer plugin.

Are we doing something stupid here that conflicts with the use of the
enforcer plugin in the Apache parent POM?

Best regards, Julian

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