Re: Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, > When been over this several times on this list. You have to extract > the configuration out of the binary. You mustn't have a Maven build > that could generate different flavors of an artifact. Which one would > you deploy to the repository? Ok, this was a bit misleading by me. With "flavors" I just meant * mvn clean deploy by command or on a nightly base * mvn release:prepare release:perform final releases / pre-releases meant for an integration build and/or tests by our business department > If you can't separate the configuration out of the binary, you should > have multiple projects each one generate one of the flavors. +1 Regards Thorsten
Re: Re: Re: useing profiles to control properties to drive version numbers in poms
> We're having lots of projects building at least one EAR, and each EAR is > deployed to the same application server(s), but in different flavors: > developer (snapshot) build, integration build and/or release build. Using > a CI server configured with special jobs doing these deployment tasks > would result in having to implement the same tasks again and again. IMHO > this is more error-prone than having a default job in a parent pom doing > that... When been over this several times on this list. You have to extract the configuration out of the binary. You mustn't have a Maven build that could generate different flavors of an artifact. Which one would you deploy to the repository? If you can't separate the configuration out of the binary, you should have multiple projects each one generate one of the flavors. /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, > > I'm using profiles at work for the sole purpose of deciding what to do > > with the build artifact, i.e. activating different deployment targets > > (application servers) for an EAR. > > I see this as a completely different task where you're simply using > Maven as a utility tool. When using Maven as a "build tool", you will > be deploying the artifacts to a repository. What you then do with the > artifacts after that (like e.g. publish to an app server) is outside > of the build story, and should be handled as a separate task. Ok, but in that case I'm just simplifying life: We're having lots of projects building at least one EAR, and each EAR is deployed to the same application server(s), but in different flavors: developer (snapshot) build, integration build and/or release build. Using a CI server configured with special jobs doing these deployment tasks would result in having to implement the same tasks again and again. IMHO this is more error-prone than having a default job in a parent pom doing that... Regards Thorsten
