New Profile Activation Type Request - Maven Version

[John Patrick]

Hi,

I believe this is the right mailing list, but please send me else where if not.

I would like to request that a new profile activation type be added,
which is based upon the maven version that is executing. What are
people version upon this change?

Base Ground

I've just done an upgrade from maven 2 to maven 3, it was a staggered
upgrade so not all developers where done at the same time, as well as
upgrading to maven 3 did not break anything. I had to create two
profiles which contained version properties to use respectively. One
issues was developer where using the wrong profile, or missing
profile.



e.g.

project xmlns=http://maven.apache.org/POM/4.0.0;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/xsd/maven-4.0.0.xsd;
  ...
  profiles
  ...
profile
  idmaven2-profile/id
  activation
maven2+/maven
  ...
profile
  idmaven3-profile/id
  activation
maven3+/maven
  ...

So you can define which maven version to activate on, using a regex
type pattern.
e.g.
--- 3+ maven version 3 or newer
--- 3.0.1 specifically maven version 3.0.1

What are peoples views on this change, I realize that maven
prerequisites exists but that is a hard limit, where as maven 2 to 3
you needed different plugin version and everything still worked okay.

Cheers,
John

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

Re: New Profile Activation Type Request - Maven Version

[John Patrick]

On 9 February 2011 14:28, Brian Fox bri...@infinity.nu wrote:
 Here's a workaround in the meantime:
 http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?p2=%2Fmaven%2Fpom%2Ftrunk%2Fasf%2Fpom.xmlp1=%2Fmaven%2Fpom%2Ftrunk%2Fasf%2Fpom.xmlr1=1065778r2=1065777view=diffpathrev=1065778

 On Wed, Feb 9, 2011 at 9:12 AM, John Patrick nhoj.patr...@gmail.com wrote:
 Hi,

 I believe this is the right mailing list, but please send me else where if 
 not.

 I would like to request that a new profile activation type be added,
 which is based upon the maven version that is executing. What are
 people version upon this change?

 Base Ground
 
 I've just done an upgrade from maven 2 to maven 3, it was a staggered
 upgrade so not all developers where done at the same time, as well as
 upgrading to maven 3 did not break anything. I had to create two
 profiles which contained version properties to use respectively. One
 issues was developer where using the wrong profile, or missing
 profile.



 e.g.

 project xmlns=http://maven.apache.org/POM/4.0.0;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd;
  ...
  profiles
  ...
    profile
      idmaven2-profile/id
      activation
        maven2+/maven
  ...
    profile
      idmaven3-profile/id
      activation
        maven3+/maven
  ...

 So you can define which maven version to activate on, using a regex
 type pattern.
 e.g.
 --- 3+ maven version 3 or newer
 --- 3.0.1 specifically maven version 3.0.1

 What are peoples views on this change, I realize that maven
 prerequisites exists but that is a hard limit, where as maven 2 to 3
 you needed different plugin version and everything still worked okay.

 Cheers,
 John

 -
 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



Cheers, Voted, I thought there would be an issue raised already. Just
couldn't find the jira project it might be in.

John

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

Repository Roadmap

[John Patrick]

Evening, Morning, Hello,

I'm wondering if their is a roadmap for repository
design/functionality. I'm thinking something along the lines of
Debian's repository structure and standards.

I've been working with Maven since 2005 usually in Off-Line
environments, where Companies question using it because it is open
source so where do they purchase support and how secure is it.

Overview of Suggested Changes

1) sha256 Checksum
  - Start using sha256 as the default checksum, as md5 can be forged
given enough cpu power.

2) Include Checksum  Signature of Artifacts in Published POM's
   - Currently each published file is independently verified by
checksum and signature. This means pom's and artifacts can be changed
without anything be detected. When a pom is published the details of
artifacts being published are injected into the released pom.

3) Repository Hierarchy
   - Merge snapshot and release repos and split central into sub directories
   - Strict publishing requirements for new core release repo
   - Relaxed publishing requirements for open repo(s)
   - Point pom to single repo and define what you are willing to accept
   - repo/core/release states to clients, only accept valid checksum
and signatures
   - repo/open/release states to client, warn if checksum are missing
or invalid and continue if you accept that risk

e.g. repo defined in pom http://repo.maven.org/repo/
   repo/
   - core/
      - snapshot/
      - release/
   - main
       - snapshot/
       - release/
   - open
       - snapshot/
       - release/
   - 3rdparty
       - snapshot/
       - release/

4) Core Publishing Requirements
   - Everything must be Signed
   - Everything mush have valid Checksum
   - Everything must publish JavaDoc (if appropriate, e.g. for
jar/war/ear packaged artifact)
   - Everything must publish Source (if appropriate, e.g. for
jar/war/ear packaged artifact)
   - Everything mush have Open Source License
   - Group ID must match project url,
   - Everything for only core functionality e.g. mvn clean install
deploy site using any org.apache.maven.plugins.

5) Main Publishing Requirements
    - Same requirements as (4) Core but ignoring the core functionality comment

6) Open Publishing Requirements
    - Everything accepted and also treated as untrusted.

7) 3rdparty Publishing Requirements
    - Probably wrong name, contains pom that are signed and checksum
themself and refer to artifacts that can't be published to maven due
to export/license restrictions.
    - Example is Oracle JDBC, or WebLogic jars. Lost of enterprise
projects use these and everything includes them in different ways. A
pom is defined which includes the checksum of the artifact, so when
people talk about ojdbc 14, every know it is
com.oracle.java.database.drivers:ojdbc:1.4:jar.

8) DNSSEC Integration
   - I realise dns sec is still being rolled out but getting maven
trusting it might lead to more trust towards maven from the corporate
world.



I would really appreciate feedback regarding these suggestion.

John

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

Re: Repository Roadmap

[John Patrick]

On Thursday, 17 February 2011, Siegmann Daniel, NY
daniel.siegm...@fja-us.com wrote:
 Hi John,

 For companies which are this paranoid, perhaps they should not download 
 artifacts from public repositories at all. Have you considered setting up a 
 Nexus / Archiva installation which does not connect to any public repos? Then 
 you can manually deploy any artifacts you wish to this repository, while 
 ensuring they meet whatever stringent requirements you wish.

 ~Daniel

 -Original Message-
 From: John Patrick [mailto:nhoj.patr...@gmail.com]
 Sent: Thursday, February 17, 2011 10:56 AM
 To: dev
 Subject: Repository Roadmap

 Evening, Morning, Hello,

 I'm wondering if their is a roadmap for repository
 design/functionality. I'm thinking something along the lines of
 Debian's repository structure and standards.

 I've been working with Maven since 2005 usually in Off-Line
 environments, where Companies question using it because it is open
 source so where do they purchase support and how secure is it.

 Overview of Suggested Changes

 1) sha256 Checksum
   - Start using sha256 as the default checksum, as md5 can be forged
 given enough cpu power.

 2) Include Checksum  Signature of Artifacts in Published POM's
    - Currently each published file is independently verified by
 checksum and signature. This means pom's and artifacts can be changed
 without anything be detected. When a pom is published the details of
 artifacts being published are injected into the released pom.

 3) Repository Hierarchy
    - Merge snapshot and release repos and split central into sub directories
    - Strict publishing requirements for new core release repo
    - Relaxed publishing requirements for open repo(s)
    - Point pom to single repo and define what you are willing to accept
    - repo/core/release states to clients, only accept valid checksum
 and signatures
    - repo/open/release states to client, warn if checksum are missing
 or invalid and continue if you accept that risk

 e.g. repo defined in pom http://repo.maven.org/repo/
    repo/
    - core/
       - snapshot/
       - release/
    - main
        - snapshot/
        - release/
    - open
        - snapshot/
        - release/
    - 3rdparty
        - snapshot/
        - release/

 4) Core Publishing Requirements
    - Everything must be Signed
    - Everything mush have valid Checksum
    - Everything must publish JavaDoc (if appropriate, e.g. for
 jar/war/ear packaged artifact)
    - Everything must publish Source (if appropriate, e.g. for
 jar/war/ear packaged artifact)
    - Everything mush have Open Source License
    - Group ID must match project url,
    - Everything for only core functionality e.g. mvn clean install
 deploy site using any org.apache.maven.plugins.

 5) Main Publishing Requirements
     - Same requirements as (4) Core but ignoring the core functionality 
 comment

 6) Open Publishing Requirements
     - Everything accepted and also treated as untrusted.

 7) 3rdparty Publishing Requirements
     - Probably wrong name, contains pom that are signed and checksum
 themself and refer to artifacts that can't be published to maven due
 to export/license restrictions.
     - Example is Oracle JDBC, or WebLogic jars. Lost of enterprise
 projects use these and everything includes them in different ways. A
 pom is defined which includes the checksum of the artifact, so when
 people talk about ojdbc 14, every know it is
 com.oracle.java.database.drivers:ojdbc:1.4:jar.

 8) DNSSEC Integration
    - I realise dns sec is still being rolled out but getting maven
 trusting it might lead to more trust towards maven from the corporate
 world.



 I would really appreciate feedback regarding these suggestion.

 John

 -
 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



Daniel, that is the kind of setup I use. But normally the development
network is not physically connected to the internet.

But you also must agree that the central repository has become a
bloated dumping group. I use to rsync it to my local network and
remember it being 16GB, it is now 175GB last time I checked. Surely a
more formal structure that give trust into what you are using is
useful to everyone.

People trust Linux software because it is signed and distributed with
the source. Maybe using a similar method would help with greater
adoption by Linux distributions.

Also I could have acces to a 1GB unlimited bandwidth server in London
but with max 30GB local diskspace. So I could offer fast mirror access
to the core/releases, main/releases but not the whole central as it is
currently structured. The hosting provider would also want
confirmation

Maven SCM Git Perforce

[John Patrick]

Want to help specifically with Git and Perforce as I'm using them both
daily with Maven projects.

Looking at the Overview of SCM's page against the Maven SCM
Providers Matrix page, it seams to have mixed messages and feels out
of date.

Perforce is listed under Fully implemented SCM's. But apparently
doesn't have the following features.
- Branch - Not Implemented
- Export - Not Implemented
- List - Not Implemented
- Login - Not In SCM *I disagree with this as I have to log into
Perforce each day.
- Pure Java - Not Implemented

Git is listed under Partially implemented SCM's. But apparently
doesn't have the following features.
- Edit - Not in SCM
- Export - Not in SCM
- Login - Not In SCM
- Unedit - Not In SCM
- Pure Java - Not Implemented



Would I be duplicating anyone else's work, if I start looking at implementing:

1) Perforce Pure Java client

2) Perforce Login

3) Git Pure Java client

4) Maven SCM Providers Matrix, add column for site. i.e. Project
Information-Source Repository. As last time I checked for git it
doesn't output helpful details.



