How best to use profiles and modules for different build purposes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How best to use profiles and modules for different build purposes

Kevin Duffey-2
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 <server/> and such is in the one module?
Appreciate any help on this.
Thanks.
Reply | Threaded
Open this post in threaded view
|

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 <
[hidden email]> 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 <server/> and such is in the one
> module?
> Appreciate any help on this.
> Thanks.