No, never to a build for a specific environment! It's "One build fits all"! There was a recent thread about that; you might want to have a look to get the details.
/Anders On Wed, Oct 6, 2010 at 15:39, Phillip Hellewell <[email protected]> wrote: > On Tue, Oct 5, 2010 at 2:56 AM, Vincent Latombe > <[email protected]> wrote: > > To handle distributionManagement, I define the url as a property that is > > defined in settings.xml. > > This allow me to define the whole connectivity from settings.xml. If ever > my > > repository changed, I just need to update settings.xml on my build > machines, > > instead of releasing a new parent and bumping parent version in all > > projects. > > Just a reminder, this was the email thread about settings in general, > for things like profiles. Also it seems to be agreed that > <repositories> belong in the settings.xml. > > We weren't really talking about <distributionManagement>. That was in > another thread. The comments in that other thread suggest that using > settings.xml for <distributionManagement> is "wrong"; it should be > done in a parent pom instead. > > One thing I am planning to have is a couple properties to determine > what type of build to do, ${build.platform} and ${build.config}. > ${build.platform} will be one of "Win32", "x64", or "all". > ${build.config} will be one of "Release", "Debug", or "all". Based on > what I have read in both these email threads, I believe the "correct" > way to do this is to define those properties in my parent pom with > default values ("all"), and then to override them if desired using > profiles in settings.xml. > > Phillip > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