John

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

Re: Maven SCM Git Perforce

[John Patrick]

On 4 April 2012 17:18, Asaf Mesika asaf.mes...@gmail.com wrote:
 Why do you need a specific login for git?
 In our company each developer exchanges keys with the main server
 hosting our git repositories and then the repository URL simply
 contains the user which we exchanged keys with. For example:
 ssh://git...@gitrepo.acme.local/gitall/reponame

 Sent from my iPad

 On 4 באפר 2012, at 17:16, Olivier Lamy ol...@apache.org wrote:

 Hello,


 2012/4/4 John Patrick nhoj.patr...@gmail.com:
 Want to help specifically with Git and Perforce as I'm using them both
 daily with Maven projects.

 Looking at the Overview of SCM's page against the Maven SCM
 Providers Matrix page, it seams to have mixed messages and feels out
 of date.
 Agree. We probably need some help/contributions here :-).
 I can review your patches and apply it !

 Perforce is listed under Fully implemented SCM's. But apparently
 doesn't have the following features.
 - Branch - Not Implemented
 - Export - Not Implemented
 - List - Not Implemented
 - Login - Not In SCM *I disagree with this as I have to log into
 Perforce each day.
 - Pure Java - Not Implemented

 Git is listed under Partially implemented SCM's. But apparently
 doesn't have the following features.
 - Edit - Not in SCM
 - Export - Not in SCM
 - Login - Not In SCM
 - Unedit - Not In SCM
 - Pure Java - Not Implemented



 Would I be duplicating anyone else's work, if I start looking at 
 implementing:

 1) Perforce Pure Java client
 We usually have an other provider for that see (see
 http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/)

 2) Perforce Login

 3) Git Pure Java client
 same as perforce (I think there already exists but I don't remember
 which fork of github is up2date :-) ). see
 https://github.com/struberg/maven-scm-providers-git module called
 maven-scm-provider-jgit )

 4) Maven SCM Providers Matrix, add column for site. i.e. Project
 Information-Source Repository. As last time I checked for git it
 doesn't output helpful details.



 John

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




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 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


Asaf,

I believe you've miss read my email.

My only comment regarding Git Login was clarification of what was Not
In SCM and Not Implemented for Git and Perforce. I listed the
current Matrix lists Git Login as Not in SCM. I totally agree with
your comments regarding git and login.

The only Not In SCM that I listed and disagree with, is, Perforce
Login. As Perforce is a classic Client/Server Source Control System
and you do have Login and Logout features.

John

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

Re: Maven SCM Git Perforce

[John Patrick]

Perforce is a nice tool, i'ld choose it over most other client server
based scm. Been using it for over 6 years as well as being a perforce
admin on and off. Does cost a lot per person.

On 5 April 2012 20:20, Asaf Mesika asaf.mes...@gmail.com wrote:
 Sadly Our company is also moving to perforce so if you want a little bit of
 help with this let me know.

 Sent from my iPhone

 On 4 באפר 2012, at 19:30, John Patrick nhoj.patr...@gmail.com wrote:

 On 4 April 2012 17:18, Asaf Mesika asaf.mes...@gmail.com wrote:

 Why do you need a specific login for git?

 In our company each developer exchanges keys with the main server

 hosting our git repositories and then the repository URL simply

 contains the user which we exchanged keys with. For example:

 ssh://git...@gitrepo.acme.local/gitall/reponame


 Sent from my iPad


 On 4 באפר 2012, at 17:16, Olivier Lamy ol...@apache.org wrote:


 Hello,



 2012/4/4 John Patrick nhoj.patr...@gmail.com:

 Want to help specifically with Git and Perforce as I'm using them both

 daily with Maven projects.


 Looking at the Overview of SCM's page against the Maven SCM

 Providers Matrix page, it seams to have mixed messages and feels out

 of date.

 Agree. We probably need some help/contributions here :-).

 I can review your patches and apply it !


 Perforce is listed under Fully implemented SCM's. But apparently

 doesn't have the following features.

 - Branch - Not Implemented

 - Export - Not Implemented

 - List - Not Implemented

 - Login - Not In SCM *I disagree with this as I have to log into

 Perforce each day.

 - Pure Java - Not Implemented


 Git is listed under Partially implemented SCM's. But apparently

 doesn't have the following features.

 - Edit - Not in SCM

 - Export - Not in SCM

 - Login - Not In SCM

 - Unedit - Not In SCM

 - Pure Java - Not Implemented




 Would I be duplicating anyone else's work, if I start looking at
 implementing:


 1) Perforce Pure Java client

 We usually have an other provider for that see (see

 http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/)


 2) Perforce Login


 3) Git Pure Java client

 same as perforce (I think there already exists but I don't remember

 which fork of github is up2date :-) ). see

 https://github.com/struberg/maven-scm-providers-git module called

 maven-scm-provider-jgit )


 4) Maven SCM Providers Matrix, add column for site. i.e. Project

 Information-Source Repository. As last time I checked for git it

 doesn't output helpful details.




 John


 -

 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

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





 --

 Olivier Lamy

 Talend: http://coders.talend.com

 http://twitter.com/olamy | http://linkedin.com/in/olamy


 -

 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



 Asaf,

 I believe you've miss read my email.

 My only comment regarding Git Login was clarification of what was Not
 In SCM and Not Implemented for Git and Perforce. I listed the
 current Matrix lists Git Login as Not in SCM. I totally agree with
 your comments regarding git and login.

 The only Not In SCM that I listed and disagree with, is, Perforce
 Login. As Perforce is a classic Client/Server Source Control System
 and you do have Login and Logout features.

 John

 -
 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: Remote Repository access

[John Patrick]

If on unix/linux has you tried the same url with curl or wget.

What does a brower day if you point it to that url?

Not sure about borland starteam but does it have access logs and if so
does see your connections coming in.

Have you tried wireshark to see what ethernet traffic is generated?

On 12 April 2012 08:11, rp_prasanna prasanna.renganat...@gmail.com wrote:
 Hi,
  I have kept all the maven repository in the borland starteam.
 Now i wanted to access the dependencies from the starteam.
 I tried using the remote repository tag in the pom.xml but it could not
 reach the reposirory.
 The syntax which i used is as follows.


                maven_rep
                http://@hostnane/@path/Maven_Repository/.m2/repository



 But the console tells that it could not reach the url.
 Thank u


 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Remote-Repository-access-tp5634845p5634845.html
 Sent from the Maven Developers mailing list archive at Nabble.com.

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

Re: Help to add Oracle JDBC driver

[John Patrick]

I think it might be as simple as add -DgeneratePom=true.

I would suggest not doing it my hand on the command line but create a
separate pom, maybe a module for your project or maybe for your
company where command 3rd party jars can be installed.

i.e.
[...]
   build
  plugins
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.3.1/version
inheritedfalse/inherited
executions
[...]
   execution
  idinstall:com.oracle:ojdbc6:11g/id
  phasevalidate/phase
  goals
 goalinstall-file/goal
  /goals
  configuration

file${project.basedir}/com/oracle/ojdbc6/ojdbc6.jar/file
 groupIdcom.oracle/groupId
 artifactIdojdbc6/artifactId
 version11g/version
 packagingjar/packaging
 createChecksumtrue/createChecksum
 generatePomtrue/generatePom
  /configuration
   /execution
[...]

The main reason is it is then consistent for each developer and
potentially continuous integration can automatically push into your
local/project/company repository.

I then have that wrapping '3rd-party' pom as a dependency for the main
project pom and it's version is increased with each new dependency. So
when a developer sync's and a new dependency instead of where is
oracle x, they also get 3rd-party x.

John

On 23 April 2012 15:23, copyto27 cop...@gmail.com wrote:
 Hi,

 I'm traying to add the Oracle JDBC driver to my maven local repository with
 this commad:

 mvn install:install-file
 -Dfile=C:\apache-maven-3.0.4\lib\ojdbc6-11.1.0.7.0.jar -DgroupId=com.oracle
 -DartifactId=ojdbc6 -Dversion=11.1.0.7.0 -Dpackaging=jar

 but maven return the next error:

 [INFO] Scanning for projects...
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 0.249s
 [INFO] Finished at: Mon Apr 23 16:06:48 CEST 2012
 [INFO] Final Memory: 1M/15M
 [INFO]
 
 [ERROR] The goal you specified requires a project to execute but there is no
 POM in this directory (C:\). Please verify
 you invoked Maven from the correct directory. - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
 switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions, please
 read the following articles:


 What am I doing wrong?

 thanks!!

 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Help-to-add-Oracle-JDBC-driver-tp5659525p5659525.html
 Sent from the Maven Developers mailing list archive at Nabble.com.

 -
 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: Help to add Oracle JDBC driver

[John Patrick]

Try going into the directory which contains the jar, so it's just ...
-Dfile=ojdbc6-11.1.0.7.0.jar ...

