Re: [EXTERNAL] https://www.mojohaus.org is down?

[James Klo]

Probably here: https://github.com/mojohaus/versions-maven-plugin 


Jim Klo
Senior Software Engineer
SRI International

> On Apr 29, 2021, at 1:25 PM, Niels Basjes  wrote:
> 
> Hi,
> 
> Just now I wanted to lookup the documentation for the versions-maven-plugin
> yet I found that website 
> https://urldefense.us/v3/__https://www.mojohaus.org/versions-maven-plugin/__;!!Nv3xtKNH_4uope0!wZbTk9uK9eKJllFXrhFXZPfN68n4jkjneH1wXBDO5-Tw-VzJVbTvS7dST7QJ$
>   to
> be offline (or more precise: I get a github error).
> 
> I have no clue where to report this (other than this mailing list).
> 
> -- 
> Best regards / Met vriendelijke groeten,
> 
> Niels Basjes



smime.p7s
Description: S/MIME cryptographic signature

Re: [External Sender] [VOTE] Retire Maven Downloader

[James Klo]

+1

> On Jun 7, 2019, at 6:32 AM, Robert Scholte  wrote:
> 
> Hi,
> 
> The Apache Maven project consist of about 90 (sub)projects. Due to the small 
> number of volunteers and the huge amount of code to maintain we're missing 
> enough space to make real progress on all these projects, including our 
> ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects 
> and decide if it is worth maintaining.
> 
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fshared%2Fmaven-downloader%2Fdata=01%7C01%7Cjim.klo%40sri.com%7C0afd8fb5ea5b4316351908d6eb4ca581%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=T%2BRz91kAba6bSJIA6o5zxvyb0f2NJ2eXyEi0hLwLeoc%3Dreserved=0
>  
> [https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fshared%2Fmaven-downloader%2Fdata=01%7C01%7Cjim.klo%40sri.com%7C0afd8fb5ea5b4316351908d6eb4ca581%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=T%2BRz91kAba6bSJIA6o5zxvyb0f2NJ2eXyEi0hLwLeoc%3Dreserved=0]
>  describes the main purpose in one line: Provide a super simple interface for 
> downloading a single artifact. Well, right now the preferred library to do so 
> is either maven-resolver or maven-artifact-transfer. 
> There have been only 2 releases, the last one was in December 2006.
> 
> I therefore propose that we retire the maven-downloader.
> 
> I don't think it makes sense to do a final release. Instead we should update 
> the documentation and freeze the codebase.
> 
> The process for retiring a plugin is described here:
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fdevelopers%2Fretirement-plan-plugins.htmldata=01%7C01%7Cjim.klo%40sri.com%7C0afd8fb5ea5b4316351908d6eb4ca581%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=4vHJozPU2j%2FT9iQx2H1G9NFfjyH4MdI3od%2F3G%2BiAkMc%3Dreserved=0
>  
> [https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fdevelopers%2Fretirement-plan-plugins.htmldata=01%7C01%7Cjim.klo%40sri.com%7C0afd8fb5ea5b4316351908d6eb4ca581%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=4vHJozPU2j%2FT9iQx2H1G9NFfjyH4MdI3od%2F3G%2BiAkMc%3Dreserved=0]
>  
> 
> The vote is open for 72 hours.
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
> 
> 
> 

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

Re: Blacklisted IP address

[James Klo]

I’d start with your IT admin. 

We have a corporate firewall that occasionally blacklists things like maven 
central, Github, and sourceforge.  

Sent from my iPhone

> On Aug 31, 2018, at 1:58 PM, Pavel Zaytsev  wrote:
> 
> Hello,
> 
> I cannot access 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo1.maven.orgdata=01%7C01%7Cjim.klo%40sri.com%7C19e93166a6734bff894708d60f8470ed%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=OGu%2BhkPhqqeUIxxV2qb5KSvo%2FXLgA5l5%2F2wSnEONZQ4%3Dreserved=0
>  when I am using this IP address: 
> 52.200.38.100
> When I try, I get this kind of error:
> 
> Resolving repo1.maven.org (repo1.maven.org)... 151.101.200.209
> Connecting to repo1.maven.org (repo1.maven.org)|151.101.200.209|:443... 
> connected.
> HTTP request sent, awaiting response... 403 Forbidden
> 2018-08-31 20:00:17 ERROR 403: Forbidden.
> 
> Could you help me or tell me who I should contact please? 
> 
> Regards,
> 
> Pavel

Re: Maven Assembly Plugin renaming jar

[James Klo]

