RE: Maven properties passed to external ant build file

[Justin Georgeson]

Looks like if I use nested  elements inside the  call it's 
working. Which is contrary to the maven-antrun-plugin 'Using Maven properties' 
section at http://maven.apache.org/plugins/maven-antrun-plugin/usage.html. Will 
try to reduce and example project and file a bug report. 

> -Original Message-
> From: Justin Georgeson [mailto:justin.george...@halliburton.com]
> Sent: Thursday, August 17, 2017 5:31 PM
> To: Maven Users List (users@maven.apache.org) 
> Subject: [EXTERNAL] Maven properties passed to external ant build file
> 
> External Sender: Use caution with links/attachments.
> 
> 
> 
> I'm using maven-antrun-plugin to execute targets in an external Ant build 
> file,
> and having an issue with inherited properties.
> 
>   
>   ${skipIvyPublish}
>   
>   https://urldefense.proofpoint.com/v2/url?u=http-3A__-
> 257Bivy.publish.re=DwIFAg=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbrMXk2FZvF0UfTo=IaG729QyGh1osYCbh8OX9axItHyepxef_hVPx
> 52Ly1s=jU_eveXMV4xr4ZGmOAYbmZOCgFUHd7iG3lp8h1UpgFM=qcSKdeR
> 57hGmNWmb6d94uy2ZGp25vlzkIPW0iNOqLec= solver}"/>
>value="$https://urldefense.proofpoint.com/v2/url?u=http-3A__-
> 257Bivy.publish.re=DwIFAg=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbrMXk2FZvF0UfTo=IaG729QyGh1osYCbh8OX9axItHyepxef_hVPx
> 52Ly1s=jU_eveXMV4xr4ZGmOAYbmZOCgFUHd7iG3lp8h1UpgFM=qcSKdeR
> 57hGmNWmb6d94uy2ZGp25vlzkIPW0iNOqLec= solver}"/>
>   https://urldefense.proofpoint.com/v2/url?u=http-3A__-
> 257Bivy.publish.re=DwIFAg=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbrMXk2FZvF0UfTo=IaG729QyGh1osYCbh8OX9axItHyepxef_hVPx
> 52Ly1s=jU_eveXMV4xr4ZGmOAYbmZOCgFUHd7iG3lp8h1UpgFM=qcSKdeR
> 57hGmNWmb6d94uy2ZGp25vlzkIPW0iNOqLec= solver}"/>
>antfile="$https://urldefense.proofpoint.com/v2/url?u=http-3A__-
> 257Bivy.de=DwIFAg=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbrMXk2FZvF0UfTo=IaG729QyGh1osYCbh8OX9axItHyepxef_hVPx
> 52Ly1s=jU_eveXMV4xr4ZGmOAYbmZOCgFUHd7iG3lp8h1UpgFM=j3u9bKQ
> hroNEpQCKrkkRTG5sUpsX2RER9LLvM-V1yiQ= pendencies.dir}/ivy-build.xml"
>   target="ivy.publish"
>   inheritAll="true"
>   inheritRefs="true"/>
>   
>   
> 
> As you might guess from the above, I have a property in my pom.xml named
> ivy.publish.resolver. The two echo lines here show the correct value (either 
> the
> default from my pom.xml or what I supply to Maven with 
> -Divy.publish.resolver).
> But within the ivy-build.xml the very first task executed (the init: target 
> in the
> output below) is the same echo statement, and inevitably the property value is
> always the default from pom.xml, ignoring what I've set with -D command-line
> argument.
> 
> [INFO] --- maven-antrun-plugin:1.8:run (ivy-publish) @ maven-ivy-example 
> ---
> [INFO] Executing tasks
> 
> ivy.publish:
>  [echo] resolver: fred
>  [echo] resolver: fred
> 
> init:
>  [echo] resolver: published.local
> 
> Any suggestions?
> 
> --
> This e-mail, including any attached files, may contain confidential and 
> privileged
> information for the sole use of the intended recipient.  Any review, use,
> distribution, or disclosure by others is strictly prohibited.  If you are not 
> the
> intended recipient (or authorized to receive information for the intended
> recipient), please contact the sender by reply e-mail and delete all copies 
> of this
> message.
> 
> -
> 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

Re: options

[James Klo]

> On Aug 17, 2017, at 11:59 PM, Tomaz Majerhold  
> 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 >  
>> > 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 
>>  
>> 
>> 
> 





smime.p7s
Description: S/MIME cryptographic signature

Re: How best to use profiles and modules for different build purposes

[Anders Hammar]

First of all, if you want to do releases you WILL need a centralized
(remote) repo where you can deploy that to. It doesn't make sense for every
developer to build their own copy of any release of your internal artifacts.

Secondly, you don't need to deploy your artifacts to a remote repo. You can
do that to your local repo (~/.m2/repository/). This is typically what you
do during development, but it also works for releases. However, it will
then not be available for anyone else but yourself and that will force
everyone to build every release (which is not the right way).
So if I understand your case you could skip the local Nexus and go with
"mvn install" (even for releases).

Or you could force everyone to have a local Nexus and have a common setup.
Thus, no need for using profiles or something to get different behavior for
different users.