On 23 April 2012 16:55, copyto27 cop...@gmail.com wrote:
 Hi John

 I tried too with -DgeneratePom=true but i have the same problem

 :(

 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Help-to-add-Oracle-JDBC-driver-tp5659525p5659746.html
 Sent from the Maven Developers mailing list archive at Nabble.com.

 -
 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: Help to add Oracle JDBC driver

[John Patrick]

If you still get errors can you send over the output from mvn -version

Also if you do the following in a new directory what does it say, mine does:

$ mkdir qwerty-20120423
$ cd qwerty-20120423
$ mvn install:install-file -Dfile=qwerty
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Maven Stub Project (No POM) 1
[INFO] 
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @
standalone-pom ---
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 0.869s
[INFO] Finished at: Mon Apr 23 17:05:11 BST 2012
[INFO] Final Memory: 3M/81M
[INFO] 
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(default-cli) on project standalone-pom: The artifact information is
incomplete or not valid:
[ERROR] [0]  'groupId' is missing.
[ERROR] [1]  'artifactId' is missing.
[ERROR] [2]  'packaging' is missing.
[ERROR] [3]  'version' is missing.
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Which is the correct error when I miss all the require options for
install:install-file.

John

On 23 April 2012 17:00, John Patrick nhoj.patr...@gmail.com wrote:
 Try going into the directory which contains the jar, so it's just ...
 -Dfile=ojdbc6-11.1.0.7.0.jar ...

 On 23 April 2012 16:55, copyto27 cop...@gmail.com wrote:
 Hi John

 I tried too with -DgeneratePom=true but i have the same problem

 :(

 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Help-to-add-Oracle-JDBC-driver-tp5659525p5659746.html
 Sent from the Maven Developers mailing list archive at Nabble.com.

 -
 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: Help to add Oracle JDBC driver

[John Patrick]

I created a new directory
Copied the oracle jar into that new directory
Renamed the oracle jar to match your filename
Copied and pasted your command line, as a single line
I get the following below...

The only thing I notice which is different is, that I get:
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @
standalone-pom ---
[INFO] Installing /Users/USERNAME/projects/oss/tmp/ojdbc6.jar to
/Users/USERNAME/.m2/repository/com/oracle/ojdbc6/11.1.0.7.0/ojdbc6-11.1.0.7.0.jar

And Your have:
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ ojdbc6 ---
[INFO] Installing C:\CGSI\apache-maven-3.0.4\lib\ojdbc6 to
C:\Users\emeanavallin\.m2\repository\com\ojdbc6\11\ojdbc6-11.jar

Questions
1) Do you have a pom.xml in the directory that you are executing the
install:install-file command from?
2) Does this work for another developer?
3) Your output says @ ojdbc6 and min says @ standalone-pom
4) Your output says C:\CGSI\apache-maven-3.0.4\lib\ojdbc6 but mine
lists the file /Users/USERNAME/projects/oss/tmp/ojdbc6.jar. It seams
to miss out the .jar so and the error reports .jar so wonder if
linked.
5) Who created the C:\CGSI directory?
6) Is the apache-maven-3.0.4 directory exactly what was downloaded from maven?
7) I as as ojdbc6.jar isn't distributed with maven so you must have
chosen to put it there.
8) If none of the above works, use the following pom and place it into
the directory where ojdbc6.jar exists
(https://gist.github.com/2490338) and the execute mvn validate, in
that same directory.

Let me know if anything helps.


My output, copy and paste of your command line.

$ mvn install:install-file -Dfile=ojdbc6.jar -DgroupId=com.oracle
-DartifactId=ojdbc6 -Dversion=11.1.0.7.0 -Dpackaging=jar
-DgeneratePom=true
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Maven Stub Project (No POM) 1
[INFO] 
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @
standalone-pom ---
[INFO] Installing /Users/USERNAME/projects/oss/tmp/ojdbc6.jar to
/Users/USERNAME/.m2/repository/com/oracle/ojdbc6/11.1.0.7.0/ojdbc6-11.1.0.7.0.jar
[INFO] Installing
/var/folders/nR/nRGBTAqKGxmmdH-QYQyQoTI/-Tmp-/mvninstall2133488645731106521.pom
to 
/Users/USERNAME/.m2/repository/com/oracle/ojdbc6/11.1.0.7.0/ojdbc6-11.1.0.7.0.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 2.241s
[INFO] Finished at: Wed Apr 25 15:38:10 BST 2012
[INFO] Final Memory: 3M/81M
[INFO] 

John

On 25 April 2012 10:44, copyto27 cop...@gmail.com wrote:
 Hi,

 searching in google i found the solutión for the error. but now i have a new
 error :(


 PS C:\CGSI\apache-maven-3.0.4\lib mvn install:install-file
 -Dfile=ojdbc6.jar -DgroupId=com.oracle -DartifactId=ojdbc6 -
 Dversion=11.1.0.7.0 -Dpackaging=jar -DgeneratePom=true
 [INFO] Scanning for projects...
 [INFO]
 [INFO]
 
 [INFO] Building ojdbc6 11.1.0.7.0
 [INFO]
 
 [INFO]
 [INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ ojdbc6
 ---
 [INFO] Installing C:\CGSI\apache-maven-3.0.4\lib\ojdbc6 to
 C:\Users\emeanavallin\.m2\repository\com\ojdbc6\11\ojdbc6-11.
 jar
 [INFO] Installing
 C:\Users\EMEANA~1\AppData\Local\Temp\mvninstall5076381426630896449.pom to
 C:\Users\emeanavallin\.m2\re
 pository\com\ojdbc6\11\ojdbc6-11.pom
 [INFO]
 [INFO]
 
 [INFO] Building ojdbc6 11.1.0.7.0
 [INFO]
 
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 0.862s
 [INFO] Finished at: Wed Apr 25 11:34:43 CEST 2012
 [INFO] Final Memory: 2M/15M
 [INFO]
 
 [ERROR] Unknown lifecycle phase .jar. You must specify a valid lifecycle
 phase or a goal in the format plugin-prefix
 :goal or plugin-group-id:plugin-artifact-id[:plugin-version]:goal.
 Available lifecycle phases are: validate, i
 nitialize, generate-sources, process-sources, generate-resources,
 process-resources, compile, process-classes, generate-
 test-sources, process-test-sources, generate-test-resources,
 process-test-resources, test-compile, process-test-classes,
  test, prepare-package, package, pre-integration-test, integration-test,
 post-integration-test, verify, install, deploy,
  pre-clean, clean, post-clean, pre-site, site, 

Re: Dynamically generating artefact contents

[John Patrick]

Additionally how would you be using these generated attributes?

In plugins?
Filtering files?
Other?

On 13 June 2012 09:46, Belhadj abdessalem belhadj.abdessa...@gmail.com wrote:
 what would you mean  *shortName would be an attribute that's derived from
 the artifact-ID   ?*

 2012/6/13 Jochen Wiedmann jochen.wiedm...@gmail.com

 Hi,

 I've got a need to generate several attributes of an artefact
 dynamically. For example, I'd like to be able to use something like

   ${shortName}

 where shortName would be an attribute that's derived from the
 artifact-ID, but not necessarily the same.

 Is that possible?

 Thanks,

 Jochen

 --
 Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja
 Buchung.
 Dieter Hildebrandt

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




 --
 Abdessalem BELHADJ
 Ingénieur en Informatique
 Direction des Etudes
 E-Mail : a.belh...@eugena.fr
 Tel : (+33) 06 36 28 78 89

 P Afin de contribuer au respect de l'environnement, merci de n'imprimer ce
 courriel que si nécessaire.

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

Re: Do releases _really_ need to be built with Java 1.5?

[John Patrick]

i guess it's the only way to definitely ensure backwards compatibility

open potential solution would be to use vagrant, I use it to ensure
developers as using the same base build setup and the files can be source
controlled



On 11 November 2013 22:39, Benson Margulies bimargul...@gmail.com wrote:


 http://maven.apache.org/developers/release/maven-project-release-procedure.html

 says so. I don't know where I'm going to get that environment.

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

Re: Running a plugin integration test from an IDE?

[John Patrick]

this might work and is what I get into the company/project root pom so
all developers can use the approach. create a debug profile and get
the tests to use is so you can debug in your preferred IDE. it doesn't
give you the nice red/green process bars and fancy output but it might
help you debug the running issue.

not tried it with the maven tests but i've used it for surefire and
failsafe before, so something like this might work for you.

1) create debug profile which is simply, and make it suspend yes so it
pauses till you connect your debugger otherwise you might miss the 1st
few tests executing

  debug
  
-Xdebug
-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y
  


2) setup a default version of the properties

   


3) change the maven-surefire-plugin and maven-failsafe-plugin to use
testing.args.debug

  org.apache.maven.plugins
  maven-surefire-plugin
  ...
  
... ${testing.args.debug}
   ...
  
  ..


John


On 16 February 2017 at 11:52, Igor Fedorenko  wrote:
> I don't use intellij, but if you are willing to try eclipse/m2e then
> there are at least two viable ways to implement "debuggable" integration
> tests. Personally I prefer takari plugin testing harness [1]
> (disclosure: I wrote the thing, so I am definitely biased).
> Alternatively, you can also use Maven Verifier [2] (this is what Maven
> core uses). Both ways to run integration tests are supported by my
> "Maven Development Tools" set of m2e extensions [3].
>
> [1] https://github.com/takari/takari-plugin-testing-project
> [2] http://maven.apache.org/shared/maven-verifier/
> [3] https://github.com/ifedorenko/com.ifedorenko.m2e.mavendev
>
> --
> Regards,
> Igor
>
> On Thu, Feb 16, 2017, at 04:03 AM, org.apache.maven.u...@io7m.com wrote:
>> On 2017-02-14T15:13:46 +
>> org.apache.maven.u...@io7m.com wrote:
>> >
>> > I can't work out how to run this integration
>> > test from an IDE (Intellij IDEA, in this case) so that I can try to
>> > step through the execution with a debugger and see what's going on.
>>
>> So nobody knows how to run an integration test from an IDE? How does
>> anyone debug problems via tests?
>>
>> M
>> Email had 1 attachment:
>> + Attachment2
>>   1k (application/pgp-signature)
>
> -
> 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

Taking Security Seriously

[John Patrick]

Hiya,

So currently checksum's are not generated by default... I've submitted
a ticket which switched the install plugin to generate them by
default.

Next step stop using md5 which most have considered dead for several
years, and checking apache
(https://www.apache.org/dev/release-signing.html) sha512 should be
being used.

So either;
1) add support so md5, sha1, sha256 and sha512 are all generated
2) plugin defines which is generated
3) plugin defines a list which are generated
4) settings.xml defines which is generated
5) settings.xml defines a list which are generated?

Thoughts???

Next;
Currently when downloading we have ignore, warn or error if checksum's
don't match. I propose adding a checksum min level options? i.e. allow
MD5 > SHA1, SHA256 > SHA512

So;
1) Default to MD5
2) Wait till all maven plugins deploy a sha512 to central
3) Switch default to SHA512

What are developers thoughts?
What staged steps should this be merged as?

I would like to start helping getting the core maven and all of it's
dependencies more secure so people can start trusting maven is secure
by default as I get the feeling isn't at the moment.

Cheers,
John

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

Re: Maven 4.0.0

[John Patrick]

I've got  a few updates I feel would be useful for the next major version;

1) Packaging type generic 'archive', or specific zip or tar.gz
- maybe a user property to enable zip and/or tar.gz

2) Packaging type generic 'application', or specific rpm or deb
- in future could be extended for windows installers too

Over the past 6 years I've mainly created jar, war or ear, but for
deployment the standard is bundle it up into a tar.gz or zip, along
with the ansible scripts or custom scripts. So I usually use pom
packaging then adding assembly plugin, just feels strange doing that
all the time and it might make it more simpler for everyone.

3) Checksum, switch to SHA3, drop md5 and sha1. If we care about
security, we should keep up to date with what is considered secure
still.

3) Debian style repo management. Instead of having a massive bucket of
artefacts, start having repo's either based upon java class version,
or maven major release version. Also split more than just release and
snapshot, maybe core, plugins, general...

Not sure exactly the best solution, but as maven central has stuff
going back years and years. How much of the old stuff will be used for
new projects going forward.

Anyway, those are some of my thoughts, if their is a more formal way
of suggesting them let me know and I'll be happy to raise them
separately for consideration and maybe also do some pull requests for
them.

John