As you didn't post a complete log or pom.xml (i.e. no properties, or or 
artifact metadata (group, artifactId, version, etc). We don't know what phase 
or goal you're executing, etc. With what you provided it's difficult to discern 
what's going on. 

Maven Assembly Plugin assembles new artifacts... it's going to copy from your 
.m2 to a representative location specified in your assembly descriptor. It 
won't rename unless you explicity tell it to. You're doing some renaming, but 
that's inside the artifact you're creating. I can only assume what's going on 
without seeing the rest of your POM, assembly descriptor, and log. 

You have things like this in your descriptor...

target/${artifactId}-${version}.${packaging}   
   
/
  
${artifactId}.${packaging} 
 
  

Note artifactID, version, packaging are going to be inherited from the POM, 
they going to resolve from your descriptor. This all can have some strange side 
effects because it looks like you're trying to include yourself but then rename 
yourself to something different inside an artifact you're creating. To a 
certain extent this looks a bit bizzare.

Without any other information on hand, the only think I can suggest is try 
changing the setting for appendAssemblyId from false to true; then rerun and 
inspect the log...  what does the log say it's "renaming" it to? My suspicion 
is that you'll see:

[DEBUG] Adding artifact: com.example:MyArtifact:jar:8.0.0 with file: 
/Users/me/.m2/repository/com/example/MyArtifact/8.0.2/MyArtifact-8.0.2.jar to 
assembly location: lib/MyArtifact-bin-8.0.0.jar.
[DEBUG] Adding file: 
/Users/me/.m2/repository/com/example/MyArtifact/8.0.2/MyArtifact-8.0.2.jar to 
archive location: Project/lib/MyArtifact-bin-8.0.0.jar

Before anyone can really help you futher, I'd say you need to provide more 
complete information; redacted where appropriate, but it really needs to be 
complete.

- JK

On 12/15/17, 10:18 AM, "Wilson, Sam" <sawil...@akamai.com> wrote:

Hey James,

The way you interpreted the version range is indeed what I intended (we use 
semantic versioning.)

It is definitely renaming the jar. I checked the shasums of 
MyArtifact-8.0.2.jar and the file included in the archive, and they match, even 
though the file is named MyArtifact-8.0.0.jar.

The MANIFEST contains “lib/MyArtifact-8.0.2.jar” as an entry.

Why would it be named MyArtifact-bin-8.0.0.jar ever?

I can try to create a minimal repro, but it’ll be hard because this is a 
big project with lots of parts.

    Sam
    

From: James Klo <jim@sri.com>
Reply-To: Maven Users List <users@maven.apache.org>
Date: Friday, December 15, 2017 at 12:27 PM
To: Maven Users List <users@maven.apache.org>
Subject: Re: Maven Assembly Plugin renaming jar

From the small snippet of log, it's bit confusing, because it looks like 
the artifact you are assembling is named the same as the dependency you are 
pulling in. Because you have this setting in the maven-assembly-plugin:
  
 false   

The generated Artifact is being named:
MyArtifact-8.0.0.jar

Instead of being named:
MyArtifact-bin-8.0.0.jar

Additionally, look at version range declaration for MyArtifact...

[8.0.0-SNAPSHOT,9.0.0-SNAPSHOT)

Per this enforcer docs: 
https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

I would read your requirement as
8.0.0-SNAPSHOT >= X < 9.0.0-SNAPSHOT

So it's not renaming your jar, it is fetching the most current version of 
the dependent artifact defined for that range and adding it into your current 
project assembly which just so happens to now have the same name AND a similar 
version number.


Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac

On 12/15/17, 8:51 AM, "Wilson, Sam" 
<sawil...@akamai.com<mailto:sawil...@akamai.com>> wrote:

Sorry to bump and old thread, but I’d appreciate it if someone had any 
insight.

Sam

From: Sam Wilson <sawil...@akamai.com<mailto:sawil...@akamai.com>>
Reply-To: Maven Users List 
<users@maven.apache.org<mailto:users@maven.apache.org>>
Date: Friday, November 24, 2017 at 11:12 AM
To: "users@maven.apache.org<mailto:users@maven.apache.org>" 
<users@maven.apache.org<mailto:users@maven.apache.org>>
Subject: Re: Maven Assembly Plugin renaming jar

Oh,

Re: Maven Assembly Plugin renaming jar

[James Klo]

>From the small snippet of log, it's bit confusing, because it looks like the 
>artifact you are assembling is named the same as the dependency you are 
>pulling in. Because you have this setting in the maven-assembly-plugin: 
  
 false   

The generated Artifact is being named:
MyArtifact-8.0.0.jar

Instead of being named:
MyArtifact-bin-8.0.0.jar