Profiles are evil. Don't use them as they will cause other issues typically.

/Anders

On Wed, Aug 16, 2017 at 11:15 PM, Kevin Duffey <
kevinmduf...@yahoo.com.invalid> wrote:

> Hi all,
> I am working on a project where we have set up modules to manage
> components better, such as common code, logging, server side, api, etc. It
> has thus far worked out very nicely. We have one module that is within our
> entire application and depends on some of the modules (namely api and
> messaging modules), but builds an artifact we want to push to our nexus
> repo eventually for others to consume. This particular module is used by
> some of our developers internally for testing of some features. Thus, I
> have provided instructions on how to set up a local (developer box) nexus
> using docker. We are all remote workers so not on a shared LAN and we are
> not yet in a position to deploy a hosted nexus.
> The problem I am facing is the .m2/settings.xml has to be configured to
> use the local docker run repo in order for the artifact to be published to
> the docker nexus on the local dev box, and for it to be accessible for a
> project outside of our main project. The secondary project is one way we
> test that the published artifact is reachable and works. So some of our
> developers have no need for this local nexus setup. The problem is that I
> set up the repository settings in our parent pom to use the localhost repo
> (which has proxies to central, etc). But if the docker instance is not
> running (and settings.xml in .m2/ is not configured) for those developers
> not needing/interested, the build breaks. Obviously..it cant find the local
> nexus it is configured for.
> So I thought profiles might be the way to solve this. We havent yet used
> them as our Jenkins build uses our default non-profile based pom setup. I
> am reading however that it is better to put profile specifics in individual
> modules, instead of the parent module with multiple profiles.
> Thus..my email to the list. I am not sure what is the best solution in our
> case. I have a developer profile that should only build/depend on most
> modules, but also work when the docker nexus is not running. Thus, I was
> thinking in the parent pom I would set profiles, each with the repository
> settings needed for their profile build specifics. For the module that
> builds in to an artifact and would be pushed to our hosted nexus (but for
> now the local docker nexus), it would use the localhost nexus repository
> details. For the typical developer build that is not interested in the
> local docker nexus, it would keep the usual central/jcenter repository
> setup. But after reading about putting profile stuff in individual
> modules.. well that is why I am here.
> So, should I keep my parent pom as is (e.g. using the central/jcenter
> repositories) and add the specific local nexus repository details to a
> profile section in the one module that would push to it? If that is the
> case.. what about the .m2/settings.xml configuration? Do I put a matching
> profile section in there (that matches the module profile id) so that only
> when that profile is activated it is used? Or do I just not have a
> settings.xml in .m2 at all and all of the  and such is in the one
> module?
> Appreciate any help on this.
> Thanks.

Re: Transitive dependencies and version management

[Anders Hammar]

What you would do is that you specify the version of C in
dependencyManagement of A. When you then build A, the specified version of
C will be used regardless of what version is specified in B. However, for
thsi to work in runtime this requires the specified version of C to be
compatible with the version that B was compiled with.

I very often, when talking to developers, run into the thinking that (using
your naming) B needs to be re-release whenever there is a new version of C.
You don't have to do that but you could handle that in A using
dependencyManagement. Also, if you utilize api modules and impl modules you
could do this even more beautifully by having B depend on an API artifact
which doesn't change that often.

/Anders

On Fri, Aug 18, 2017 at 2:34 AM, Halper, Andrew  wrote:

> Greetings,
>
> I was wondering if someone might be able to help with a Maven version
> management problem we've encountered.
>
> We have several interdependent, legacy Java projects, that have recently
> been re-cast as Maven projects. Now that we have the first iteration done,
> it's apparent that one salient characteristic of this particular group of
> projects is: there are about a half-dozen "front-end" projects that depend
> on an intermediate layer of several projects, which in turn depend on a
> rather large, "monolithic" type project at the back. For the sake of
> brevity, a set of projects A, depends (selectively) on a set of projects B,
> which in turn depend on a single project c (the monolithic one).
>
> A colleague would like to be able to increment the version number of
> project c, then recompile the set of projects A, without having to
> re-specify c's prerequisite version number occurrences in each pom.xml file
> of each (intermediate level) project in B each time project c's version is
> incremented. This would almost surely be desired only in development, and
> not in a test or production environment.
>
> Could anyone tell me if there is an intrinsic Maven feature that could be
> employed here? The present, proposed solution to the problem is to declare
> the  of each of c's dependency declarations in each B project's
> pom.xml as "provided", but I am uneasy with this. For example, what if
> someone wanted to compile a project in B in isolation from the projects in
> A?
>
> Thanks very much,
> --
> Andy Halper
> USGS WMA Software Engineering
> 520 N Park Ave Ste 221
> Tucson AZ 85719
>

Re: options

[Tomaz Majerhold]

No, because it is on CI system and I can't  do it interactively(I know 
docker switches  ), thx any way.


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 
> 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



--

*Tomaž Majerhold*

Arnes 25 let

Arnes p. p. 7, 1001 Ljubljana
T: +386 (0)1 479 88 00 • F: +386 (0)1 479 88 01 • i...@arnes.si 
 • www.arnes.si