On 4 November 2017 at 13:18, Paul Hammant  wrote:
>>
>>
>>
>> >
>> > *3. More pluggable dependency resolver:*
>> >
>>
>> I am willing to let this be optional scope for now. May be yanked if too
>> risky or not ready in time
>>
>>
>>
> I don't see how you can even make it optional without a pom specified way
> of saying "not maven central, this way/place instead"

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

Re: Speeding up Maven

[John Patrick]

Mark,
Your project on mine machine takes on average 2.5 second and that is
also doing a clean package each time, not just package.

Spec:
MacBook Pro (Retina, 13-inch, Late 2013)
Processor 2.8 GHz Intel Core i7
Memory 16 GB 1600 MHz DDR3
Disk 512GB SSD

$ java -version
java version "9.0.4"
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
$ mvn -version
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T19:49:05Z)
Maven home: /opt/local/share/java/maven3
Java version: 9.0.4, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.4", arch: "x86_64", family: "mac"
$ mvn -Dmaven.tests.skip=true -DskipTests=true clean package 2>&1
[INFO] Scanning for projects...
[INFO]
[INFO] -< com.io7m.minimal:com.io7m.minimal >--
[INFO] Building com.io7m.minimal 0.0.1
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ com.io7m.minimal ---
[INFO] Deleting /Users/john/projects/tmp/maven-minimal-20180413/target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
com.io7m.minimal ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/Users/john/projects/tmp/maven-minimal-20180413/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @
com.io7m.minimal ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding
UTF-8, i.e. build is platform dependent!
[INFO] Compiling 1 source file to
/Users/john/projects/tmp/maven-minimal-20180413/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources
(default-testResources) @ com.io7m.minimal ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/Users/john/projects/tmp/maven-minimal-20180413/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) @ com.io7m.minimal ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
com.io7m.minimal ---
[INFO] Tests are skipped.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ com.io7m.minimal ---
[INFO] Building jar:
/Users/john/projects/tmp/maven-minimal-20180413/target/com.io7m.minimal-0.0.1.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 2.515 s
[INFO] Finished at: 2018-04-14T11:13:18+01:00
[INFO] 
$ mvn -Dmaven.tests.skip=true -DskipTests=true clean package 2>&1
[INFO] Scanning for projects...
[INFO]
[INFO] -< com.io7m.minimal:com.io7m.minimal >--
[INFO] Building com.io7m.minimal 0.0.1
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ com.io7m.minimal ---
[INFO] Deleting /Users/john/projects/tmp/maven-minimal-20180413/target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
com.io7m.minimal ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/Users/john/projects/tmp/maven-minimal-20180413/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @
com.io7m.minimal ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding
UTF-8, i.e. build is platform dependent!
[INFO] Compiling 1 source file to
/Users/john/projects/tmp/maven-minimal-20180413/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources
(default-testResources) @ com.io7m.minimal ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/Users/john/projects/tmp/maven-minimal-20180413/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) @ com.io7m.minimal ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
com.io7m.minimal ---
[INFO] Tests are skipped.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ com.io7m.minimal ---
[INFO] Building jar:
/Users/john/projects/tmp/maven-minimal-20180413/target/com.io7m.minimal-0.0.1.jar
[INFO] 
[INFO] BUILD 

Re: I am wandering how you do guys debug maven?

[John Patrick]

simon,
been using maven since 2005 so 1.x something, so might be better way
as often i discover features added several releases ago that i simply
missed to kept using the old approach as it works and isn't broken.
Something like;

...

...
  
debug

5005

-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=${project.debug.port}

  
...

...


  ${project.debug.args}




then "mvn -Pdebug test" and surefire uses the argLine user property.
then if you want to change the port "mvn -Pdebug
-Dproject.debug.port=8000 test". the important part is suspend=y.

Reading the latest
https://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html,
then "mvn -Dmaven.surefire.debug test" should setup a debug port on
5005 but i've only just seen that in the latest documentation but i've
probably not looked at surefire documentation for debugging for maybe
6+ years.

John

On Fri, 12 Oct 2018 at 20:25, Simon Sheng  wrote:
>
> Hi John,
>
> I am trying the profile, but no matter 5005 or 8000 port, I can't start
> debug. Would you please give me more detail of this profile.
>
> I global search maven source code, only classworld pom file has debug
> profile.
>
> I am looking into the wrapper you mentioned.
>
> Thank you!
>
> Simon(ChengHong) Sheng
>
>
> On Tue, Oct 9, 2018 at 5:24 AM John Patrick  wrote:
>
> > others have talked about mvnDebug, i prefer using a profile e.g.
> > debug, then all the surefire and failsafe and exec-maven-plugin, plus
> > other plugins are all configured to use ${DEBUG_ARGS}, then;
> >
> > $ mvn -Pdebug test
> > $ mvn -Pdebug exec:java
> >
> > Then in intellij/eclipse/netbeans I can just connect a remote debugger
> > to the code. For some situations you want it to pause the execute
> > until your debugger is connected otherwise you might miss breakpoints
> > if those test are executed 1st.
> >
> > I've also switched to maven wrapper so don't have mvnDebug anymore as
> > it means developers don't need to keep their local machines in sync
> > and just do mvnw and it will sort out the maven version that
> > project/branch requires.
> >
> >
> > On Tue, 9 Oct 2018 at 06:29, Tibor Digana  wrote:
> > >
> > > In IntelliJ IDEA it is "Remote", see Select Run/Debug Configurations >
> > > Remote, change the port to 8000.
> > > Run command *mvnDebug test* and then start "Remote" in IDEA.
> > >
> > > On Tue, Oct 9, 2018 at 6:16 AM Romain Manni-Bucau  > >
> > > wrote:
> > >
> > > > Hello
> > > >
> > > > Not sure the question was about test classes - you got answers for
> > that ;)
> > > > - or maven and plugins themselves. If the last one, just replace "mvn"
> > by
> > > > "mvnDebug" in any command and remote debug on port 8000 in your IDE.
> > > >
> > > > Side note: if you check mvn script you will see maven has a main class
> > so
> > > > can be remote debugged as any java software ;)
> > > >
> > > > Le mar. 9 oct. 2018 05:44, Olivier Lamy  a écrit :
> > > >
> > > > > an other option is to use command line and the surefire option:
> > > > > -Dmaven.surefire.debug=true
> > > > > then you can have debug on port 5005 (look at your ide to start a
> > remote
> > > > > debug)
> > > > >
> > > > > On Tue, 9 Oct 2018 at 08:45, Enrico Olivelli 
> > > > wrote:
> > > > >
> > > > > > Il lun 8 ott 2018, 23:23 Jeff MAURY  ha
> > scritto:
> > > > > >
> > > > > > > M2e takes care of everything
> > > > > > >
> > > > > >
> > > > > > Same for Apache Netbeans :)
> > > > > >
> > > > > > Enrico
> > > > > >
> > > > > >
> > > > > > > Jeff
> > > > > > >
> > > > > > > Le lun. 8 oct. 2018 à 23:09, Simon Sheng 
> > a
> > > > > > écrit :
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I am bringing this baby question since Maven load all it's
> > classes
> > > > by
> > > > > > > > ClassWorlds. Which means it doesn't have "main method".
> > instead we
> > > > > > debug
> > > > > > > > everything by log, do we have other way like debug with any
> > IDE:
> > > > > > Eclipse,
> > > > > > > > Intellij etc. put breakpoints and debug step by step ?
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > Simon(ChengHong) Sheng
> > > > > > > >
> > > > > > >
> > > > > > --
> > > > > >
> > > > > >
> > > > > > -- Enrico Olivelli
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Olivier Lamy
> > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > > >
> > > >
> >
> > -
> > 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: I am wandering how you do guys debug maven?

[John Patrick]

but if you configure surefire or failsafe, of any other plugin that
supports fork to fork, it will be a new jvm, so it can get confusing
to debug maven when it's running like that.
On Sat, 13 Oct 2018 at 12:41, Karl Heinz Marbaise  wrote:
>
> Hi,
>
> On 08/10/18 23:08, Simon Sheng wrote:
> > Hi,
> >
> > I am bringing this baby question since Maven load all it's classes by
> > ClassWorlds. Which means it doesn't have "main method". instead we debug
> > everything by log, do we have other way like debug with any IDE: Eclipse,
> > Intellij etc. put breakpoints and debug step by step ?
>
> Maven has a main method it looks like this:
>
>
>  public static void main( String[] args )
>  {
>  int result = main( args, null );
>
>  System.exit( result );
>  }
>
>
> and is located in package: org.apache.maven.cli.MavenCli in module
> maven-embedder.
>
> where you can set a breakpoint...
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> 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: I am wandering how you do guys debug maven?

[John Patrick]

others have talked about mvnDebug, i prefer using a profile e.g.
debug, then all the surefire and failsafe and exec-maven-plugin, plus
other plugins are all configured to use ${DEBUG_ARGS}, then;

$ mvn -Pdebug test
$ mvn -Pdebug exec:java

Then in intellij/eclipse/netbeans I can just connect a remote debugger
to the code. For some situations you want it to pause the execute
until your debugger is connected otherwise you might miss breakpoints
if those test are executed 1st.

I've also switched to maven wrapper so don't have mvnDebug anymore as
it means developers don't need to keep their local machines in sync
and just do mvnw and it will sort out the maven version that
project/branch requires.


On Tue, 9 Oct 2018 at 06:29, Tibor Digana  wrote:
>
> In IntelliJ IDEA it is "Remote", see Select Run/Debug Configurations >
> Remote, change the port to 8000.
> Run command *mvnDebug test* and then start "Remote" in IDEA.
>
> On Tue, Oct 9, 2018 at 6:16 AM Romain Manni-Bucau 
> wrote:
>
> > Hello
> >
> > Not sure the question was about test classes - you got answers for that ;)
> > - or maven and plugins themselves. If the last one, just replace "mvn" by
> > "mvnDebug" in any command and remote debug on port 8000 in your IDE.
> >
> > Side note: if you check mvn script you will see maven has a main class so
> > can be remote debugged as any java software ;)
> >
> > Le mar. 9 oct. 2018 05:44, Olivier Lamy  a écrit :
> >
> > > an other option is to use command line and the surefire option:
> > > -Dmaven.surefire.debug=true
> > > then you can have debug on port 5005 (look at your ide to start a remote
> > > debug)
> > >
> > > On Tue, 9 Oct 2018 at 08:45, Enrico Olivelli 
> > wrote:
> > >
> > > > Il lun 8 ott 2018, 23:23 Jeff MAURY  ha scritto:
> > > >
> > > > > M2e takes care of everything
> > > > >
> > > >
> > > > Same for Apache Netbeans :)
> > > >
> > > > Enrico
> > > >
> > > >
> > > > > Jeff
> > > > >
> > > > > Le lun. 8 oct. 2018 à 23:09, Simon Sheng  a
> > > > écrit :
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am bringing this baby question since Maven load all it's classes
> > by
> > > > > > ClassWorlds. Which means it doesn't have "main method". instead we
> > > > debug
> > > > > > everything by log, do we have other way like debug with any IDE:
> > > > Eclipse,
> > > > > > Intellij etc. put breakpoints and debug step by step ?
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Simon(ChengHong) Sheng
> > > > > >
> > > > >
> > > > --
> > > >
> > > >
> > > > -- Enrico Olivelli
> > > >
> > >
> > >
> > > --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >

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