Additionally, look at version range declaration for MyArtifact...

[8.0.0-SNAPSHOT,9.0.0-SNAPSHOT)

Per this enforcer docs: 
https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

I would read your requirement as 
8.0.0-SNAPSHOT >= X < 9.0.0-SNAPSHOT

So it's not renaming your jar, it is fetching the most current version of the 
dependent artifact defined for that range and adding it into your current 
project assembly which just so happens to now have the same name AND a similar 
version number.


Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
 t. @nsomnac 
 

On 12/15/17, 8:51 AM, "Wilson, Sam"  wrote:

Sorry to bump and old thread, but I’d appreciate it if someone had any 
insight.

Sam

From: Sam Wilson 
Reply-To: Maven Users List 
Date: Friday, November 24, 2017 at 11:12 AM
To: "users@maven.apache.org" 
Subject: Re: Maven Assembly Plugin renaming jar

Oh, I should mention that I've tried this with maven-assembly-plugin 2.4
and 3.1.0.

Sam

On 11/24/2017 11:07 AM, Wilson, Sam wrote:
Hey!
Hopefully you can help me out. Maven assembly plugin seems to be renaming a 
jar file without being told to, and it’s messing up my MANIFEST.MF classpath.
You notice in the snippet of mvn -X below the assembly plugin seems to be 
getting version 8.0.2, but it renames it to 8.0.0.
Thanks,
Sam
---
mvn -X package
--
[…]
[DEBUG] Adding dependency artifact com.example:MyArtifact:jar:8.0.0.
[DEBUG] Adding artifact: com.example:MyArtifact:jar:8.0.0 with file: 
/Users/me/.m2/repository/com/example/MyArtifact/8.0.2/MyArtifact-8.0.2.jar to 
assembly location: lib/MyArtifact-8.0.0.jar.
[DEBUG] Adding file: 
/Users/me/.m2/repository/com/example/MyArtifact/8.0.2/MyArtifact-8.0.2.jar to 
archive location: Project/lib/MyArtifact-8.0.0.jar
[…]
---
Project/pom.xml
---

 
 
 
 
 com.example
 MyArtifact
 [8.0.0-SNAPSHOT,9.0.0-SNAPSHOT)
 
 
 
 
 
 org.apache.maven.plugins
 maven-jar-plugin
 2.4
 
 
 
 true
 lib/
 com.example.MainClass
 
 
 
 
 
 org.apache.maven.plugins
 maven-assembly-plugin
 2.2
 
 
 package
 
 single
 
 
 
 ${project.artifactId}
 
 
 false
 
 
 
src/assembly/bin.xml
 
 false
 
 
 
 

---
Project/src/assembly/bin.xml
---
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 
http://maven.apache.org/xsd/assembly-1.1.0.xsd;>
 bin
 ${artifactId}
 
 tar.gz
 dir
 
 
 
 false
 false
 runtime
 lib
 
 
 
 
 
target/${artifactId}-${version}.${packaging}
 /
 ${artifactId}.${packaging}
 
  

Re: how can I prevent maven-deploy-plugin:deploy-file from deploying main artifact?

[James Klo]

Hi Robert,

Thanks for the reply.

On Sep 20, 2017, at 1:05 AM, Robert Scholte 
<rfscho...@apache.org<mailto:rfscho...@apache.org>> wrote:

Are you asking the right question?


Not sure. I see three possible questions:
1. How can I change/set the version dynamically during the reactor build?
2. How can I replace the main artifact with a different artifact?
3. How can I prevent the main artifact from deploying?


it seems to me you want to deploy files of this project.

Yes, but I want the version coordinates to reflect the version discovered, not 
the version provided.

if you want to convert/replace the main artifact, I suggest to use the same 
filename.


I've tried that. All I end up with is a correctly named file installed in my 
repo at the wrong version coordinate.

also have a look at 
http://www.mojohaus.org/build-helper-maven-plugin/attach-artifact-mojo.html

How does this replace the main artifact? It says it only adds artifacts.

deploy-file is never a good solution as part of the build lifecycle, there are 
often plugins which better match the requirements.

Okay. So what is the right plugin? Why is it never a good solution within the 
lifecycle? Does it not do what it says?


And here lies the rub with maven - nowhere exists a master document that 
outlines how to use each and locate each of thousands of plugins. Sure one can 
utilize  to locate the plugin 
documentation, only to yield cookie cutter generated docs that highlight use 
both in pom and cli and rarely describe the intent.


This goal is intended to be run from commandline and to upload 3rd party jars.

