Profiles per-se are “ok” Adding dependencies in a profile is not.
The problem is when do those profiles get activated, and hence when will the dependencies get pulled in. When people have profiles activated by the presence of a file, and then that pom is resolved from the local repo and not from the checkout... then the file will not be in ~/.m2/repository/.../.../.../ so the profile will not be activated, and hence the dependency is lost. When people have profiles activated by the presence of a system property, and then the pom is resolved by a different build where the system property is not defined, the dependency will go missing. When people have profiles activated by a specific OS or JDK and then you build e.g. a WAR file that depends on it with one JDK, then the WAR file will only work for that JDK. Every time somebody tries adding a dependency via a profile, it comes back to shoot a downstream consumer of the pom in the ass. It was a mistake to allow (transitive scoped) <dependencies> in <profile>s in the first place. BTW a similar sin is using properties to define dependency coordinates and using profiles to change those properties. I suspect non-transitive dependencies (i.e. scope=test or provided) in profiles *might* have one or two valid use cases... but you would *REALLY* need to be sure you knew what exactly you were doing and why, and I would fight tooth and nail to avoid needing to go down that road. -Stephen On 11 April 2012 23:22, mike digioia <[email protected]> wrote: > Brian, > > You can find detail in the manual - > > What do we mean by different build environments? Two example build > environments are production and devel- > opment. When you are working in a development environment, your system > might be configured to read from a > development database instance running on your local machine while in > production, your system is configured to > read from the production database. Maven allows you to define any number of > build environments (build profiles) > which can override any of the settings in the pom.xml. You could configure > your application to read from your > local, development instance of a database in your "development" profile, > and you can configure it to read from the > production database in the "production" profile. Profiles can also be > activated by the environment and platform, > you can customize a build to run differently depending the Operating System > or the installed JDK version. Before > we talk about using and configuring Maven profiles, we need to define the > concept of Build Portability. > ********************* > > I don't see anything wrong with their use to fix the many current issues > with using this system in very different industry/commercial settings > > > On Wed, Apr 11, 2012 at 2:48 PM, Brain Dump <[email protected]> > wrote: > > > Just to see if it would work, I moved the child-dep-jdk15 dependency out > of > > profiles and moved it into <dependencies></dependencies> (outside of > > profiles). It still fails with the same stack trace. Any idea why? I can > > get the build to pass if I leave out that dependency altogether, but > that's > > not really an option without significant code rewriting. > > > > I'm also curious about why including a dependency in a profile is not a > > good idea (as is using profiles at all). I'm working on a large codebase > > and would need to explain to the rest of the team before making such > > changes. Where can I read up on best practices about this? > > > > On Wed, Apr 11, 2012 at 1:29 PM, Wayne Fay <[email protected]> wrote: > > > > > > I've managed to do to get the build to succeed is to (1) remove the > > > > dependency listed within <profiles></profiles> of child-alpha, or (2) > > > first > > > > > > For a ton of reasons, including a dependency in a profile is a really > > > terrible thing to do. The very first thing I would do would be to > > > remove it. > > > > > > In fact, I'd do everything I could to remove the use of profiles from > > > your build entirely. > > > > > > Wayne > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