Re: [DISCUSS] Maven 3.7.0

[John Patrick]

Been using Maven since spring 2005, so really happy with Maven...

I work on legacy applications so I still build on Java 6 & 7
weekly/monthly, but mainly on Java 8 with so experimenting with Java
11.

My feedback and input would be;

1) Drop Pre Java 8 support
It would hurt my as I use it for projects stuck on Java 6 and 7, but
it would also give me business case for needing to upgrade these
projects to supported versions.

2) Dual Support for Java 8 and 11
Bump base version of Java 8 and use multi-release version jars so core
components/plugins and use new features where needed.
e.g.
META-INF/MANIFEST.MF (Automatic-Module-Name)
META-INF/versions/11/module-info.class (really support modules)

3) extend toolchains support for all plugins/phases
Currently having issues i.e. wanting to execute surefire/failsafe with
a specific version but having to hack build.

4) Separate repo rebuilt for each major/minor release
Similar to Debian/Ubuntu where each release gets it's own brand new
repo with everything rebuilt. Just wildcard idea.
So each major version gets a new repo, so 3.x, 4.x, 5.x. or 3.6.x,
3.7.x. Everything in this repo allows a basic project to build, i.e.
compile, jar, test, install and deploy. I fell if we don't do anything
in another 10 years maven central might be say 1 PB. We need to think
about a way of starting to drop old old versions, do we need all the
jars that are needed for a maven 2.x build still in central???
Not sure the best idea but think something like this needs working on.

John
Maven Enthusiasts and Evangelist

On Mon, 30 Sep 2019 at 21:21, Romain Manni-Bucau  wrote:
>
> +1 for java 8
> Java 7 dev will likely stick to already published versions since the
> ecosystem is already EOL anyway so no reason to not make maven java 8 based
> IMHO
>
> Le lun. 30 sept. 2019 à 22:16, Mickael Istria  a écrit :
>
> > On Sat, Sep 28, 2019 at 5:37 PM Mickael Istria  wrote:
> >
> > > I believe this reveals that some of the important Tycho tests are not
> > > performed against latest Maven snapshots.
> > >
> >
> > After a fix, the failures with polyglot build using more recent version of
> > Maven are now surfacing.
> > Too bad we didn't spot this missing configuration earlier, it would have
> > allowed to spot the regression against snapshot, before it get released...
> >
> >
> > --
> > Mickael Istria
> > Eclipse IDE 
> > developer, for Red Hat Developers 
> >

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

Re: Clarify why surefire filters tests (*Test/Test*)

[John Patrick]

I would argue the opposite, maven/surefire gives you configuration and
control over what to files to look at for tests, and potentially what
files to ignore/exclude.

IntelliJ is just a blunder bust for searching '*', but yes might be
seamed as more user friendly.

For some projects I've both surefire unit tests and failsafe
integration tests in 'src/test/java', but IntelliJ just executes both
and so often the integration tests fail as I've not setup the pre
reqs.

In large code bases it good to have tests within files names including
the word 'Test' as you might have other helper utils/classes also
within 'src/test/java' that support those tests. So when searching or
navigating the codebase you know which are which.

On Mon, 28 Oct 2019 at 13:54, Romain Manni-Bucau  wrote:
>
> Hi everyone,
>
> Today a colleague asked me why "FooWhateverBla" test was not executed with
> maven whereas it works well in Intellij.
>
> Indeed I explained him Surefire does its own scanning and the hardcoded
> defaults but I actually wonder why we still do that and if it is not just
> something inherited from early times.
>
> Concretely, scanning target/test-classes we can find all @[whatever
> package]Test (and meta @Test), subclasses of Specification or whatever
> parent etc. In other words the scanning can default to the supported
> providers (any other pattern is useless since it will not run anyway) and
> we can even just delegate the scanning to the underlying engine in a lot of
> cases.
> The gain is to drop code in surefire but also expose something more user
> friendly (aligned on the used engine).
>
> Any rational I'm missing to still have an abstraction there?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 

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

Re: Prefer Mockito?

[John Patrick]

Just did comment regarding typo.

I also advocate Mockito, so also would be recommending that.

It appeared Mockito supported junit v5 earlier than others and
compared to previous versions remove boiler plate setup. Or I missed
those other frameworks supporting junit v5.
PowerMock might be agued that is supports static, but most of the code
i've reviewed just highlight most developer mock static
classes/methods incorrectly and end up just verifying the mock they
create.
Not touched/used JMock or EasyMock for about 10 years so no idea about them.

John


On Mon, 27 Apr 2020 at 15:14, Elliotte Rusty Harold  wrote:
>
> Anyone have an opinion on recommending Mockito as our preferred mocking
> library?
>
> https://github.com/apache/maven-site/pull/158/files
>
> This doesn't require us to port old unit tests, though we can. Right now we
> have a mix of Mockito, JMock, PowerMock, and EasyMock spread out across the
> plugins.
>
> --
> 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

Re: source directory layout for multirelease jars

[John Patrick]

The structure which I want is;
src/main/java
src/main/java11
src/main/java14
src/test/java
src/test/java11
src/test/java14

I'm wanting to create a java 1.8 jar, with java 11 LTS support and the
latest release java version supported. So newer projects can use
modules and older projects still have a single jar they can depend
upon and choose when to upgrade within having to change and GAV
details.

Which the maven-compiler-plugin can handled, and produce a MR-JAR, but
the issues I've encountered are;
1) surefire doesn't support toolchain yet, believe is out in 3.0.0-M5
2) Bug since Java 9 and still in 14 regarding MR-JAR and JPMS, where
the root java version can't be 1.8, it must be 9 or newer. otherwise
so if your have java 1.8 and this java 11
/META-INF/versions/11/module-info.class, it would be valid for jar but
not for java or javac even if you specify -release 11.
3) IDE's can't handle different project subdirectories being different
java versions

I do like the new 6 month release cycles but i'm still feeling some
projects are yet to move from java 6, or 7 to even 8, so some issues
are yet to be found...

John


On Fri, 24 Apr 2020 at 17:06, Christian Stein  wrote:
>
> Robert (?) wrote this page [0] about supporting MR-JAR files.
>
> There're several approaches to the topic. It'd be nice, if the compiler- and
> the jar-plugin would pick one by default or based on a directory layout
> convention.
>
> [0]:
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
>
> On Fri, Apr 24, 2020 at 5:26 PM Elliotte Rusty Harold 
> wrote:
>
> > I've been thinking about multirelease jars. First step is source layout.
> > Here's a strawman modeled after the jar layout.
> >
> > We add a versions directory to the existing src directory. Inside the
> > versions directory one can have directories named 9, 10, 11, etc. for each
> > major Java version that has custom code. Each numbered directory is a full
> > src folder that contains main, test, etc.
> >
> >
> > Can anyone poke holes in this? Is there a reason why this wouldn't suffice?
> >
> > --
> > 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

Re: Speed of Maven build

[John Patrick]

Are you planning to create a baseline project or selecting a range of
projects to be used as a baseline, so that perceived improvements can
be monitored? So that anyone wanting to help out or give feedback can
submit their own build performance.

i.e.
1. Equipment OS, Ram, CPU, physical, virtual, docker, openshift, other
2. Java version
3. Maven version
4. Speedtest results
5. Direct Internet Connection or via Http Proxy or via Nexus/Artifactory
6. Clean/Fresh Local Repo Execution Time
7. 2nd Execution Time, after everything downloaded

As using Maven since 2005, I've found each new release has gotten
faster and faster, and most performance issues have been around what
OS I'm using, SSD vs HDD and also do you have enough free RAM etc.

As I'm surprised how quickly my builds are running at the moment, the
only issue is when I see maven perform internet connections
downloading new dependencies or say the versions plugin to check. Any
thoughts about adding a HTTP/2 Server Push support so if it's Maven
Aware and you request the pom it can also push back the hashes and
maybe the jar too.

Regarding a "zombie" maven instance, it should be opt in so i need to
explicitly enable it as often i'm jumping around between lots of
projects so don't want each having a "zombie" progress and i might not
be building that project again for another week maybe.

John

On Tue, 25 Aug 2020 at 12:27, Jeff Jensen
 wrote:
>
> In case this helps, Jason Dillon has a "Maven Shell" that does what you
> seek for CLI - launches a Maven instance and runs interactive commands with
> it, saving the startup time.
> https://github.com/jdillon/mvnsh
>
>
> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach 
> wrote:
>
> > > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > > I suppose that community would be happy to get such contributions.
> > >
> > > -Bertrand
> >
> > You are right, Bertrand. Why not ask!
> >
> > Hello Maven guys,
> > we had a discussion on the NetBeans mailing list recently and here is a
> > summary:
> > * Apache NetBeans IDE is delegating most of its work directly to Maven
> > * Users however complain that the speed isn't great
> > * One of the ideas was to launch a "zombie" instance of Maven in advance
> > * then actions like build, exec or test would be faster
> >
> > Have you thought about something like this already? Any advices?
> >
> > Best regards.
> > Jaroslav Tulach
> > NetBeans Platform Architect
> >
> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
> > jaroslav.tul...@gmail.com>
> > napsal:
> >
> > > > I agree with others, Ant is much faster day to day. But the pom.xml has
> > > > become the universal project file for Java,
> > >
> > > Thank you all for sharing your thoughts. I know Maven start is slower,
> > but
> > > I
> > > learned to live with it. It is interesting to hear that some of you
> > > maintain a
> > > dual Ant based copy of your project metadata. Once we were trying a
> > > different
> > > approach:
> > >
> > > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > > XML &
> > > co. files and stop it. As soon as we need to build/run/test, wake up this
> > > zombie Maven process, tell it what to do and let it continue. If the XML
> > > files
> > > are modified, throw the process away and initialize it again. Tomáš
> > Stupka
> > > implemented a prototype of this and there were no issues, as far as I
> > know
> > > (nobody tested it thoroughly however).
> > >
> > > Maybe the support is even in and there is a property to turn it on. If
> > the
> > > Maven startup is the biggest problem for you guys, we shall investigate
> > > how to
> > > turn Tomáš's work on...
> > >
> > > -jt
> > >
> > >
> > >
> > >
> > >
> > >
> >

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