Yes, that's how I've used it in the past. But why would my use case be any 
different?
1. I'm technically creating a third-party jar.
2. It mostly doing what I want, I just don't understand why it is still 
deploying my third-party jar also as the main artifact.



Robert


On Tue, 19 Sep 2017 23:57:03 +0200, James Klo 
<jim@sri.com<mailto:jim@sri.com>> wrote:

I’m using the io.fabric8:maven-docker-plugin to launch a container, run 
specialized build that generates some versioned files and then I want to take 
those files convert them into an artifact and upload them to our corp 
Artifactory.

I’ve got mostly the whole thing working except the last step, deploying to 
Artifactory.  Yes it deploys, but it deploys too many artifacts.



org.apache.maven.plugins
maven-deploy-plugin
2.8.2


default-deploy
none

deploy



deploy-artifact
deploy

deploy-file


artifactory

https://artifactory.sri.com/artifactory/sunflower-local

${project.build.directory}/${project.artifactId}-${docker_env.FLORA_VERSION}-pdf.tar.bz2
${project.groupId}
${project.artifactId}
${docker_env.FLORA_VERSION}
pdf
tar.bz2
false





so I’ve disabled the default-deploy execution, and replacing it with my own 
deploy-artifact, which runs the deploy-file it deploys both the aux artifact 
and the main artifact:

[INFO] --- maven-deploy-plugin:2.8.2:deploy-file (deploy-artifact) @ 
flora2-docs ---
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0, 
ConflictMarker.markTime=0, ConflictMarker.nodeCount=36, 
ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0, 
ConflictIdSorter.conflictIdCount=16, ConflictIdSorter.conflictIdCycleCount=0, 
ConflictResolver.totalTime=0, ConflictResolver.conflictItemCount=36, 
DefaultDependencyCollector.collectTime=3, 
DefaultDependencyCollector.transformTime=1}
[DEBUG] org.apache.maven.plugins:maven-deploy-plugin:jar:2.8.2:
[DEBUG]org.apache.maven:maven-plugin-api:jar:2.2.1:compile
[DEBUG]org.apache.maven:maven-project:jar:2.2.1:compile
[DEBUG]   org.apache.maven:maven-settings:jar:2.2.1:compile
[DEBUG]   org.apache.maven:maven-profile:jar:2.2.1:compile
[DEBUG]   org.apache.maven:maven-artifact-manager:jar:2.2.1:compile
[DEBUG]  org.apache.maven:maven-repository-metadata:jar:2.2.1:compile
[DEBUG]  
backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
[DEBUG]   org.apache.maven:maven-plugin-registry:jar:2.2.1:compile
[DEBUG]   org.codehaus.plexus:plexus-interpolation:jar:1.11:compile
[DEBUG]   
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
[DEBUG]  junit:junit:jar:3.8.1:compile
[DEBUG]  classworlds:classworlds:jar:1.1-alpha-2:compile
[DEBUG]org.apache.maven:maven-model:jar:2.2.1:compile
[DEBUG]org.apache.maven:maven-artifact:jar:2.2.1:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.15:compile
[DEBUG] Created new class realm 
plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
[DEBUG] Importing foreign packag

Re: how can I prevent maven-deploy-plugin:deploy-file from deploying main artifact?

[James Klo]

On Sep 19, 2017, at 6:42 PM, Russell Gold <russell.g...@oracle.com> wrote:Ah, sorry, I misread what was going on. I looked at the docs for the deploy-file goal and found this:file <>:File to be deployed.Type: java.io.FileRequired: YesUser Property: filefiles <>:A comma separated list of files for each of the extra side artifacts to deploy. If there is a mis-match in the number of entries in types or classifiers, then an error will be raised.Type: java.lang.StringRequired: NoUser Property: filesI think this may be inconsistent, as the most common convention is that the plural attribute simply allows you to specify multiple values. So I am guessing that deploy-file is simply intended to deploy *additional* files, not replacement files.Not sure about that, I think you’re partially reading the docs…http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.htmlnote that “file” is required and is the file you’re deploying… and “files” is a csv list of files as extra side artifacts.Also http://maven.apache.org/plugins/maven-deploy-plugin/  says:deploy:deploy-file is used to install a single artifact along with its pom. In that case the artifact information can be taken from an optionally specified pomFile, but can be completed/overriden using the command line.I’ve used this before from CLI and not had this problem, however I’ve never tried doing this from within a POM. I suppose I could cheat and just exec:exec or antrun:run.Thus, since your project is a snapshot version, you are getting the snapshot version uploaded. What if you let the default goal happen, get rid of the second execution, and simply set the project version to what you are now calling flora-version? What happens then?If I make it just any release version - it still pushes two artifacts.  If I just happen to use the same value as flora-version, it only deploys one.  However this is kind of the apex of the problem.. the version of flora is unknown at the start of the reactor build.Attaching the full pom so it’s more clear. But essentially I need to create an instance of a container which has a very esoteric installation of latex and macros.  That builds some PDF documentation within the container - however the latex source is inside the container which maps to some version within the container.  So after running the container that builds the pdf output - I need to take all those pdf’s and create an artifact from them with a version that matches the flora version in the container.The problem is that Maven makes certain POM properties immutable such that they cannot be changed at runtime.  If ${project.version} were able to modified, I could solve this quick an easy.  Worst case I assign some bogus release version to my POM and just ignore - but it just seems lame that I can’t make this work the way I need.

