On Wed, 13 May 2020 at 11:50, Anders Hammar <and...@hammar.net> wrote: > > activeByDefault is a bit tricky as it doesn't really when that it is > active by default all the time. It is only active if there is no other > profile ativated [1]. So I believe this is the behavior that you're seeing. > > So, 'activeByDefault' is typically not good to use as you can get > unexpected behavior. E.g. when you enable some other profile.
That's very interesting... and completely un-intuitive behaviour IMHO I just read in [1]: "This profile will automatically be active for all builds unless another profile in the same POM is activated using one of the previously described methods" So, in this case there is another profile which is activated in that POM when it detects that it is running on MacOS. I guess this would explain what is causing the <activeByDefault> to be ignored? > On a general note I don't really understand the use case. In general you > shouldn't use profiles, especially to change the build behavior as you seem > to be wanting here. We have a module that has many steps in it. It builds a distribution of our software (lots of different types of package: DMG for Mac, Zip and Bz2 files, etc), by default I want all of those packages to build. Building all those packages takes a lot of time. For developers to speed up their build-test lifecycle I want to offer flags to disable building some of those packages. I thought I could do that in this way. I might be better to do the inverse though where the build plugin is set to <skipAssembly>false</skipAssembly>, and I could instead enable a profile which sets <skipAssembly>true</skipAssembly>. It's not enough to use a command line property to control the assembly-plugin as we make lots of different uses of it within that module. I do realise that ultimately we should likely refactor this large module into a parent with lots of smaller modules, but that is a large amount of work as there are lots of file dependencies between the plugin steps. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