Re: Moving hashes (checksums) forward

[John Patrick]

I also think a phase parallel rollout would be more useful, also
consider lots of projects still won't upgrade to java 8 because they
want to maintain backwards compatibility.

1. maven 3.7.0 add support for list of hashes, valid list, warning
list and banned list
2. maven 3.7.0 add sha-2 and sha-3 support
3. maven 3.7.0 generates md5, sha1, sha2 and sha3 by default
4. maven 3.7.0 warns if no sha-2 or sha-3 exists and having to use md5
or sha1 for validation
5. maven 4.0.0 stops generating md5 and sha1 hashes by default, users
can still opt for then to be generated
6. maven 4.0.0 error if no sha-2 or sha-3 exists and having to use md5
or sha1 for validation, user can still opt for then to be warning

i tried working out how to add sha-2 support about 5 years ago as a
pull request but it didn't go very far

I also think we need to change maven central to more like a debian
repo setup, core and 3rd party, with a new repo for each major
release, or are repo based upon the min version of java, so java 9,
10, 12, 13, 14, 15, 16, 18, 19, etc could be dropped 3-6 months after
that version of java is out of support. Maybe something else that
needs to be considered, as as nothing gets removed from maven central,
in another 5 or 10 years we might have jars that won't ever get used
again.

John

On Sun, 31 May 2020 at 19:42, Michael Osipov  wrote:
>
> Am 2020-05-31 um 18:46 schrieb Maarten Mulders:
> > Hi,
> >
> > It's great to see support for more secure hashing algorithms coming.
> >
> > At the risk of suggesting something that is already there, or is just
> > not feasible... Wouldn't it be possible to have a smoother transition by
> > allowing multiple hashes at the same time?
> >
> > When resolving, if there is a SHA-2 hash we use that for validation.
> > Otherwise, we use SHA-1 or MD5. We might log a warning about the fact
> > that a deprecated hashing algorithm is used. That way, repo managers
> > wouldn't necessarily need to re-hash all their content. On the other
> > hand, it might slow down the adoption of SHA-2 for content hashing.
>
> We already have multiple hashes in parallel and Resolver will traverse
> until no hash is found or the first one has failed.
>
> > On May 31, 2020, at 17:19, Robert Scholte wrote:
> >
> >> hi,
> >>
> >> I would be great if Sonatype could lead this request.
> >> It seems like a similar process compared to the TLSv1.2 requirement
> >> and the drop of http
> >> They have the best overview in how to handle the switch to different
> >> hashes.
> >> You can already start with #1, but until then I would be careful with #2
> >>
> >> thanks,
> >> Robert
> >>
> >> On 31-5-2020 16:58:58, Michael Osipov  wrote:
> >> Folks,
> >>
> >> I have been recently (indirectly) approached by Mark Thomas for the
> >> Tomcat committers that he wants to provide SHA-2 hashes for all uploaded
> >> Tomcat artifacts in Central. Since Nexus 2.14.18 supports this properly
> >> for validation, I have picked up MRESOLVER-56 and asked for testing.
> >>
> >> I'd like also to discuss two proposals for the Maven community:
> >> 1. Introduce SHA-2 support in Maven Resolver 1.4.3 which will go into
> >> Maven 3.7.0
> >> 2. Deprecate MD5 and SHA-1 with that release and make them obsolete with
> >> Maven 4.0 and Maven Resolver 2.0 which will include package change also.
> >>
> >> Those proposals have the following greater implications:
> >> 1.
> >> * Certain repo managers might reject hashes, they don't know. As did
> >> Nexus on repository.a.o.
> >> * This will incur two more requests with each upload and download. In
> >> the latter, it will fail with 404 because most repo managers won't have
> >> SHA-2 hashes. So fails Central for now. (will be solved with 2.)
> >>
> >> 2.
> >> * All repo managers will need to
> >> ** rehash all current content to provide SHA-2 hashes
> >> ** Require SHA-2 hashes to be uploaded
> >> ** Reject MD5 and SHA-1 hashes
> >> * Old tools will fail because MD5 and SHA-1 hashes are gone:
> >> ** Uploads will be rejected
> >> ** Strict download validation will fail
> >>
> >> Please comment. I will also provide a draft PR soon.
> >> I can cast two formal votes if required.
> >>
> >> Michael
> >>
> >> -
> >> 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
> >
>
>
> -
> 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: Absolute location of settings files help

[John Patrick]

thanks Falko, I've been able to raise the PR to enhance a plugin now.

John




On Sat, 25 Jul 2020 at 21:37, Falko Modler  wrote:
>
> Inject the MavenSession:
>
> @Parameter(defaultValue ="${session}", readonly = true)
> private  MavenSession mavenSession;
>
> and then:
>
> mavenSession.getRequest() -> getUserSettingsFile() or getGlobalSettingsFile()
>
>
> Cheers,
>
> Falko
>
> Am 23.07.2020 um 13:42 schrieb John Patrick:
> >  From within a plugin, how can I obtain the global settings and user 
> > settings???
> >
> > Not the effective settings object, the real location of the files
> > being used, so what SettingsXmlConfigurationProcessor works out.
> >
> > I've worked out that either MavenExecutionRequest or
> > SettingsBuildingRequest contain this information, but can't work out
> > how to get access to these from within the plugin.
> >
> > Is there a method or interface or annotation that I can use, or do I
> > need to register for the EventSpyDispatcher?
> >
> > I've looked in most org.apache.maven.plugins but can't find what I'm
> > looking for. Google just gives me the source or javadoc of these files
> > and stackoverflow gives irrelevant answers.
> >
> > Cheers,
> > John
> >
> > -
> > 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: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[John Patrick]

What is the best forum to discuss issues or configuration around
compiler, surefire and jpms?

Most of the issues I have, seam to be resolved with 3.0.0-M5, but;
- already raising issue with IntelliJ now as they don't support 2
module-info.java files in the same project, one under src/main/java
and the other under src/test/java.
- how can package private methods be tested? as compiler is now seeing
the new test module-info.java but complaining about package exists in
main and test module-info.
- i might be making things more complex as i've using src/main/java
and src/test/java for java 8 code, and src/main/java11 and
src/test/java11 for java 11 code base. so creating multi version jars.
java 8 builds an tests, then java 11 does verify, i then rebuild and
test fully on java 11.

John


On Sat, 13 Jun 2020 at 23:40, Tibor Digana  wrote:
>
> Hi Herve,
>
> We can fork the discussion about this problem apart in the Slack.
> Thx for finding this.
>
> T
>
>
> On Sat, Jun 13, 2020 at 9:35 PM Hervé BOUTEMY  wrote:
>
> > +1
> >
> > near full reproducibility of reference artifacts with JDK 8 on Windows: 48
> > artifacts are ok, just 2 still have issues:
> > - surefire-3.0.0-M5-source-release.zip: I don't know why my local build
> > added 3 dependency-reduced-pom.xml that do not exist in reference build
> > - surefire-shadefire-3.0.0-M5.jar: some strange timestamp issues for some
> > shaded content, probably a subtle maven-shade-plugin bug
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 13 juin 2020, 15:46:10 CEST Tibor Digana a écrit :
> > > Hi,
> > >
> > > We solved 40 issues:
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927
> > > rsion=12344612
> > >
> > > There are still a couple of issues left in JIRA:
> > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20
> > > status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1590/
> > >
> > https://repository.apache.org/content/repositories/maven-1590/org/apache/mav
> > > en/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
> > >
> > > Source release checksum(s):
> > > surefire-3.0.0-M5-source-release.zip  sha1:
> > > 687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
> > > surefire-3.0.0-M5-source-release.zip  sha512:
> > >
> > e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f0
> > > 91081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7
> > >
> > > Staging site:
> > > http://maven.apache.org/surefire-archives/surefire-LATEST/
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > Cheers
> > > Tibor
> >
> >
> >
> >
> >
> > -
> > 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

Absolute location of settings files help

[John Patrick]

>From within a plugin, how can I obtain the global settings and user settings???

Not the effective settings object, the real location of the files
being used, so what SettingsXmlConfigurationProcessor works out.

I've worked out that either MavenExecutionRequest or
SettingsBuildingRequest contain this information, but can't work out
how to get access to these from within the plugin.

Is there a method or interface or annotation that I can use, or do I
need to register for the EventSpyDispatcher?

I've looked in most org.apache.maven.plugins but can't find what I'm
looking for. Google just gives me the source or javadoc of these files
and stackoverflow gives irrelevant answers.

Cheers,
John

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

Re: Assumption fail treated as unexcepted exception?!

[John Patrick]

If the code working out the assumption fails and causes a throwable,
either Runtime or Checked, I would expect the test to fail.
If you have a line something like below, and that causes a test error,
then that feels wrong as it's a valid assumption.
Assumptions.assumeFalse("ABC".equals("ABC"), "message");

But if you had below, which would throw an NPE, then that should error
as it's a badly coded assumption logic.
String IS_NULL = null;
Assumptions.assumeFalse(IS_NULL.equals("ABC"), "message");

So without seeing the test involved it's hard to tell if it's correct or not.

John

On Sun, 16 Aug 2020 at 13:31, Martin Gainty  wrote:
>
> MG>below
>
> 
> From: Markus KARG 
> Sent: Sunday, August 16, 2020 7:40 AM
> To: dev@maven.apache.org 
> Subject: Assumption fail treated as unexcepted exception?!
>
> Guys,
>
>
>
> I'm stuck with working on a new feature due to this, so I hope you can help
> me quickly:
>
>
>
> JUnit knows assumptions, assertions and exceptions. Failing assertions will
> FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
> tests (hence will pass maven builds). Exceptions will ERROR tests (hence
> will break maven builds). Unfortunately today I noticed that assumptions
> actually ERROR test (hence fail builds) in Maven!
>
>
>
> (I simply added another test to maven dependency plugin which contains an
> always-failing assumption to proof the claim)
>
>
>
> [INFO] Results:
>
> [INFO]
>
> [ERROR] Errors:
>
> [ERROR]   TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
>
> MG>get maven environment and debug information
> MG>mvn -e -X
> MG>also I know Junit 5.4.2 needs Hamcrest to be on classpath
> MG>can you tell us which version of Junit you are using?
>
> -Markus Karg
> ~gruss~
> ~martin~
>
>
>
>
>

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

Re: Apache Maven Software

[John Patrick]

Hi Keith,

If you look at the historic releases, once a minor version has been bumped
there have been no more releases to the previous minor version for 3.x, see
https://maven.apache.org/docs/history.html

For major version releases, maven 1 and maven 2 did have an overlap where
1.1 got released after 2.0.7. But the same overlapping releases didn't
happen for maven 2 and maven 3.