pom.xml
Description: XML document
On Sep 19, 2017, at 6:15 PM, James Klo <jim@sri.com> wrote:Thanks for responding.However, I’m not sure how that changes things.  The “deploy” goal is currently not executing.The problem seems to me that the “deploy-file” goal is deploying both the file I want in addtion to the main artifact.  Maybe this is a bug? Seems like it could be.- JKOn 9/19/17, 3:09 PM, "Russell Gold" <russell.g...@oracle.com> wrote:   Instead of       default-deploy   none      deploy         try      default-deploy   none       On Sep 19, 2017, at 5:57 PM, James Klo <jim@sri.com> wrote:I’m using the io.fabric8:maven-docker-plugin to launch a container, run specialized build that generates some versioned files and then I want to take those files convert them into an artifact and upload them to our corp Artifactory.I’ve got mostly the whole thing working except the last step, deploying to Artifactory.  Yes it deploys, but it deploys too many artifacts.   org.apache.maven.plugins   maven-deploy-plugin   2.8.2         default-deploy   none      deploy            deploy-artifact   deploy      deploy-file         artifactory   https://artifactory.sri.com/artifactory/sunflower-local <https://artifactory.sri.com/artifactory/sunflower-local>   ${project.build.directory}/${project.artifactId}-${docker_env.FLORA_VERSION}-pdf.tar.bz2   ${project.groupId}   ${project.artifactId}   ${docker_env.FLORA_VERSION}   pdf   tar.bz2   false         so I’ve disabled the default-deploy execution, and replacing it with my own deploy-artifact, which runs the deploy-file it deploys both the aux artifact and the main artifact:[INFO] --- maven-deploy-plugin:2.8.2:deploy-file (deploy-artifact) @ flora2-docs ---[DEBUG] Dependency collection stats: {Con

Re: how can I prevent maven-deploy-plugin:deploy-file from deploying main artifact?

[James Klo]

Thanks for responding.

However, I’m not sure how that changes things.  The “deploy” goal is currently 
not executing.

The problem seems to me that the “deploy-file” goal is deploying both the file 
I want in addtion to the main artifact.  

Maybe this is a bug? Seems like it could be.
 
- JK

On 9/19/17, 3:09 PM, "Russell Gold" <russell.g...@oracle.com> wrote:

Instead of 


default-deploy
none

deploy



try


default-deploy
none