You mention the current version 3.5.3. I considered 3.5.x tech debt and out
of support already. I upgraded from 3.5.3 to 3.6.1 upon its release and it
worked for my projects, so I skipped 3.6.0 as during testing of 3.6.0 it
had some issues with some projects so didn't upgrade. Also upgrading little
and often means a tidal wave of tech debt doesn't build up so you're only
spending 5% on going upgrading, instead of having to spend 100% for a few
weeks/months/year taking out new functionality.

Personally I consider all Open Source projects to be Rolling Support even
if they don't explicitly state that. As most volunteers probably won't be
interested in backporting bug fixes or investigating issues with older
releases where that works on the latest release. Even with commercial
support, my experience of Oracle support for WebLogic was the first
question they asked was have you upgraded to the latest maintenance release
and does it still have issues. But at least with Oracle if you have paid
for support they will investigate the version you need to use if you're not
able to upgrade.

Sorry it's not a definitive answer regarding v3.5.3 support. I'm working in
a similar situation where software versions where older than they should
have been and tech debt was left for far longer than it should have been,
so most projects are just upgrades at the moment.

John


On Thu, 26 Nov 2020 at 05:19, Bernd Eckenfels 
wrote:

> Hello Keith,
>
> Apache is a volunteer driven organisation, as long as volunteers,
> including your Organisation contribute patches (and funding) the software
> is supported. There is no guarantee or contract you can obtain for that.
>
> You haven’t specified which projects (plugins) in particular you are
> interested in, however the general maven project is not planning to stop
> development. Some older versions however might not be actively maintained
> anymore, and it is always a good idea to stay with the latest release.
>
> Maven 3.6.3 is recent, so I would not expect any more releases in the
> Maven 3.5.x line. (However as already explained, if enough organizations
> invest the time and produce a critical fix, together with this free
> development community, why not. It would be however much easier to just
> upgrade)
>
> Gruss
> Bernd
> (An unofficial bystander, triggered by formal requests)
> --
> http://bernd.eckenfels.net
>
> 
> Von: Crawford, Keith K CIV USARMY SEC (USA)
> 
> Gesendet: Donnerstag, November 26, 2020 12:49 AM
> An: dev@maven.apache.org
> Betreff: Apache Maven Software
>
> Maven Support,
>
> We are going through the Assess Only process of licensed and open source
> client software for Information Assurance.  As part of the package we must
> submit dates for support End of Support for current version 3.5.3, not just
> the release date.  We need this information to install and use this
> software, required by our developers in support of multiple programs.  Can
> you provide support or End of Support dates for Apache Maven 3.5.3, please?
>
> V/r,
>
> Keith Crawford
> Enterprise Architect
> Technical Services Branch
> Technical Operations Division
> Army Shared Services Center
> CECOM Software Engineering Center (SEC)
>
> ☎ (804) 734 - 5204Feldman Hall
>  (804) 892 - 5759Govt Mobile
> ✉ keith.k.crawford@mail.mil
>
>
>
>
>

Re: [DISCUSS] Allow attributes shorthand in pom.xml

[John Patrick]

I'm with you on that, yes xml is considered old, and legacy, and
verbose. But it's got a decent validation framework, people understand
an xsd and so write a valid xml file based upon the xsd.

With json i'm unaware of any standard validation framework and schema
definition standard.


On Sat, 12 Dec 2020 at 11:46, Michael Osipov  wrote:
>
> Am 2020-12-12 um 11:04 schrieb Markus KARG:
> > Wouldn't it be a more modern and even more effective approach to add JSON 
> > support for POMs? We could keep POM.xml for legacy reasons but add support 
> > for POM.json files.
>
> NOO, please! JSON is horribly to write by hand and does not have
> comments. It is a decent serialization format, but a horrible one for
> humans. I would rather prefer YAML for this.
>
> > -Ursprüngliche Nachricht-
> > Von: Will Iverson [mailto:wiver...@gmail.com]
> > Gesendet: Freitag, 11. Dezember 2020 23:40
> > An: dev@maven.apache.org
> > Betreff: [DISCUSS] Allow attributes shorthand in pom.xml
> >
> > One of the biggest complaints about Maven has long been the verbosity of
> > the XML format. The verbosity is due in large part to the exclusive
> > reliance on XML elements in Maven.
> >
> > Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
> > declaring configuration elements.
> >
> > Example: One of the most verbose sections of the pom for most projects is
> > dependencies. A typical example:
> >
> > 
> > commons-io
> > commons-io
> > 2.8.0
> > 
> >
> > Here is the same declaration expressed with attribute shortcuts:
> >
> > 
> > That's an 80% reduction in LoC, and would make Maven comparable with other
> > popular build tools (e.g. compare and contrast with other build tools at
> > https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)
> >
> > REQUEST: Feedback on if this is something to pursue. I've done some
> > research, happy to submit patches, but don't want to pursue if there is
> > either a) technical reason[s] not to proceed I'm not aware of or b) a lack
> > of enthusiasm for the entire idea from the community.
> >
> > Basically, I'm looking for some feedback along the lines of a) love it -
> > please submit patches so we can check it out, b) huh, maybe, willing to
> > look at it, or c) this is a terrible idea, because X. Effectively, a
> > totally non-binding vote on if this is worth exploring.
> >
> > I've discussed this with others online and done some research, so are a few
> > answers to objections/Qs as I currently understand. I may be
> > wrong/uninformed about certain aspects, which would be very helpful
> > feedback.
> >
> > Q: Won't this require a new Maven XSD to be generated?
> > A: No. The current Maven XSD declares many elements, but is not actually
> > involved in validation. While the current XSD is valuable for tools and
> > documentation, it does not actually perform validation.
> >
> > Q: Wait, so what actually does the validation?
> > A: It's all done in Java code generated by Modello. The maven-model project
> > (https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
> > the Modello Maven Plugin (
> > http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
> > turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
> > generate the Java code that processes the pom.xml
> >
> > The proposal is to submit a patch for Modello that would allow the
> > generated source to accept an attribute as an alias for input. If it's a
> > valid element per the Maven maven.mdo file (
> > https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
> > it will now accept an attribute as a shortcut.
> >
> > Q: Wouldn't this break, like, everything?
> > A: It would only affect pom.xml files that are read at runtime. All emitted
> > pom.xml files would remain exactly the same.
> >
> > Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
> > the thing that's making it hard to support alternative formats for pom.xml
> > like polyglot poms, etc?
> > A: Nope, the pom.xml on disk is still the pom.xml. A
> > X.X.X would be the only flag
> > recommended to declare that a pom.xml uses attributes for shorthand.
> >
> > Q: How much work is this to actually implement?
> > A: It starts with a few lines added to the Modello code generation to allow
> > for attribute aliasing with a feature flag. Testing those changes through
> > the rest of the dependency chain. Adding test cases throughout.
> > Documentation. although as "now you can use attributes" is conceptually
> > simple it's not too bad. Tools in the Maven ecosystem would be able to
> > indicate they have been updated to support this by referring to the simple
> > term, "attribute shortcuts". Because nothing else changes, the only real
> > documentation change would be "things that were elements can also be
> > declared as attributes." The trickiest part is probably sorting out how to
> > manage the feature flag across the various components. I'm 

Re: Build windows-jdk15

[John Patrick]

Better to know the issues and slowly fix them then get hit with a load
of issues blocking users.

Unlike the 1st 20 years of Java where deprecated didn't really mean
anything at all... Since Java 9 the guidelines are 1 release with
deprecation warning and then things can be
removed/dropped/delete/refactored in the following release. So we got
use to probably ignoring those warnings and we probably now need to
pay attention.

I know I would prefer refactoring code with warnings instead of
refactoring code with errors.

Also in 6 months time Java 18 EA will be branched from the Java 17
Release Candidate... Potentially it could drop support for bytecode
version 54.0 and older as why have support for more than 2 LTS
versions (11 and 17)...

John


John

On Wed, 30 Dec 2020 at 14:22, Markus KARG  wrote:
>
> Well, whether or not switching off a build platform should more be a question 
> of: Why have we switched it on actually?
>
> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: Gary Gregory [mailto:garydgreg...@gmail.com]
> Gesendet: Mittwoch, 30. Dezember 2020 15:14
> An: Maven Developers List
> Betreff: Re: Build windows-jdk15
>
> FWIW, it might be worth switching that Java 15/16-EA build to 17-EA since
> 17 will be LTS.
>
> FYI, over at Apache Commons, we've found and reported bugs in Java 15 that
> have been fixed in 16-EA but that won't be back ported to 15.
>
> Gary
>
>
> On Wed, Dec 30, 2020, 08:59 Elliotte Rusty Harold 
> wrote:
>
> > The Windows JDK 15 instance in jenkins seems irredeemably flaky. It
> > fails more often than not for reasons that have nothing to do with the
> > code being tested.
> >
> > As JDK 15 is not a long term support release, and has only minimal
> > adoption, can we simply turn off the Windows JDK 15 build?
> >
> > Personally, I'd love to turn off all JDK 15 and 16 builds, but Windows
> > JDK 15 is by far the worst.
> >
> > --
> > 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
> >
> >
>
>
> -
> 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: [ANN] Apache Maven 3.8.1 Released

[John Patrick]

Does the Maven Wrapper need to be release/upgraded at the same time as
core Maven?

I was using takari maven wrapper, so did this to upgrade;
$ ./mvnw -N io.takari:maven:0.7.7:wrapper -Dmaven=3.8.1

>From what I can tell everything still works with Takari v0.7.7 and Maven 
>v3.8.1.

I then wanted to switch to Maven Wrapper as this was down for a Maven
v3.7.0 release as per
(https://maven.apache.org/plugins/maven-wrapper-plugin/index.html).

So I did this as documented here
(https://maven.apache.org/plugins/maven-wrapper-plugin/wrapper-mojo.html)
and get the following missing dependency;
$ ./mvnw org.apache.maven.plugins:maven-wrapper-plugin:3.0.1:wrapper
...
[INFO] --- maven-wrapper-plugin:3.0.1:wrapper (default-cli) @ PROJECT ---
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven-wrapper/3.8.1/apache-maven-wrapper-3.8.1.pom
[WARNING] The POM for
org.apache.maven:apache-maven-wrapper:zip:script:3.8.1 is missing, no
dependency information available
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven-wrapper/3.8.1/apache-maven-wrapper-3.8.1-script.zip
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  1.678 s
[INFO] Finished at: 2021-04-05T11:12:02+01:00
[INFO] 
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-wrapper-plugin:3.0.1:wrapper
(default-cli) on project PROJECT: Could not find artifact
org.apache.maven:apache-maven-wrapper:zip:script:3.8.1 in central
(https://repo.maven.apache.org/maven2) -> [Help 1]
$

Because it's got a 3.8.1 version number I would assume it should be
release at the same time as core Maven.

John

On Sun, 4 Apr 2021 at 19:14, Robert Scholte  wrote:
>
> The Apache Maven team is pleased to announce the release of the Apache Maven 
> 3.8.1
>
> Apache Maven is a software project management and comprehension tool. Based 
> on the concept
> of a project object model (POM), Maven can manage a project's build, 
> reporting and documentation
> from a central piece of information.
>
> Maven 3.8.1 is available via https://maven.apache.org/download.cgi
>
> The core release is independent of plugin releases. Further releases of 
> plugins will be made
> separately.
>
> If you have any questions, please consult:
>
> - the web site: https://maven.apache.org/
> - the maven-user mailing list: https://maven.apache.org/mailing-lists.html
> - the reference documentation: https://maven.apache.org/ref/3.8.1/
>
> RELEASE DETAILS
>
> This release with CVE fixes is a result based on the findings and feedback of 
> Jonathan Leitschuh and Olaf Flebbe.
>
> One of the changes that might impact your builds is the way custom 
> repositories defined in dependency POMs will be handled.
> By default external insecure repositories will now be blocked (localhost over 
> HTTP will still work).
> Configuration can be adjusted via the conf/settings.xml.
>
> Release Notes - Maven - Version 3.8.1
>
> ** Bug
>
> * [MNG-7128] - improve error message when blocked repository defined in 
> build POM
>
> ** New Feature
>
> * [MNG-7116] - Add support for mirror selector on external:http:*
> * [MNG-7117] - Add support for blocking mirrors
> * [MNG-7118] - Block external HTTP repositories by default
>
> ** Dependency upgrade
> * [MNG-7119] - Upgrade Maven Wagon to 3.4.3
> * [MNG-7123] - Upgrade Maven Resolver to 1.6.2
>
> For more information read 
> https://maven.apache.org/docs/3.8.1/release-notes.html
>
> Enjoy!
>
> - The Maven Team

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

Re: Maven Dependency Plugin - Log4j vulnerabilities

[John Patrick]

You might need to raise a bug with your security scanner regarding false
positives.

So your dependency tree I only see log4j 2.17.1; i.e.

Your Pom
- org.springframework.boot:spring-boot-starter-web:2.6.4
-- org.springframework.boot:spring-boot-starter-web:2.6.4
--- org.springframework.boot:spring-boot-starter:2.6.4
 org.springframework.boot:spring-boot-starter-logging:2.6.4
- org.apache.logging.log4j:log4j-to-slf4j:2.17.1
-- org.apache.logging.log4j:log4j-api:2.17.1

Doing a build "mvn clean install -Dmaven.repo.local=repo"
Then "find repo -name "*log4j*" -type f", only returns;
repo/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.jar
repo/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.pom.sha1
repo/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.pom
repo/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.jar.sha1
repo/org/apache/logging/log4j/log4j-to-slf4j/2.17.1/log4j-to-slf4j-2.17.1.pom
repo/org/apache/logging/log4j/log4j-to-slf4j/2.17.1/log4j-to-slf4j-2.17.1.pom.sha1
repo/org/apache/logging/log4j/log4j-to-slf4j/2.17.1/log4j-to-slf4j-2.17.1.jar
repo/org/apache/logging/log4j/log4j-to-slf4j/2.17.1/log4j-to-slf4j-2.17.1.jar.sha1
repo/org/apache/logging/log4j/log4j-bom/2.17.1/log4j-bom-2.17.1.pom
repo/org/apache/logging/log4j/log4j-bom/2.17.1/log4j-bom-2.17.1.pom.sha1
repo/org/apache/logging/log4j/log4j/2.17.1/log4j-2.17.1.pom.sha1
repo/org/apache/logging/log4j/log4j/2.17.1/log4j-2.17.1.pom
repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1

What version does the scanner say its found?

John


On Mon, 28 Feb 2022 at 23:15, Juraj Veverka
 wrote:

> Hi David
>
> Just for clarification: we are not relying on the maven dependency plugin
> at runtime. Our runtime is perfectly clear of log4j vulnerabilities.
> The problem is that our security scanners are scanning gitlab runner nodes
> (virtual machines on which we compile and package our application) and
> log4j vulnerability is found there.
>
> Kind regards
> Juraj Veverka
>
> On Mon, Feb 28, 2022 at 1:32 PM Juraj Veverka <
> juraj.veve...@globallogic.com>
> wrote:
>
> > Hi David
> >
> > Many thanks for your email, I really appreciate your reply. This is an
> > isolated example of the problem.
> > https://github.com/jveverka/mvn-dependency-log4j
> > You can find all repro steps there. In case of any questions, feel free
> > to contact me.
> >
> > Kind regards
> > Juraj Veverka
> >
> >
> >
> > On Mon, Feb 28, 2022 at 12:14 PM David Milet 
> > wrote:
> >
> >> Where I work we decided to address log4j vulnerabilities only for
> >> components directly used by the application and actually performing
> logging.
> >> We ignored transitive dependencies and maven plug-ins.
> >> I’m curious about this use case from Venu though, what application would
> >> rely on the maven dependency plugin at runtime? Does it mean you’re
> pulling
> >> maven dependencies after application startup?
> >>
> >> > On Feb 28, 2022, at 03:30, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > Please provide more information, like plugin, mven, os version.
> >> >
> >> > We also need an example project which reproduces your issue.
> >> > When we can't reproduce we can't help.
> >> >
> >> > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
> >> >  napisał(a):
> >> >
> >> >> Hi team,
> >> >>
> >> >> Can I expect any response?  Is this the right email address for my
> >> >> question?
> >> >>
> >> >> Thanks,
> >> >> Venu
> >> >>
> >> >>
> >> >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> >> >>> jaladi.venumad...@verizon.com> wrote:
> >> >>>
> >> >>> Hi team,
> >> >>>
> >> >>> We are using the Maven Dependency Plugin in one of our projects and
> >> our
> >> >>> scanning tools are showing multiple vulnerabilities related to Log4j
> >> >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> >> >>> CVE-2022-23307 and CVE-2021-4104).
> >> >>>
> >> >>> We would  like to know if there are any plans to release a newer
> >> version
> >> >>> of Maven Dependency Plugin with the fixes of these
> >> >>> vulnerabilities(referring to the latest version of Log4j libraries).
> >> If
> >> >>> so, is there any planned date for this release?
> >> >>>
> >> >>> Please let us know any any more information is required.
> >> >>>
> >> >>> Thanks,
> >> >>> Venu
> >> >>>
> >> >>
> >> >
> >> >
> >> > --
> >> > Sławomir Jaranowski
> >>
> >>
> >
> > --
> >
> > Best Regards
> >
> >
> > --
> >
> > Juraj Veverka  | Solution Design Architect
> >
> > M +421 917 521 285
> >
> > www.globallogic.sk  
> >
> >    [image: GLTwitter]
> > 
> > 
> > 
> > 
> >
> > 

Re: Maven Dependency Plugin - Log4j vulnerabilities

[John Patrick]

Sorry I thought you where talking about log4j v2, not v1. I can see it
downloads the metadata about the project but non or the jars;
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j/log4j/1.2.12/_remote.repositories

So I would still say false positive, as the jar is not actually used.

But looking at the dependency tree it would need the apache commons to
update commons-logging:commons-logging, then
ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
then it gets to the 1st dependency within the maven ecosystem.
So 5 ish patches to 5 separate projects to upgrade, test and release, each
before then next pr can progress.

John


On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:

> That was just to demonstrate how i got the dependency chain, that file
> was there, but if you're going to be this hostile, i'm not interested
> anymore, muting thread
>
> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> wrote:
> >
> > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > >
> > > Can confirm this project downloads log4j 1.12.12 for me
> >
> > As I see it - you confirm something else.
> >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> >
> > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > _artifact descriptor_
> >
> > --
> > Piotrek
> >
> > -
> > 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
>
>

Trying Maven v4

[John Patrick]

Hi,
If I want to start testing maven v4.x is it the master branch or the mvn4
branch I need to build?
Or is there a guide I can look at with current/known issues or work arounds?

I've a few issues/features I would like to raise and see if I can do
patches for, mostly more profile options like for;
settings.xml profile support for servers and mirrors.
extensions.xml profile support for extensions.
profile activation based upon other profiles being active or disabled.

i.e. the com.soebes.maven.extensions:maven-buildtime-profiler is good to
look into high build times, but for day to day usage I don't want every
developer or cicd build with the extra overhead or verbose output. Just
want it on release builds or when a developer enables a specific profile.

Someone with a home office nexus so has a * to their
own proxy, then whilst at a conference want to build they need to change
their default settings.xml to remove that mirror. I've 4 settings.xml
depending if home, travelling, in office or building from a maven staging
repo like maven-1731 (for surefire v3.0.0-M6).

All things just seam simpler switching different profiles.

Cheers,
John

Re: --no-transfer-progress might be causing the some tests to fail

[John Patrick]

I would be asking what version of maven are you using? what java version?
Could you try upgrading to the latest maven version.
Could you try upgrading to the latest of all plugins being used.

My standard maven options for cicd are "--batch-mode --no-transfer-progress
--show-version -fae -U" and never seen and issue like that personally.

John


On Wed, 19 Jan 2022 at 19:42, Karl Heinz Marbaise  wrote:

> Hi,
>
> it sounds like a subject for the users mailing list and not for the dev
> list.
>
>
> On 18.01.22 15:27, Janardhan Pulivarthi wrote:
> > Hi Maven team,
> >
> > A test is failing consistently for us when maven build is triggered
> > along with --no-transfer-progress option.
>
> do you have a full example of such case?
>
> Otherwise it's impossilbe to even speculate...
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > We are using the following operation to build a jar, against which the
> > test was run:
> >
> > mvn --no-transfer-progress clean package -P distribution
> >
> > Thank you,
> > Janardhan
> >
> > -
> > 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
>
>

Developing Maven within an IDE

[John Patrick]

Having trouble running Maven Core with in an IDE.

I've tried all the pages under
https://maven.apache.org/guides/development/guide-maven-development.html
but nothing specific about running within an IDE.

I'm trying to use IntelliJ and get the following output.
/Library/Java/JavaVirtualMachines/jdk1.8.0_341.jdk/Contents/Home/bin/java
... org.apache.maven.cli.MavenCli -ep
-Dmaven.multiModuleProjectDirectory system property is not set.
Process finished with exit code 1

I'm trying to launch org.apache.maven.cli.MavenCli
I'm setting the working directory to where my test pom is.

Any useful pages that might be good to look at?

John