> On Sep 19, 2017, at 5:57 PM, James Klo <jim@sri.com> wrote:
> 
> I’m using the io.fabric8:maven-docker-plugin to launch a container, run 
specialized build that generates some versioned files and then I want to take 
those files convert them into an artifact and upload them to our corp 
Artifactory.
> 
> I’ve got mostly the whole thing working except the last step, deploying 
to Artifactory.  Yes it deploys, but it deploys too many artifacts.
> 
> 
> org.apache.maven.plugins
> maven-deploy-plugin
> 2.8.2
> 
> 
> default-deploy
> none
> 
> deploy
> 
> 
> 
> deploy-artifact
> deploy
> 
> deploy-file
> 
> 
> artifactory
> 
https://artifactory.sri.com/artifactory/sunflower-local 
<https://artifactory.sri.com/artifactory/sunflower-local>
> 
${project.build.directory}/${project.artifactId}-${docker_env.FLORA_VERSION}-pdf.tar.bz2
> ${project.groupId}
> ${project.artifactId}
> ${docker_env.FLORA_VERSION}
> pdf
> tar.bz2
> false
> 
> 
> 
> 
> so I’ve disabled the default-deploy execution, and replacing it with my 
own deploy-artifact, which runs the deploy-file it deploys both the aux 
artifact and the main artifact:
> 
> [INFO] --- maven-deploy-plugin:2.8.2:deploy-file (deploy-artifact) @ 
flora2-docs ---
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0, 
ConflictMarker.markTime=0, ConflictMarker.nodeCount=36, 
ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0, 
ConflictIdSorter.conflictIdCount=16, ConflictIdSorter.conflictIdCycleCount=0, 
ConflictResolver.totalTime=0, ConflictResolver.conflictItemCount=36, 
DefaultDependencyCollector.collectTime=3, 
DefaultDependencyCollector.transformTime=1}
> [DEBUG] org.apache.maven.plugins:maven-deploy-plugin:jar:2.8.2:
> [DEBUG]org.apache.maven:maven-plugin-api:jar:2.2.1:compile
> [DEBUG]org.apache.maven:maven-project:jar:2.2.1:compile
> [DEBUG]   org.apache.maven:maven-settings:jar:2.2.1:compile
> [DEBUG]   org.apache.maven:maven-profile:jar:2.2.1:compile
> [DEBUG]   org.apache.maven:maven-artifact-manager:jar:2.2.1:compile
> [DEBUG]  
org.apache.maven:maven-repository-metadata:jar:2.2.1:compile
> [DEBUG]  
backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
> [DEBUG]   org.apache.maven:maven-plugin-registry:jar:2.2.1:compile
> [DEBUG]   org.codehaus.plexus:plexus-interpolation:jar:1.11:compile
> [DEBUG]   
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
> [DEBUG]  junit:junit:jar:3.8.1:compile
> [DEBUG]  classworlds:classworlds:jar:1.1-alpha-2:compile
> [DEBUG]org.apache.maven:maven-model:jar:2.2.1:compile
> [DEBUG]org.apache.maven:maven-artifact:jar:2.2.1:compile
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.15:compile
> [DEBUG] Created new class realm 
plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
> [DEBUG] Importing foreign packages into class realm 
plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
> [DEBUG]   Imported:  < maven.api
> [DEBUG] Populating class realm 
plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
> [DEBUG]   Included: org.apache.maven.plugins:maven-deploy-plugin:jar:2.8.2
> [DEBUG]   Included: 
backport-util-concurrent:backport-util-concurrent:jar:3.1
> [DEBUG]   Included: org.codehaus.plexus:plexus-interpolation:jar:1.11
> [DEBUG]   Included: junit:junit:jar:3.8.1
> [DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:3.0.15
> [DEBUG] Configuring mojo 
org.apache.maven.plugins:maven-deploy-plugi

how can I prevent maven-deploy-plugin:deploy-file from deploying main artifact?

[James Klo]

I’m using the io.fabric8:maven-docker-plugin to launch a container, run 
specialized build that generates some versioned files and then I want to take 
those files convert them into an artifact and upload them to our corp 
Artifactory.

I’ve got mostly the whole thing working except the last step, deploying to 
Artifactory.  Yes it deploys, but it deploys too many artifacts.


org.apache.maven.plugins
maven-deploy-plugin
2.8.2


default-deploy
none

deploy



deploy-artifact
deploy

deploy-file


artifactory

https://artifactory.sri.com/artifactory/sunflower-local

${project.build.directory}/${project.artifactId}-${docker_env.FLORA_VERSION}-pdf.tar.bz2
${project.groupId}
${project.artifactId}
${docker_env.FLORA_VERSION}
pdf
tar.bz2
false




so I’ve disabled the default-deploy execution, and replacing it with my own 
deploy-artifact, which runs the deploy-file it deploys both the aux artifact 
and the main artifact:

[INFO] --- maven-deploy-plugin:2.8.2:deploy-file (deploy-artifact) @ 
flora2-docs ---
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0, 
ConflictMarker.markTime=0, ConflictMarker.nodeCount=36, 
ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0, 
ConflictIdSorter.conflictIdCount=16, ConflictIdSorter.conflictIdCycleCount=0, 
ConflictResolver.totalTime=0, ConflictResolver.conflictItemCount=36, 
DefaultDependencyCollector.collectTime=3, 
DefaultDependencyCollector.transformTime=1}
[DEBUG] org.apache.maven.plugins:maven-deploy-plugin:jar:2.8.2:
[DEBUG]org.apache.maven:maven-plugin-api:jar:2.2.1:compile
[DEBUG]org.apache.maven:maven-project:jar:2.2.1:compile
[DEBUG]   org.apache.maven:maven-settings:jar:2.2.1:compile
[DEBUG]   org.apache.maven:maven-profile:jar:2.2.1:compile
[DEBUG]   org.apache.maven:maven-artifact-manager:jar:2.2.1:compile
[DEBUG]  org.apache.maven:maven-repository-metadata:jar:2.2.1:compile
[DEBUG]  
backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
[DEBUG]   org.apache.maven:maven-plugin-registry:jar:2.2.1:compile
[DEBUG]   org.codehaus.plexus:plexus-interpolation:jar:1.11:compile
[DEBUG]   
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
[DEBUG]  junit:junit:jar:3.8.1:compile
[DEBUG]  classworlds:classworlds:jar:1.1-alpha-2:compile
[DEBUG]org.apache.maven:maven-model:jar:2.2.1:compile
[DEBUG]org.apache.maven:maven-artifact:jar:2.2.1:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.15:compile
[DEBUG] Created new class realm 
plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
[DEBUG] Importing foreign packages into class realm 
plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
[DEBUG]   Imported:  < maven.api
[DEBUG] Populating class realm 
plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
[DEBUG]   Included: org.apache.maven.plugins:maven-deploy-plugin:jar:2.8.2
[DEBUG]   Included: backport-util-concurrent:backport-util-concurrent:jar:3.1
[DEBUG]   Included: org.codehaus.plexus:plexus-interpolation:jar:1.11
[DEBUG]   Included: junit:junit:jar:3.8.1
[DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:3.0.15
[DEBUG] Configuring mojo 
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy-file from plugin 
realm ClassRealm[plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2, 
parent: sun.misc.Launcher$AppClassLoader@5c647e05]
[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy-file' with basic 
configurator -->
[DEBUG]   (f) artifactId = flora2-docs
[DEBUG]   (f) classifier = pdf
[DEBUG]   (f) file = 
/Users/jklo/projects/RAVE/source/sunflower-docs/doc/flora2-docs/target/flora2-docs-1277-pdf.tar.bz2
[DEBUG]   (f) generatePom = true
[DEBUG]   (f) groupId = com.sri
[DEBUG]   (s) localRepository =   id: local
  url: file:///Users/jklo/.m2/repository/
   layout: default
snapshots: [enabled => true, update => always]
 releases: [enabled => true, update => always]

[DEBUG]   (f) offline = false
[DEBUG]   (f) packaging = tar.bz2
[DEBUG]   (f) project = MavenProject: com.sri:flora2-docs:0.0.1-SNAPSHOT @ 
/Users/jklo/projects/RAVE/source/sunflower-docs/doc/flora2-docs/pom.xml
[DEBUG]   (f) repositoryId = artifactory
[DEBUG]   (f) repositoryLayout = default
[DEBUG]   (f) retryFailedDeploymentCount = 1
[DEBUG]   (f) uniqueVersion = false
[DEBUG]   (f) updateReleaseInfo = false
[DEBUG]   (f) url = https://artifactory.sri.com/artifactory/sunflower-local
[DEBUG]   (f) version = 1277
[DEBUG] -- end configuration --
[DEBUG] Using transporter WagonTransporter with priority -1.0 for 

Re: options

[James Klo]

> On Aug 17, 2017, at 11:59 PM, Tomaz Majerhold <tomaz.majerh...@arnes.si> 
> wrote:
> 
> No, because it is on CI system and I can't  do it interactively(I know docker 
> switches  ), thx any way.

Where the container instance runs shouldn’t matter.  If it’s a container as you 
say, the Maven instance inside the container should download to the same 
location regardless of the host system, unless you’re passing some environment 
into the entry point / cmd that would change that (but then you’re somewhat 
defeating the purpose of the container), your CI system should be able to log 
the command, settings, and environment used to run the container.

If you exec the container locally (on a system you have access), the .m2 repo 
should be in the same exact location as it would be if using the CI system as 
host.  That’s one of the main reasons one uses a container in a CI system - 
because it provides a portable environment for process instances.

I have a similar setup where I run maven inside a container.  I also have to 
pass credentials and such into the container for things like SCM and 
Artifactory. I’m also able to log all the docker output into the CI.  But if I 
have some problem with some particular image, I just pull the image from 
wherever it originates (Artifactory for me) and run it locally so I can inspect 
it while running. 

Also if you can run:
mvn help:effective-settings -X -l 
/path/to/a/logfile/that/you/can/access.log

You should be able to capture the output in some manner and then search for the 
string “Using local repository at” which should be about 100 lines or so past 
the start of the log.

Aside: if your CI system has the docker daemon configured to also run on a tcp 
port… you should be able to connect to it…. see 
https://docs.docker.com/engine/reference/commandline/dockerd/

> 
> Regards, Tomaž
> 
> James Klo je 17.8.2017 ob 16:25 napisal:
>> You can attach and inspect a running Docker container with:
>> 
>> docker exec -it  bash
>> 
>> But the cache should be by default in ~/.m2.
>> 
>> So depending upon what user your container is running, it should download 
>> all the artifacts into $HOME/.m2
>> 
>> Also you should be able to inspect the mvn output inside your container 
>> using:
>> 
>> docker logs 
>> 
>> Jim Klo
>> Senior Software Engineer
>> SRI International
>> t: @nsomnac
>> 
>> On Aug 17, 2017, at 5:46 AM, Tomaž Majerhold <tomaz.majerh...@arnes.si 
>> <mailto:tomaz.majerh...@arnes.si><mailto:tomaz.majerh...@arnes.si> 
>> <mailto:tomaz.majerh...@arnes.si>> wrote:
>> 
>> But if I use mvn -X help:effective-settings
>> it hide me information about localRepository
>> 
>> I'm using inside a docker, and I can override MAVEN_OPTS and there I could 
>> override with -Dmaven.repo.local but at run time I wont to know where is 
>> saved(to be sure)
>> It is about cache in my container environment.
>> 
>> Regards, Tomaž
>> 
>> Tomaž Majerhold je 17. 08. 2017 ob 14:38 napisal:
>> Yes at run time(maven showing it on standard output), where are actually 
>> saved, because if you are using maven docker image and you can not go inside 
>> a container interactively.
>> 
>> Regards, Tomaž
>> 
>> 
>> 
>> Russell Gold je 17. 08. 2017 ob 14:01 napisal:
>> Hi Tomaž,
>> 
>> What do you mean by, “downloaded”?
>> 
>> Do you mean where the local maven repository is located? You can configure 
>> that in settings.xml <http://maven.apache.org/settings.html> 
>> <http://maven.apache.org/settings.html>
>> 
>> Regards,
>> Russ
>> 
>> On Aug 17, 2017, at 5:25 AM, Tomaž Majerhold <tomaz.majerh...@arnes.si 
>> <mailto:tomaz.majerh...@arnes.si><mailto:tomaz.majerh...@arnes.si> 
>> <mailto:tomaz.majerh...@arnes.si>> wrote:
>> 
>> Hello!
>> 
>> Is it possible(some options switches ) at runtime to determine 
>> where(location)  artifacts has ben downloaded?
>> 
>> It would be useful information for running maven in docker.
>> 
>> Regards, Tomaž
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
>> <mailto:users-unsubscr...@maven.apache.org><mailto:users-unsubscr...@maven.apache.org>
>>  <mailto:users-unsubscr...@maven.apache.org>
>> For additional commands, e-mail: users-h...@maven.apache.org 
>> <mailto:users-h...@maven.apache.org><mailto:users-h...@maven.apache.org> 
>> <mailto:users-h...@maven.apache.org>
>> 
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
>> <mailto:users-unsubscr...@maven.apache.org><mailto:users-unsubscr...@maven.apache.org>
>>  <mailto:users-unsubscr...@maven.apache.org>
>> For additional commands, e-mail: users-h...@maven.apache.org 
>> <mailto:users-h...@maven.apache.org><mailto:users-h...@maven.apache.org> 
>> <mailto:users-h...@maven.apache.org>
>> 
> 





smime.p7s
Description: S/MIME cryptographic signature

Re: options

[James Klo]

You can attach and inspect a running Docker container with:

docker exec -it  bash

But the cache should be by default in ~/.m2.

So depending upon what user your container is running, it should download all 
the artifacts into $HOME/.m2

Also you should be able to inspect the mvn output inside your container using:

docker logs 

Jim Klo
Senior Software Engineer
SRI International
t: @nsomnac

On Aug 17, 2017, at 5:46 AM, Tomaž Majerhold 
> wrote:

But if I use mvn -X help:effective-settings
it hide me information about localRepository

I'm using inside a docker, and I can override MAVEN_OPTS and there I could 
override with -Dmaven.repo.local but at run time I wont to know where is 
saved(to be sure)
It is about cache in my container environment.

Regards, Tomaž

Tomaž Majerhold je 17. 08. 2017 ob 14:38 napisal:
Yes at run time(maven showing it on standard output), where are actually saved, 
because if you are using maven docker image and you can not go inside a 
container interactively.

Regards, Tomaž



Russell Gold je 17. 08. 2017 ob 14:01 napisal:
Hi Tomaž,

What do you mean by, “downloaded”?

Do you mean where the local maven repository is located? You can configure that 
in settings.xml 

Regards,
Russ

On Aug 17, 2017, at 5:25 AM, Tomaž Majerhold 
> wrote:

Hello!

Is it possible(some options switches ) at runtime to determine where(location)  
artifacts has ben downloaded?

It would be useful information for running maven in docker.

Regards, Tomaž


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





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